GHSA-26pp-8wgv-hjvm

What it actually does

The vulnerability is an improper input validation issue in Hono's setCookie() write path. When application code passes an untrusted or insufficiently constrained cookie name to setCookie(), affected versions of the hono npm package do not adequately validate that name before emitting a Set-Cookie header. At a technical level, this can allow malformed cookie names to influence HTTP response header construction, potentially causing cookie confusion, unexpected cookie creation or overwriting, response header manipulation, or application-specific security control bypasses where cookie names are derived from user-controlled input. The impact depends heavily on whether the application allows attacker-controlled values to reach the cookie name parameter.

Why it matters to the business

Applications using affected Hono versions may be exposed to session, authentication, or application-state integrity risks if they dynamically create cookies from user-controlled input. The CVSS score indicates moderate severity, and there is no current KEV listing or known mature public exploitation signal in the provided data; however, the issue has been public for 124 days, so affected internet-facing services and frameworks embedded in downstream applications should be updated during the next normal security patch cycle, with higher urgency for applications that set cookies based on request parameters, user profile fields, routing values, or other external input.

How an attack unfolds

An attacker first identifies an application built with an affected version of the Hono npm package and looks for functionality that causes the server to call setCookie() with a cookie name influenced by user input. This may occur in custom preference handling, tenant or feature flag cookies, localization settings, tracking identifiers, or other dynamic cookie creation logic. The attacker then submits a crafted value intended to produce an invalid or syntactically meaningful cookie name. If the application passes that value directly into setCookie(), the vulnerable library may emit a malformed Set-Cookie response header instead of rejecting the name. Depending on browser, proxy, and application behavior, the attacker may be able to create unexpected cookies, interfere with legitimate cookies, confuse downstream parsing, or alter application state. Successful exploitation is application-dependent and generally requires a vulnerable coding pattern in addition to the affected library version.

How to fix it

Upgrade the hono npm package to version 4.12.12 or later. For package-managed applications, update package.json and the corresponding lockfile, rebuild, test, and redeploy all affected services. In addition to upgrading, review application code for calls to setCookie() where the cookie name is derived from user input. Cookie names should be static constants wherever possible. If dynamic names are unavoidable, enforce an allowlist such as alphanumeric characters plus a small set of safe separators, reject control characters, whitespace, semicolons, commas, equals signs, quotes, backslashes, and newline characters, and add tests verifying invalid cookie names are rejected before reaching setCookie().

How to confirm the fix worked

Confirm that all deployed artifacts resolve hono to version 4.12.12 or later by checking npm lockfiles, software composition analysis output, container SBOMs, and runtime package inventories. Run npm ls hono or equivalent dependency tooling in each application repository and build context. Validate application behavior by exercising endpoints that set cookies and confirming malformed cookie names are rejected or never accepted from user input. Inspect HTTP responses to ensure Set-Cookie headers remain well formed and contain only expected cookie names. If static analysis is available, search for setCookie() calls and verify the first argument is a constant or validated value.

Typical attack path

1. Identify a web application or API implemented with Hono using an affected hono npm package version.
2. Find an endpoint or workflow that creates cookies dynamically, especially where the cookie name may come from request data, route parameters, query parameters, headers, form fields, or user-controlled profile data.
3. Submit crafted cookie-name input containing invalid or delimiter-like characters intended to affect Set-Cookie header behavior.
4. Observe the HTTP response for malformed, unexpected, duplicated, or attacker-influenced Set-Cookie headers.
5. Use the resulting cookie behavior to cause application-specific effects such as cookie confusion, state manipulation, or interference with authentication or preference cookies.

How to detect it

To determine whether exploitation was attempted or successful, focus on endpoints that set cookies and accept user-controlled values near the cookie-setting workflow. Review HTTP access logs, reverse proxy logs, WAF logs, and application logs for requests containing suspicious delimiter or control characters in query strings, path parameters, form fields, JSON bodies, or headers that could map to cookie names. Look for URL-encoded or raw characters such as semicolon, comma, equals sign, quotes, backslash, carriage return, line feed, tab, or other control characters. Inspect response logs, if available, for abnormal Set-Cookie headers, duplicated cookie names, cookie names containing invalid characters, unexpected additional cookies, or Set-Cookie headers that differ from the application's known cookie inventory. Search application error logs for cookie serialization, header validation, malformed header, or invalid character warnings. If packet capture, CDN logs, or synthetic browser telemetry are available, compare historical Set-Cookie values before and after suspicious requests. There are no unique attacker infrastructure indicators for this vulnerability; detection is primarily behavioral and application-specific.

• setCookie(
• Set-Cookie:
• %0d
• %0a
• %09
• %3b
• %2c
• %3d
• %22
• %27
• %5c
• \r
• \n
• ;
• Invalid character in header content
• malformed Set-Cookie
• invalid cookie name
• hono@4.12.11
• hono@4.12.10
• hono@4.12.9

What your security team should do

• Inventory applications and services that include the hono npm package and identify any versions earlier than 4.12.12.
• Prioritize remediation for internet-facing applications and any application that dynamically sets cookie names from request or user-controlled data.
• Upgrade hono to 4.12.12 or later, regenerate lockfiles, rebuild containers or serverless bundles, and redeploy.
• Review all setCookie() call sites to ensure cookie names are constants or strictly allowlisted before use.
• Add unit and integration tests for cookie-setting code paths to confirm invalid cookie names are rejected and Set-Cookie headers are well formed.
• Monitor web response logs, application logs, and WAF/proxy telemetry for unusual Set-Cookie behavior or requests containing delimiter/control characters in parameters that influence cookie creation.
• Because no KEV listing or mature exploitation signal is provided, treat this as moderate priority unless local code review shows attacker-controlled cookie names in sensitive authentication or session flows.