EUVD-2026-38330
GHSA-wgpf-jwqj-8h8p
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Network vector with high complexity because exploitation requires Lambda@Edge deployment plus header-chain-dependent security middleware; low C and I reflect partial access control weakening with no availability impact.
Primary rating from Vendor (https://github.com/honojs/hono).
CVSS VectorVendor: https://github.com/honojs/hono
Lifecycle Timeline
2Blast Radius
ecosystem impact- 58 npm packages depend on hono (42 direct, 17 indirect)
Ecosystem-wide dependent count for version 4.12.25.
DescriptionCVE.org
Summary
On AWS Lambda@Edge, CloudFront delivers a request header that appears more than once as several separate entries. The adapter writes each value with Headers.set instead of Headers.append, so every value overwrites the previous one and only the last reaches the application. Repeated request headers such as X-Forwarded-For, Forwarded, and Via are silently truncated to a single value.
Details
A repeated request header carries an ordered list of values. The adapter iterates the list but overwrites on each step, keeping only the final value. Middleware that depends on the full list - for example IP restriction that walks the X-Forwarded-For chain, or auditing based on Forwarded/Via hops - receives incomplete data. The API Gateway adapter already appends repeated values and is not affected.
This issue arises only on Lambda@Edge deployments, for requests that contain the same header more than once.
Impact
Request middleware sees only the last value of a repeated header instead of the full chain. For applications that base access control on the X-Forwarded-For chain, this can weaken or alter that decision; for auditing, hop history is lost. This affects applications deployed on AWS Lambda@Edge that rely on multi-value request headers.
AnalysisAI
Header chain truncation in Hono's Lambda@Edge adapter silently discards all but the last value of repeated request headers, undermining IP-based access control and audit integrity for applications deployed on AWS Lambda@Edge. The adapter incorrectly uses Headers.set instead of Headers.append when converting CloudFront's multi-value header format, meaning headers such as X-Forwarded-For, Forwarded, and Via are reduced to a single entry before reaching application middleware. Affected deployments using Hono versions prior to 4.12.25 on Lambda@Edge may experience weakened IP restriction logic or loss of hop-chain audit data; no public exploit or active exploitation (CISA KEV) has been identified at time of analysis.
Technical ContextAI
Hono (npm package hono) is a lightweight, multi-runtime web framework that provides platform-specific adapters for environments including AWS Lambda@Edge and API Gateway. On Lambda@Edge, CloudFront serializes repeated HTTP headers - headers whose specification allows multiple values such as X-Forwarded-For, Forwarded, and Via - as distinct array entries in the event payload rather than a single comma-joined string. The Lambda@Edge adapter iterates this array but calls Headers.set(name, value) on each iteration; because set replaces any existing value for a given header name, each iteration overwrites the previous, retaining only the final value. The correct call is Headers.append, which accumulates values. The API Gateway adapter already uses append and is unaffected. CWE-348 (Use of Less Trusted Source) applies: the application receives a truncated, less-representative header value rather than the authoritative full chain, causing downstream middleware to base trust decisions on incomplete data. The affected package is pkg:npm/hono at versions below 4.12.25.
RemediationAI
Upgrade the hono npm package to version 4.12.25 or later, which replaces the incorrect Headers.set call with Headers.append in the Lambda@Edge adapter. The fix is documented in the GitHub Security Advisory at https://github.com/honojs/hono/security/advisories/GHSA-wgpf-jwqj-8h8p. If an immediate upgrade is not possible, a compensating control is to consolidate multi-value X-Forwarded-For header values at the CloudFront layer using a Lambda@Edge origin-request function that joins repeated header values into a single comma-separated string before the Hono adapter processes them; this avoids the set-vs-append issue but adds latency and operational complexity. Alternatively, avoid placing security-critical IP restriction logic inside Hono middleware for Lambda@Edge deployments and instead enforce it at the CloudFront distribution level using WAF IP match conditions, which operate before the request reaches the adapter and are not affected by this bug.
Same weakness CWE-348 – Use of Less Trusted Source
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today