chore(deps): update dependency hono to v4.12.14 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
hono (source)	4.12.7 → 4.12.14

GitHub Vulnerability Alerts

CVE-2026-39408

Summary

A path traversal issue in toSSG() allows files to be written outside the configured output directory during static site generation. When using dynamic route parameters via ssgParams, specially crafted values can cause generated file paths to escape the intended output directory.

Details

The static site generation process creates output files based on route paths derived from application routes and parameters. When ssgParams is used to provide values for dynamic routes, those values are used to construct output file paths. If these values contain traversal sequences (e.g. ..), the resulting output path may resolve outside the configured output directory. As a result, files may be written to unintended locations instead of being confined within the specified output directory.

For example:

import { Hono } from 'hono'
import { toSSG, ssgParams } from 'hono/ssg'

const app = new Hono()

app.get('/:id', ssgParams([{ id: '../pwned' }]), (c) => {
  return c.text('pwned')
})

toSSG(app, fs, { dir: './static' })

In this case, the generated output path may resolve outside ./static, resulting in a file being written outside the intended output directory.

Impact

An attacker who can influence values passed to ssgParams during the build process may be able to write files outside the intended output directory.

Depending on the build and deployment environment, this may:

• overwrite unintended files
• affect generated artifacts
• impact deployment outputs or downstream tooling

This issue is limited to build-time static site generation and does not affect request-time routing.

Severity

• CVSS Score: 5.9 / 10 (Medium)
• Vector String: CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

CVE-2026-39407

Summary

