CVE-2026-59897

What it actually does

In affected Hono versions 4.3.3 through versions before 4.12.27, the AWS API Gateway v1 adapter can incorrectly de-duplicate repeated request header values using substring matching instead of exact equality. When a request contains repeated headers with distinct values where one value is a substring of another, one value may be dropped before middleware or application code processes the request. The main technical risk is that application logic relying on complete header data, especially X-Forwarded-For or other proxy-derived headers, may make decisions using an incomplete client IP chain. This can weaken IP-based rate limiting, proxy-chain validation, audit logging, abuse detection, and access-control decisions that depend on forwarded header integrity.

Why it matters to the business

Applications using the affected Hono AWS API Gateway v1 adapter may record or evaluate incomplete request-origin information. In practice, this can make abusive traffic harder to attribute, allow some clients to evade IP-based controls, reduce the reliability of security logs, and complicate incident investigations. The CVSS and EPSS values indicate relatively low urgency compared with active exploitation vulnerabilities, and it is not listed in CISA KEV; however, internet-facing serverless APIs that rely on X-Forwarded-For for rate limiting, fraud detection, or allow/deny decisions should prioritize the fix because the business impact depends heavily on how much trust the application places in those headers.

How an attack unfolds

An attacker targets an application built with Hono and deployed behind AWS API Gateway v1 using the vulnerable adapter. The attacker crafts HTTP requests containing repeated header values, commonly focusing on X-Forwarded-For or other headers consumed by middleware. By choosing values where one distinct value is a substring of another, the vulnerable adapter may treat them as duplicates and remove one before the application sees the request. If downstream logic uses the resulting incomplete header chain for rate limiting, proxy validation, logging, or security decisions, the attacker may obscure the true request path, reduce logging fidelity, or bypass controls that depend on a complete set of header values. Exploitation requires the application to use the affected adapter and to make meaningful trust decisions based on these repeated headers, which is why practical exploitability is context-dependent.

How to fix it

Upgrade Hono to version 4.12.27 or later. If exact package management is used, ensure the resolved dependency version is at least 4.12.27, not just the top-level package constraint. Rebuild and redeploy affected serverless applications after upgrading. As compensating controls, avoid making security-critical decisions solely from client-supplied forwarded headers, normalize and validate forwarding headers at a trusted edge layer, prefer provider-supplied request context for source attribution where possible, and ensure rate limiting or access controls are enforced at a trusted gateway, WAF, or load-balancing layer rather than relying only on application-parsed headers.

How to confirm the fix worked

Confirm that deployed applications using the AWS API Gateway v1 adapter resolve Hono version 4.12.27 or later by checking lockfiles, build artifacts, and runtime dependency manifests. Test affected routes by sending repeated headers with distinct but substring-related values and verify that the application receives the complete set of expected header values after the upgrade. Review middleware behavior for X-Forwarded-For, rate limiting, audit logging, and proxy-chain validation to ensure they do not trust malformed or client-controlled forwarding data. Validate that production deployments were rebuilt after dependency updates and that no older bundled artifacts remain in use.

Typical attack path

1. Identify an internet-facing application using Hono on AWS API Gateway v1.
2. Probe how the application responds to forwarded headers such as X-Forwarded-For.
3. Send requests with repeated header values where one value is a substring of another value.
4. Cause the vulnerable adapter to drop one distinct header value during de-duplication.
5. Trigger middleware or application logic that evaluates the incomplete header set.
6. Attempt to evade IP-based rate limits, proxy-chain validation, audit accuracy, or other controls that depend on complete header data.

How to detect it

There is no public evidence in the provided data that this vulnerability is being actively exploited, and there are no universal post-exploitation artifacts because exploitation may only alter how request headers are interpreted. To assess possible prior abuse, review API Gateway access logs, application request logs, WAF logs, CDN logs, and rate-limiting logs for requests containing repeated X-Forwarded-For or other repeated security-relevant headers, especially where one value is a substring of another. Compare edge-layer logs against application-layer logs: exploitation may appear as a mismatch where the gateway or WAF recorded multiple forwarded header values but the application log recorded fewer values or a shortened proxy chain. Investigate bursts of requests that avoided expected rate limits, unusual client IP attribution changes, failed proxy-chain validation anomalies, or audit records with incomplete forwarded header chains. Pay particular attention to endpoints protected by IP-based controls, abuse prevention, fraud checks, administrative restrictions, or logging middleware that consumes X-Forwarded-For.

• X-Forwarded-For
• x-forwarded-for
• X-Forwarded-For: 1.1.1.1
• X-Forwarded-For: 1.1.1.10
• X-Forwarded-For: 10.0.0.1
• X-Forwarded-For: 10.0.0.10
• duplicate header
• repeated header
• AWS API Gateway v1
• hono
• @hono

What your security team should do

• Inventory applications using Hono with the AWS API Gateway v1 adapter, prioritizing internet-facing APIs.
• Upgrade Hono to 4.12.27 or later and redeploy affected applications.
• Review code paths that rely on X-Forwarded-For or repeated request headers for rate limiting, auditing, proxy validation, or access decisions.
• Move security-critical IP attribution and rate limiting to trusted infrastructure controls where feasible.
• Search historical access logs for suspicious repeated forwarded headers or malformed proxy-chain patterns.
• Add tests that verify repeated headers are handled exactly and are not de-duplicated by substring comparison.
• Because this issue is not in CISA KEV and has very low EPSS, schedule remediation according to exposure and dependence on header-based controls rather than emergency patching unless the application uses these headers for security decisions.