CVE-2026-47675

What it actually does

Hono versions prior to 4.12.21 do not consistently validate cookie option values before constructing a Set-Cookie header. The cookie serializer blocks header-syntax-breaking characters in domain and path, but not in sameSite or priority. If an application passes untrusted input into either of those options, an attacker can inject additional attacker-chosen cookie attributes into the response header. The impact is integrity-focused: cookie security properties may be weakened or altered, such as adding or overriding attributes that affect browser handling of the cookie. The issue does not by itself provide code execution, data disclosure, or service disruption, and exploitation depends on application code using user-controlled values for the affected options.

Why it matters to the business

Applications using vulnerable Hono cookie serialization may unintentionally issue cookies with attacker-influenced security attributes. In practical terms, this can weaken session or preference cookie protections, interfere with authentication flows, or create conditions that make other web attacks easier. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV or known ransomware use, but the fix is straightforward and should be prioritized for internet-facing applications, authentication services, and applications that dynamically set cookie options based on request data.

How an attack unfolds

An attacker first identifies an application built with a vulnerable Hono version that uses hono/cookie serialize() and allows user-controlled input to influence the sameSite or priority cookie options. The attacker then supplies a crafted value containing Set-Cookie attribute separators or header-control characters, such as semicolons or line breaks, depending on how the surrounding runtime and framework preserve or normalize the value. When the application serializes the cookie, the malicious value is inserted into the Set-Cookie header without the same validation applied to domain and path. The browser receives a cookie header containing additional attacker-selected attributes. Depending on the application design, this can alter cookie behavior, weaken protections intended to reduce cross-site request exposure, or manipulate cookie precedence and handling. Exploitation is application-dependent and typically requires a user or browser to trigger the vulnerable response path.

How to fix it

Upgrade Hono to version 4.12.21 or later wherever it is used. If exact dependency pinning is used, update the hono package to >=4.12.21 and regenerate lockfiles. If immediate upgrade is not possible, ensure sameSite and priority values are never derived directly from user-controlled input and enforce a strict allowlist before calling serialize(): sameSite should be limited to expected values such as Strict, Lax, or None, and priority should be limited to Low, Medium, or High. Reject or normalize any value containing semicolons, carriage returns, line feeds, or unexpected characters. Review all wrappers or helper functions that build Set-Cookie headers, because vulnerable use may be indirect through shared middleware or authentication utilities.

How to confirm the fix worked

Confirm all deployed applications and build artifacts resolve hono to version 4.12.21 or later by checking package manifests, lockfiles, software composition analysis results, and runtime container images. Add or run a unit/integration test that attempts to set sameSite or priority to a value containing ';', '\r', or '\n' and verifies that serialization rejects or safely handles the value rather than emitting additional Set-Cookie attributes. For running services, inspect HTTP responses from cookie-setting endpoints and verify that SameSite and Priority attributes contain only approved values and that no user-supplied text can introduce additional attributes into the Set-Cookie header.

Typical attack path

1. Identify a Hono-based application endpoint that sets cookies using hono/cookie serialize().
2. Determine whether sameSite or priority cookie options are influenced by request parameters, headers, form fields, route variables, or other untrusted input.
3. Submit a crafted value containing Set-Cookie attribute delimiters or control characters intended to append additional cookie attributes.
4. Cause the application to generate a Set-Cookie response using the malicious value.
5. Rely on the victim browser to process the modified Set-Cookie header and apply attacker-influenced cookie attributes.
6. Use the altered cookie behavior to support a broader attack, such as weakening session protections or manipulating browser cookie precedence.

How to detect it

To determine whether exploitation already occurred, focus on evidence of suspicious Set-Cookie responses from endpoints that dynamically set cookies. Useful sources include reverse proxy access logs with response headers enabled, CDN/WAF logs, application debug logs, APM HTTP traces, browser HAR captures, and packet captures from affected services. Look for Set-Cookie headers where SameSite or Priority contains unexpected delimiters, line breaks, URL-encoded line breaks, duplicated attributes, or values outside the normal allowlist. Also review application logs for requests containing parameters that appear to control cookie behavior, especially values containing semicolons, carriage returns, line feeds, or URL-encoded equivalents. Because exploitation is highly application-specific and may leave no durable server-side artifact unless response headers are logged, absence of evidence in standard access logs does not prove non-exploitation.

• Set-Cookie:
• SameSite=;
• SameSite=%3B
• SameSite=%0d
• SameSite=%0a
• SameSite=%0D
• SameSite=%0A
• Priority=;
• Priority=%3B
• Priority=%0d
• Priority=%0a
• Priority=%0D
• Priority=%0A
• SameSite=Strict; SameSite=
• SameSite=Lax; SameSite=
• SameSite=None; SameSite=
• Priority=Low; Priority=
• Priority=Medium; Priority=
• Priority=High; Priority=
• hono@4.12.20
• hono@4.12.19
• hono@4.12.18

What your security team should do

• Inventory applications and packages that depend on Hono, including transitive and bundled JavaScript dependencies.
• Prioritize upgrade to Hono 4.12.21 or later for internet-facing applications, identity/authentication components, and services that set session cookies.
• Search source code for calls to serialize(), setCookie(), or custom cookie helpers where sameSite or priority may be populated from request-controlled data.
• Add allowlist validation for cookie attributes at application boundaries, even after upgrading, to reduce future header-construction risk.
• Review web application logs and response captures for suspicious Set-Cookie headers containing unexpected SameSite or Priority values or extra injected attributes.
• Add regression tests for cookie serialization to ensure semicolons, carriage returns, and line feeds cannot alter Set-Cookie structure.
• Monitor dependency scanning tools for vulnerable hono versions and fail builds that introduce versions earlier than 4.12.21.