Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
4.8
Hono: Malicious Cookies Can Override Secure Cookies
GHSA-r5rp-j6wh-rvv4
CVE-2026-39410
Summary
A security issue in Hono's cookie handling code allows attackers to set malicious cookies that can override secure cookies, potentially leading to session hijacking or other security risks. Affected applications should update Hono to the latest version to prevent this issue. To protect against this vulnerability, ensure all cookies are set over a secure connection and use secure prefix protections.
What to do
- Update yusukebe hono to version 4.12.12.
Affected software
| Vendor | Product | Affected versions | Fix available |
|---|---|---|---|
| yusukebe | hono | <= 4.12.12 | 4.12.12 |
Original title
Hono: Non-breaking space prefix bypass in cookie name handling in getCookie()
Original description
## 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.
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.
ghsa CVSS3.1
4.8
Vulnerability type
CWE-20
Improper Input Validation
Published: 8 Apr 2026 · Updated: 8 Apr 2026 · First seen: 8 Apr 2026