CVE-2026-54289

What it actually does

In Hono versions prior to 4.12.25, the AWS Lambda@Edge adapter mishandles duplicate request headers delivered by CloudFront. When a header appears more than once, the adapter uses `Headers.set()` instead of `Headers.append()`, causing each value to overwrite the previous value. As a result, application code and middleware see only the last value for repeated headers such as `X-Forwarded-For`, `Forwarded`, and `Via`. This can cause incorrect authorization, rate-limiting, IP allowlist, geolocation, logging, or audit decisions when those controls depend on the full proxy or forwarding header chain.

Why it matters to the business

Applications using affected Hono versions on AWS Lambda@Edge may make access-control or auditing decisions using incomplete request-origin information. The most likely business impact is unauthorized access to functionality that relies on forwarded-header checks, inaccurate security logs, weakened fraud or abuse controls, and loss of reliable request provenance. The public exploitation likelihood is currently low based on the available EPSS score, there is no known KEV listing, and no public exploit maturity is indicated, but the issue should still be fixed where Lambda@Edge deployments use Hono and trust forwarding headers.

How an attack unfolds

An attacker targets a Hono application deployed through AWS Lambda@Edge behind CloudFront. The attacker sends an HTTP request containing repeated forwarding-related headers, such as multiple `X-Forwarded-For`, `Forwarded`, or `Via` entries. CloudFront passes these duplicate headers to Lambda@Edge as separate header entries. In vulnerable Hono versions, the adapter processes the entries with overwrite behavior, so earlier values are discarded and only the final value is exposed to the application. If the application or middleware uses that visible value to decide whether a request comes from a trusted proxy, internal address, allowlisted source, or expected forwarding chain, the attacker may influence the decision by placing the desired value last. Successful exploitation depends on application-specific trust decisions and header handling, which is why the attack complexity is higher than a simple unauthenticated remote exploit.

How to fix it

Upgrade Hono to version 4.12.25 or later in every affected application and redeploy the Lambda@Edge function version associated with CloudFront. Because Lambda@Edge uses published function versions, ensure the fixed code is packaged, published as a new version, and associated with the relevant CloudFront distributions; updating only local dependencies or unpublished Lambda aliases is not sufficient. Regenerate and commit dependency lockfiles, rebuild deployment artifacts, and verify no older bundled copy of Hono remains. As defense in depth, avoid making authorization decisions directly from client-controllable forwarding headers, validate the complete forwarding chain, prefer trusted CloudFront-provided request attributes where possible, and normalize or reject duplicate security-sensitive headers at CloudFront, AWS WAF, or an edge middleware layer.

How to confirm the fix worked

Confirm the deployed dependency version is Hono 4.12.25 or later using package inventory, lockfile review, artifact inspection, or commands such as `npm ls hono`, `pnpm why hono`, or `yarn why hono`. Verify the active Lambda@Edge association points to a newly published function version containing the fixed dependency. Perform a controlled test by sending a request with repeated `X-Forwarded-For`, `Forwarded`, or `Via` headers and confirming application middleware receives the full expected header chain rather than only the final value. Review CloudFront distribution associations, Lambda deployment packages, CI build logs, and software composition analysis results to ensure no vulnerable Hono version remains in production artifacts.

Typical attack path

1. Identify a Hono application running on AWS Lambda@Edge behind CloudFront.
2. Determine whether the application uses forwarding headers for access control, rate limiting, logging, tenant routing, fraud checks, or audit decisions.
3. Send requests containing duplicate instances of security-relevant headers such as `X-Forwarded-For`, `Forwarded`, or `Via`.
4. Place the attacker-controlled value that should be trusted by the application as the final repeated header value.
5. Rely on the vulnerable adapter behavior to overwrite earlier header values and expose only the last value to Hono middleware or route handlers.
6. Access protected functionality, alter policy decisions, evade rate limits, or generate misleading audit records if the application trusts the truncated header value.

How to detect it

There is no unique post-exploitation artifact for this issue; detection depends on finding suspicious request patterns and policy outcomes. Review CloudFront real-time logs, AWS WAF logs, Lambda@Edge application logs, ALB or upstream logs if present, and any structured request-header telemetry for duplicate `X-Forwarded-For`, `Forwarded`, or `Via` headers in the same request. Prioritize requests to administrative, allowlisted, authenticated, rate-limited, or policy-protected endpoints. Look for cases where the final repeated header value is an allowlisted, private, loopback, or otherwise trusted address while earlier values are untrusted or inconsistent with the CloudFront `c-ip` or viewer address. Correlate successful access, reduced rate-limit enforcement, or unusual audit entries with requests containing repeated forwarding headers. If only normalized access logs are available, detection may be incomplete because the overwritten header values may not have been recorded by the vulnerable application.

• Repeated header in same request: X-Forwarded-For
• Repeated header in same request: Forwarded
• Repeated header in same request: Via
• X-Forwarded-For: 127.0.0.1
• X-Forwarded-For: localhost
• X-Forwarded-For: 10.
• X-Forwarded-For: 172.16.
• X-Forwarded-For: 172.17.
• X-Forwarded-For: 172.18.
• X-Forwarded-For: 172.19.
• X-Forwarded-For: 172.20.
• X-Forwarded-For: 172.21.
• X-Forwarded-For: 172.22.
• X-Forwarded-For: 172.23.
• X-Forwarded-For: 172.24.
• X-Forwarded-For: 172.25.
• X-Forwarded-For: 172.26.
• X-Forwarded-For: 172.27.
• X-Forwarded-For: 172.28.
• X-Forwarded-For: 172.29.
• X-Forwarded-For: 172.30.
• X-Forwarded-For: 172.31.
• X-Forwarded-For: 192.168.
• Forwarded: for=127.0.0.1
• Forwarded: for="127.0.0.1"
• Forwarded: for=localhost
• Forwarded: for=10.
• Forwarded: for=192.168.

What your security team should do

• Inventory Hono applications deployed on AWS Lambda@Edge and prioritize those that use `X-Forwarded-For`, `Forwarded`, `Via`, or similar headers for authorization, allowlisting, rate limiting, fraud controls, or audit logging.
• Upgrade all affected deployments to Hono 4.12.25 or later and redeploy published Lambda@Edge function versions associated with CloudFront.
• Add regression tests that send duplicate forwarding headers and verify the application receives and evaluates the complete header chain safely.
• Review application logic for unsafe trust of client-supplied forwarding headers and replace it with trusted edge metadata or strict proxy-chain validation.
• Add AWS WAF, CloudFront Function, or Lambda@Edge normalization rules to reject or canonicalize duplicate security-sensitive headers where business requirements allow.
• Search historical CloudFront, WAF, and application logs for requests containing duplicate forwarding headers, especially requests that reached protected paths or were accepted despite an unexpected source IP.
• Treat this as moderate urgency overall due to low current exploitation signals, but high priority for applications where forwarded headers directly affect access decisions.