Hono: Non-breaking space prefix bypass in cookie name handling in getCookie()GHSA-r5rp-j6wh-rvv4
MEDIUMFix: honojs/hono@cc067c8GHSA-r5rp-j6wh-rvv4 is a medium-severity (CVSS 4.8) Improper Input Validation vulnerability in hono. A fix is available for hono — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-r5rp-j6wh-rvv4.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
hononpmDescription
Summary
A discrepancy between browser cookie parsing and parse() handling allows cookie prefix protections to be bypassed.
Cookie names that are treated as distinct by the browser may be normalized to the same key by parse(), allowing attacker-controlled cookies to override legitimate ones.
Details
Browsers follow RFC 6265bis and only trim SP (0x20) and HTAB (0x09) from cookie names. Other characters, such as the non-breaking space (U+00A0), are preserved as part of the cookie name.
For example, the browser treats the following cookies as distinct:
"dummy-cookie"
"\u00a0dummy-cookie"
However, parse() previously used JavaScript's trim(), which removes a broader set of characters including U+00A0. As a result, both names are normalized to:
"dummy-cookie"
This mismatch allows attacker-controlled cookies with a U+00A0 prefix to shadow or override legitimate cookies when accessed via getCookie().
Impact
An attacker who can set cookies (e.g., via a man-in-the-middle on a non-secure page or other injection vector) can bypass cookie prefix protections and override sensitive cookies.
This may lead to:
- Bypassing
__Secure-and__Host-prefix protections - Overriding cookies that rely on the Secure attribute
- Session fixation or session hijacking depending on application usage
This issue affects applications that rely on getCookie() for security-sensitive cookie handling.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | hono | all versions | 4.12.12npm install hono@4.12.12 |
Affected Products
honohonoDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for hono, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update hono to 4.12.12 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r5rp-j6wh-rvv4 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-r5rp-j6wh-rvv4 in your dependencies?
Find it across npm, including transitive dependencies.