CVE-2026-39410

What it actually does

Hono versions prior to 4.12.12 parse browser-supplied Cookie headers differently than browsers enforce cookie-name prefix rules. An attacker who can cause a victim browser to store and send a crafted cookie can create cookie names that the browser treats as separate from protected cookies, but Hono's parse() logic normalizes or resolves to the same application key. If an application relies on parsed cookies for authentication, session selection, CSRF state, tenant/user preferences, or authorization-related flags, the attacker-controlled cookie may override the legitimate value. The likely impact is limited confidentiality and integrity compromise; availability is not directly affected. Exploitation is network-reachable but higher complexity because the attacker usually needs a way to plant or influence cookies for the target site or an associated domain/subdomain.

Why it matters to the business

Applications using affected Hono versions may make trust decisions based on attacker-controlled cookie values instead of legitimate protected cookies. In practical terms, this can lead to account/session confusion, bypass of some client-side cookie hardening assumptions, unauthorized changes to user state, or weakening of CSRF/session protections in affected applications. The CVSS score is moderate and EPSS is low, and it is not listed in CISA KEV, but Hono is a widely used JavaScript web framework, so organizations should still prioritize upgrading internet-facing and authentication-sensitive services.

How an attack unfolds

An attacker first identifies an application built with a vulnerable Hono release that uses cookies parsed by Hono for a security-sensitive purpose. The attacker then finds a way to make the victim browser store an attacker-controlled cookie, such as through a related subdomain, response-header injection, cross-site scripting, misconfigured cookie scope, or another application under the same site boundary. The crafted cookie name is chosen so the browser considers it distinct from the legitimate protected cookie, while Hono's parse() handling maps it to the same key or lets it override the legitimate parsed value. When the victim later sends both cookies to the application, the vulnerable parser returns the attacker-controlled value to application code. The application may then make authentication, CSRF, session, or authorization decisions using the wrong cookie value, enabling data exposure or unauthorized actions depending on how the application uses that cookie.

How to fix it

Upgrade Hono to version 4.12.12 or later everywhere it is used, including direct dependencies, transitive bundles, serverless functions, edge deployments, containers, and lockfiles. Rebuild and redeploy affected JavaScript applications after updating the dependency. If immediate upgrade is not possible, add request validation that rejects ambiguous, duplicate, malformed, or normalized-colliding cookie names before application logic reads them; avoid relying solely on cookie-name prefixes for security; require server-side validation for session identifiers and CSRF tokens; use signed or encrypted cookies where appropriate; and limit the ability of subdomains or adjacent applications to set cookies for the parent site. Review applications for any security-sensitive logic that trusts parsed cookie values without additional verification.

How to confirm the fix worked

Confirm the deployed dependency version is Hono 4.12.12 or later using package-lock.json, pnpm-lock.yaml, yarn.lock, npm ls hono, pnpm why hono, yarn why hono, or equivalent software composition analysis tooling. Verify that rebuilt artifacts, containers, and serverless/edge deployments contain the updated package rather than only an updated source tree. Add regression tests that submit requests containing legitimate protected cookies plus crafted ambiguous or duplicate cookie names and confirm the application either rejects the request or uses only the intended legitimate value. For internet-facing services, use DAST or targeted HTTP tests to confirm ambiguous Cookie headers do not alter authentication, CSRF, or authorization behavior.

Typical attack path

1. Identify a Hono-based application running a version earlier than 4.12.12.
2. Determine whether the application uses parsed cookie values for authentication, session state, CSRF tokens, authorization flags, or other trust decisions.
3. Gain a method to set or influence cookies in the victim browser for the target site or a related domain/subdomain.
4. Plant a crafted cookie whose name bypasses browser-enforced prefix assumptions but collides or overrides after Hono parse() handling.
5. Wait for or induce the victim to send the crafted and legitimate cookies in the same request.
6. Cause the application to consume the attacker-controlled parsed cookie value.
7. Use the resulting session, CSRF, or state confusion to access information or perform unauthorized actions within the limits of the affected application logic.

How to detect it

Review HTTP request telemetry from CDN, WAF, reverse proxy, load balancer, and application logs for raw Cookie headers containing duplicate, ambiguous, malformed, or visually similar cookie names, especially where protected cookie names such as __Host- or __Secure- appear alongside variants. Correlate suspicious Cookie headers with authentication logs, session creation or rotation events, CSRF validation failures, unexpected privilege changes, account-switching symptoms, or user reports of being logged in as the wrong session. Also review Set-Cookie sources from related subdomains or adjacent applications that could have planted attacker-controlled cookies. Because many environments do not log raw Cookie headers by default and cookies may contain sensitive data, exploitation may be difficult to prove retrospectively; prioritize metadata, cookie names, request paths, source IPs, user agents, and authentication outcomes rather than storing full cookie values unless required for incident response.

• Cookie: .*__Host-.*; .*__Host-
• Cookie: .*__Secure-.*; .*__Secure-
• Cookie: .*(__Host-|__Secure-).*; .*\1
• Set-Cookie: .*__Host-
• Set-Cookie: .*__Secure-
• Cookie: .*[Cc]srf.*; .*[Cc]srf
• Cookie: .*[Ss]ession.*; .*[Ss]ession
• Cookie: .*%5f%5fHost-
• Cookie: .*%5f%5fSecure-
• Cookie: .*__Host-.*Domain=

What your security team should do

• Inventory all applications and packages that use Hono and identify deployments running versions earlier than 4.12.12.
• Prioritize patching internet-facing services and applications where cookies influence authentication, authorization, CSRF, session routing, or user identity.
• Upgrade to Hono 4.12.12 or later, refresh lockfiles, rebuild artifacts, and redeploy all affected services.
• Review cookie-handling code for assumptions that browser cookie prefixes alone prevent attacker-controlled cookie values from reaching server-side logic.
• Add application or edge-layer validation to reject duplicate, malformed, or ambiguous cookie names, especially around protected prefixes such as __Host- and __Secure-.
• Search recent web, CDN, WAF, and application logs for requests containing duplicate or suspiciously similar cookie names, protected cookie prefixes, and abnormal authentication or CSRF outcomes.
• Ensure raw Cookie headers are captured in a privacy-conscious way for security investigations where legally and operationally appropriate.
• Monitor dependency advisories and SCA results for Hono and related JavaScript web framework packages.