A path handling inconsistency in serveStatic allows protected static files to be accessed by using repeated slashes (//) in the request path.

When route-based middleware (e.g., /admin/*) is used for authorization, the router may not match paths containing repeated slashes, while serveStatic resolves them as normalized paths. This can lead to a middleware bypass.

Details

The routing layer and serveStatic handle repeated slashes differently.

For example:

/admin/secret.txt => matches /admin/*
/admin//secret.txt => may not match /admin/*

However, serveStatic may interpret both paths as the same file location (e.g., admin/secret.txt) and return the file.

This inconsistency allows a request such as:

GET //admin/secret.txt

to bypass middleware registered on /admin/* and access protected files.

The issue has been fixed by rejecting paths that contain repeated slashes, ensuring consistent behavior between route matching and static file resolution.

Impact

An attacker can access static files that are intended to be protected by route-based middleware by using repeated slashes in the request path.

This can lead to unauthorized access to sensitive files under the static root.

This issue affects applications that rely on serveStatic together with route-based middleware for access control.

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

CVE-2026-39409

Summary

ipRestriction() does not canonicalize IPv4-mapped IPv6 client addresses (e.g. ::ffff:127.0.0.1) before applying IPv4 allow or deny rules. In environments such as Node.js dual-stack, this can cause IPv4 rules to fail to match, leading to unintended authorization behavior.

Details

The middleware classifies client addresses based on their textual form. Addresses containing ":" are treated as IPv6, including IPv4-mapped IPv6 addresses such as ::ffff:127.0.0.1. These addresses are not normalized to IPv4 before matching.

As a result:

• IPv4 static rules (e.g. 127.0.0.1) do not match because the raw string differs
• IPv4 CIDR rules (e.g. 127.0.0.0/8, 10.0.0.0/8) are skipped because the address is treated as IPv6

For example, with:

denyList: ['127.0.0.1']

a request from 127.0.0.1 may be represented as ::ffff:127.0.0.1 and bypass the deny rule.

This behavior commonly occurs in Node.js environments where IPv4 clients are exposed as IPv4-mapped IPv6 addresses.

Impact

Applications that rely on IPv4-based ipRestriction() rules may incorrectly allow or deny requests.

In affected deployments, a denied IPv4 client may bypass access restrictions. Conversely, legitimate clients may be rejected when using IPv4 allow lists.

Severity

• CVSS Score: 6.3 / 10 (Medium)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

GHSA-26pp-8wgv-hjvm

Summary

Cookie names are not validated on the write path when using setCookie(), serialize(), or serializeSigned() to generate Set-Cookie headers.

While certain cookie attributes such as domain and path are validated, the cookie name itself may contain invalid characters.

This results in inconsistent handling of cookie names between parsing (read path) and serialization (write path).

Details

When applications use setCookie(), serialize(), or serializeSigned() with a user-controlled cookie name, invalid values (e.g., containing control characters such as \r or \n) can be used to construct malformed Set-Cookie header values.

For example:

Set-Cookie: legit
X-Injected: evil=value

However, in modern runtimes such as Node.js and Cloudflare Workers, such invalid header values are rejected and result in a runtime error before the response is sent.

As a result, the reported header injection / response splitting behavior could not be reproduced in these environments.

Impact

Applications that pass untrusted input as the cookie name to setCookie(), serialize(), or serializeSigned() may encounter runtime errors due to invalid header values.

In tested environments, malformed Set-Cookie headers are rejected before being sent, and the reported header injection behavior could not be reproduced.

This issue primarily affects correctness and robustness rather than introducing a confirmed exploitable vulnerability.

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

CVE-2026-39410

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.

Severity

• CVSS Score: 4.8 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

GHSA-458j-xx4x-4375

Summary

Improper handling of JSX attribute names in hono/jsx allows malformed attribute keys to corrupt the generated HTML output.

When untrusted input is used as attribute keys during server-side rendering, specially crafted keys can break out of attribute or tag boundaries and inject unintended HTML.

Details

When rendering JSX elements to HTML strings, attribute values are escaped, but attribute names (keys) were previously inserted into the output without validation.

If an attribute name contains characters such as ", >, or whitespace, it can alter the structure of the generated HTML.

For example, malformed attribute names can:

• Break out of the current attribute and introduce unintended additional attributes
• Break out of the current HTML tag and inject new elements into the output

This issue arises when untrusted input (such as query parameters or form data) is used as JSX attribute keys during server-side rendering.

Impact

An attacker who can control attribute keys used in JSX rendering may inject unintended attributes or HTML elements into the generated output.

This may lead to:

• Injection of unexpected HTML attributes
• Corruption of the HTML structure
• Potential cross-site scripting (XSS) if combined with unsafe usage patterns

This issue affects applications that pass untrusted input as JSX attribute keys during server-side rendering.

Severity

• CVSS Score: 4.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

---

Release Notes

honojs/hono (hono)

v4.12.14

Compare Source

Security fixes

This release includes fixes for the following security issues:

Improper handling of JSX attribute names in hono/jsx SSR

Affects: hono/jsx. Fixes missing validation of JSX attribute names during server-side rendering, which could allow malformed attribute keys to corrupt the generated HTML output and inject unintended attributes or elements. GHSA-458j-xx4x-4375

Other changes

• fix(aws-lambda): handle invalid header names in request processing (#​4883) fa2c74f

v4.12.13

Compare Source

v4.12.12

Compare Source

Security fixes

This release includes fixes for the following security issues:

Middleware bypass via repeated slashes in serveStatic

Affects: Serve Static middleware. Fixes a path normalization inconsistency where repeated slashes (//) could bypass route-based middleware protections and allow access to protected static files. GHSA-wmmm-f939-6g9c

Path traversal in toSSG() allows writing files outside the output directory

Affects: toSSG() for Static Site Generation. Fixes a path traversal issue where crafted ssgParams values could write files outside the configured output directory. GHSA-xf4j-xp2r-rqqx

Incorrect IP matching in ipRestriction() for IPv4-mapped IPv6 addresses

Affects: IP Restriction Middleware. Fixes improper handling of IPv4-mapped IPv6 addresses (e.g. ::ffff:127.0.0.1) that could cause allow/deny rules to be bypassed. GHSA-xpcf-pg52-r92g

Missing validation of cookie name on write path in setCookie()

Affects: setCookie(), serialize(), and serializeSigned() from hono/cookie. Fixes missing validation of cookie names on the write path, preventing inconsistent handling between parsing and serialization. GHSA-26pp-8wgv-hjvm

Non-breaking space prefix bypass in cookie name handling in getCookie()

Affects: getCookie() from hono/cookie. Fixes a discrepancy in cookie name handling that could allow attacker-controlled cookies to override legitimate ones and bypass prefix protections. GHSA-r5rp-j6wh-rvv4

---

Users who use Serve Static, Static Site Generation, Cookie utilities, or IP restriction middleware are strongly encouraged to upgrade to this version.

v4.12.11

Compare Source

What's Changed

• feat(css): add classNameSlug option to createCssContext by @​flow-pie in #​4834

New Contributors

• @​flow-pie made their first contribution in #​4834

Full Changelog: honojs/hono@v4.12.10...v4.12.11

v4.12.10

Compare Source

What's Changed

• test(router): fix Simple capturing group test by @​yusukebe in #​4838
• docs: fix impaired -> inspired typo in benchmark READMEs by @​Abhi3975 in #​4843
• fix(jsx/dom): apply select value after children are rendered by @​usualoma in #​4847
• fix(compress): convert strong ETag to weak ETag when compressing by @​usualoma in #​4848
• docs(ip-restriction): add clear JSDoc examples and param types by @​VISHNU7KASIREDDY in #​4851

New Contributors

• @​Abhi3975 made their first contribution in #​4843
• @​VISHNU7KASIREDDY made their first contribution in #​4851

Full Changelog: honojs/hono@v4.12.9...v4.12.10

v4.12.9

Compare Source

What's Changed

• fix(request): remove parseBody from bodyCache to prevent TypeError by @​yusukebe in #​4807
• feat(client): add PickResponseByStatusCode type by @​yusukebe in #​4791
• fix(ssg): pass SSG_CONTEXT to forGetInfoURLRequest by @​yuintei in #​4810
• fix(service-worker): make fire() fallback behavior consistent with handle() by @​yusukebe in #​4821
• fix(cors): reflect request origin when credentials is true with wildcard by @​ctonneslan in #​4813

New Contributors

• @​yuintei made their first contribution in #​4810
• @​ctonneslan made their first contribution in #​4813

Full Changelog: honojs/hono@v4.12.8...v4.12.9

v4.12.8

Compare Source

What's Changed

• fix(utils/mime): Normalize input extension to lowercase before MIME check by @​TheEssem in #​4800
• fix(bearer-auth): escape regex metacharacters in bearer auth prefix option by @​otoneko1102 in #​4750

New Contributors

• @​TheEssem made their first contribution in #​4800

Full Changelog: honojs/hono@v4.12.7...v4.12.8

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • ""
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

Deployment results

Worker	Alias	URL	Outcome
API	-	staging	success
CDN	-	staging	success
App	-	staging	success

---

Logs #24502797421