Skip to content

build(deps): update dependency hono to v4.12.18 [security]#48

Open
renovate[bot] wants to merge 1 commit intomasterfrom
renovate/npm-hono-vulnerability
Open

build(deps): update dependency hono to v4.12.18 [security]#48
renovate[bot] wants to merge 1 commit intomasterfrom
renovate/npm-hono-vulnerability

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate Bot commented Mar 4, 2026 •
edited
Loading

This PR contains the following updates:

Package Change Age Confidence
hono (source) 4.12.2 → 4.12.18 age confidence

Hono vulnerable to arbitrary file access via serveStatic vulnerability

CVE-2026-29045 / GHSA-q5qw-h33p-qvwr

More information

Details

Summary

When using serveStatic together with route-based middleware protections (e.g. app.use('/admin/*', ...)), inconsistent URL decoding allowed protected static resources to be accessed without authorization.

The router used decodeURI, while serveStatic used decodeURIComponent. This mismatch allowed paths containing encoded slashes (%2F) to bypass middleware protections while still resolving to the intended filesystem path.

Details

The routing layer preserved %2F as a literal string, while serveStatic decoded it into / before resolving the file path.

Example:

Request: /admin%2Fsecret.html

  • Router sees: /admin%2Fsecret.html → does not match /admin/*
  • Static handler resolves: /admin/secret.html

As a result, static files under the configured static root could be served without triggering route-based protections.

This only affects applications that both:

  • Protect subpaths using route-based middleware, and
  • Serve files from the same static root using serveStatic.

This does not allow access outside the static root and is not a path traversal vulnerability.

Impact

An unauthenticated attacker could bypass route-based authorization for protected static resources by supplying paths containing encoded slashes.

Applications relying solely on route-based middleware to protect static subpaths may have exposed those resources.

Severity

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono Vulnerable to SSE Control Field Injection via CR/LF in writeSSE()

CVE-2026-29085 / GHSA-p6xx-57qc-3wxr

More information

Details

Summary

When using streamSSE() in Streaming Helper, the event, id, and retry fields were not validated for carriage return (\r) or newline (\n) characters.

Because the SSE protocol uses line breaks as field delimiters, this could allow injection of additional SSE fields within the same event frame if untrusted input was passed into these fields.

Details

The SSE helper builds event frames by joining lines with \n. While multi-line data: fields are handled according to the SSE specification, the event, id, and retry fields previously allowed raw values without rejecting embedded CR/LF characters.

Including CR/LF in these control fields could allow unintended additional fields (such as data:, id:, or retry:) to be injected into the event stream.

The issue has been fixed by rejecting CR/LF characters in these fields.

Impact

An attacker could manipulate the structure of SSE event frames if an application passed user-controlled input directly into event, id, or retry.

Depending on application behavior, this could result in injected SSE fields or altered event stream handling. Applications that render e.data in an unsafe manner (for example, using innerHTML) could potentially expose themselves to client-side script injection.

This issue affects applications that rely on the SSE helper to enforce protocol-level constraints.

Severity

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono Vulnerable to Cookie Attribute Injection via Unsanitized domain and path in setCookie()

CVE-2026-29086 / GHSA-5pq2-9x2x-5p6w

More information

Details

Summary

The setCookie() utility did not validate semicolons (;), carriage returns (\r), or newline characters (\n) in the domain and path options when constructing the Set-Cookie header.

Because cookie attributes are delimited by semicolons, this could allow injection of additional cookie attributes if untrusted input was passed into these fields.

Details

setCookie() builds the Set-Cookie header by concatenating option values. While the cookie value itself is URL-encoded, the domain and path options were previously interpolated without rejecting unsafe characters.

Including ;, \r, or \n in these fields could result in unintended additional attributes (such as SameSite, Secure, Domain, or Path) being appended to the cookie header.

Modern runtimes prevent full header injection via CRLF, so this issue is limited to attribute-level manipulation within a single Set-Cookie header.

The issue has been fixed by rejecting these characters in the domain and path options.

Impact

An attacker may be able to manipulate cookie attributes if an application passes user-controlled input directly into the domain or path options of setCookie().

This could affect cookie scoping or security attributes depending on browser behavior. Exploitation requires application-level misuse of cookie options.

Severity

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono vulnerable to Prototype Pollution possible through proto key allowed in parseBody({ dot: true })

GHSA-v8w9-8mx6-g223

More information

Details

Summary

When using parseBody({ dot: true }) in HonoRequest, specially crafted form field names such as __proto__.x could create objects containing a __proto__ property.

If the parsed result is later merged into regular JavaScript objects using unsafe merge patterns, this may lead to prototype pollution in the target object.

Details

The parseBody({ dot: true }) feature supports dot notation to construct nested objects from form field names.

In previous versions, the __proto__ path segment was not filtered. As a result, specially crafted keys such as __proto__.x could produce objects containing __proto__ properties.

While this behavior does not directly modify Object.prototype within Hono itself, it may become exploitable if the parsed result is later merged into regular JavaScript objects using unsafe merge patterns.

Impact

Applications that merge parsed form data into regular objects using unsafe patterns (for example recursive deep merge utilities) may become vulnerable to prototype pollution.

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

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

CVE-2026-39408 / GHSA-xf4j-xp2r-rqqx

More information

Details

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono: Middleware bypass via repeated slashes in serveStatic

CVE-2026-39407 / GHSA-wmmm-f939-6g9c

More information

Details

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono has incorrect IP matching in ipRestriction() for IPv4-mapped IPv6 addresses

CVE-2026-39409 / GHSA-xpcf-pg52-r92g

More information

Details

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono missing validation of cookie name on write path in setCookie()

GHSA-26pp-8wgv-hjvm

More information

Details

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

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

CVE-2026-39410 / GHSA-r5rp-j6wh-rvv4

More information

Details

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

hono Improperly Handles JSX Attribute Names Allows HTML Injection in hono/jsx SSR

GHSA-458j-xx4x-4375

More information

Details

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

hono/jsx has Unvalidated JSX Tag Names that May Allow HTML Injection

CVE-2026-44455 / GHSA-69xw-7hcm-h432

More information

Details

Summary

Improper handling of JSX element tag names in hono/jsx allowed unvalidated tag names to be directly inserted into the generated HTML output.

When untrusted input is used as a tag name via the programmatic jsx() or createElement() APIs during server-side rendering, specially crafted values may break out of the intended element context and inject unintended HTML.

Details

When rendering JSX elements to HTML strings, attribute values are escaped and attribute names are validated. However, element tag names were previously inserted into the output without validation.

If a tag name contains characters such as <, >, quotes, or whitespace, it may alter the structure of the generated HTML.

For example, malformed tag names can:

  • Break out of the intended element and introduce unintended HTML elements
  • Inject attributes or event handlers into the rendered output

This issue arises when untrusted input (such as query parameters or database content) is used as JSX tag names via jsx() or createElement() during server-side rendering.

Impact

An attacker who can control tag names used in JSX rendering may inject unintended HTML into the generated output.

This may lead to:

  • Injection of unexpected HTML elements or attributes
  • Corruption of the HTML structure
  • Cross-site scripting (XSS) when combined with unsafe usage patterns

This issue only affects applications that construct JSX tag names from untrusted input. Applications using static or allowlisted tag names are not affected.

Severity

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono: bodyLimit() can be bypassed for chunked / unknown-length requests

CVE-2026-44456 / GHSA-9vqf-7f2p-gf9v

More information

Details

Summary

bodyLimit() does not reliably enforce maxSize for requests without a usable Content-Length (e.g. Transfer-Encoding: chunked). Oversized requests can reach handlers and return 200 instead of 413.

Details

For chunked / unknown-length requests, bodyLimit() wraps the body in a stream that counts bytes asynchronously, then runs the handler before the size decision is final. The 413 is only applied afterwards by checking c.error.

This lets the limit be bypassed when:

  • the handler does not read the body,
  • the handler reads only the first chunk(s) and returns, or
  • the handler reads the body but swallows the read error in try/catch.

In all three cases the handler returns 200 before the limit check completes (or its result is observed).

The fix is to enforce the size decision before next() runs, instead of retrofitting the response via c.error afterwards.

Impact

Applications relying on bodyLimit() as a hard boundary can be bypassed: oversized chunked requests can reach handler logic and return successful responses. Per-request data exposure is bounded by maxSize, but the documented guarantee — "oversized requests are rejected before business logic runs" — does not hold.

Credits
  • @​lalalala5678 (slow chunked / early return variants)
  • @​Jvr2022 (error handling bypass)

Severity

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono's Cache Middleware ignores Vary: Authorization / Vary: Cookie leading to cross-user cache leakage

CVE-2026-44457 / GHSA-p77w-8qqv-26rm

More information

Details

Summary

Cache Middleware does not skip caching for responses that declare per-user variance via Vary: Authorization or Vary: Cookie. As a result, a response cached for one authenticated user may be served to subsequent requests from different users.

Details

The Cache Middleware skips caching when a response carries Vary: *, certain Cache-Control directives (private, no-store, no-cache), or Set-Cookie. However, Vary: Authorization and Vary: Cookie — the standard signals defined in RFC 9110 / RFC 9111 to indicate per-user responses — are not treated as cache-skip reasons.

This issue arises when applications use the Cache Middleware on endpoints that return user-specific data and rely on Vary: Authorization or Vary: Cookie to scope the response per user, without also setting Cache-Control: private.

Impact

A user may receive a cached response that was originally generated for a different authenticated user. This may lead to:

  • Disclosure of personally identifiable information or other user-specific data present in the response body
  • Inconsistent or incorrect behavior in user-specific endpoints

This issue affects applications that use the Cache Middleware on endpoints whose responses vary by Authorization or Cookie and that do not also set Cache-Control: private.

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono has improper validation of NumericDate claims (exp, nbf, iat) in JWT verify()

CVE-2026-44459 / GHSA-hm8q-7f3q-5f36

More information

Details

Summary

Improper validation of the JWT NumericDate claims exp, nbf, and iat in hono/utils/jwt allows tokens with non-spec-compliant claim values to silently bypass time-based checks. This issue is not exploitable by an anonymous attacker; it only manifests when a malformed claim value reaches verify() — typically when the application itself issues such tokens, or when the signing key is otherwise under attacker control.

Details

The validation routine combined option, presence, and threshold checks in a single short-circuiting expression, so several classes of malformed values were silently skipped instead of rejected:

  • A falsy numeric value short-circuited the presence check.
  • A non-finite numeric value compared as never-after-now and never-expired.
  • A non-numeric type produced NaN comparisons that evaluated false.

This deviates from RFC 7519 §4.1.4, which defines NumericDate as a finite JSON numeric value.

Impact

An actor able to issue tokens accepted by the application may craft tokens whose exp, nbf, or iat claims silently bypass time-based enforcement. This may lead to:

  • Tokens treated as never expiring even with exp configured on the verifier.
  • Tokens with a future nbf accepted as currently valid.
  • Tokens with a future iat accepted as legitimately issued.

Deployments using a well-formed token issuer and protecting the signing key are not affected.

Severity

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Hono has CSS Declaration Injection via Style Object Values in JSX SSR

CVE-2026-44458 / GHSA-qp7p-654g-cw7p

More information

Details

Summary

The JSX renderer escapes style attribute object values for HTML but not for CSS. Untrusted input in a style object value or property name can therefore inject additional CSS declarations into the rendered style attribute. The impact is limited to CSS and does not allow JavaScript execution or HTML attribute breakout.

Details

style object values are serialized into a CSS declaration list and escaped for HTML attribute context only. Characters that act as CSS declaration boundaries — such as ;, comment markers, quoted strings, and block delimiters — are valid in HTML attribute content and can extend a value beyond its assigned property.

This issue arises when untrusted input is interpolated into a JSX style object and rendered server-side.

Impact

An attacker who can control the value or property name of a style object may inject arbitrary CSS declarations. This may lead to:

  • Visual manipulation of the page, including full-viewport overlays usable for phishing
  • Outbound requests to attacker-controlled hosts via CSS resource references such as url(...)
  • Hijacking of UI affordances through layout, positioning, or visibility changes

This issue affects applications that render JSX on the server with style object values or property names derived from untrusted input.

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

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

honojs/hono (hono)

v4.12.18

Compare Source

v4.12.17

Compare Source

v4.12.16

Compare Source

Security fixes

This release includes fixes for the following security issues:

Unvalidated JSX Tag Names in hono/jsx May Allow HTML Injection

Affects: hono/jsx. Fixes missing validation of JSX tag names when using jsx() or createElement(), which could allow HTML injection if untrusted input is used as the tag name. GHSA-69xw-7hcm-h432

bodyLimit() can be bypassed for chunked / unknown-length requests

Affects: Body Limit Middleware. Fixes late enforcement for request bodies without a reliable Content-Length (e.g. chunked requests), where oversized requests could reach handlers and return successful responses before being rejected. GHSA-9vqf-7f2p-gf9v

v4.12.15

Compare Source

What's Changed
New Contributors

Full Changelog: honojs/hono@v4.12.14...v4.12.15

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

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.12.12...v4.12.13

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
New Contributors

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

v4.12.10

Compare Source

What's Changed

New Contributors

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

v4.12.9

Compare Source

What's Changed

New Contributors

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

v4.12.8

Compare Source

What's Changed

New Contributors

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

v4.12.7

Compare Source

Security hardening

Ignore __proto__ path segments in parseBody({ dot: true }) to prevent potential prototype pollution when merged with unsafe patterns.

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

v4.12.6

Compare Source

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.12.5...v4.12.6

v4.12.5

Compare Source

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.12.4...v4.12.5

v4.12.4

Compare Source

Security fixes

This release includes fixes for the following security issues:

SSE Control Field Injection

Affects: streamSSE() in Streaming Helper. Fixes injection of unintended SSE fields by rejecting CR/LF characters in event, id, and retry. GHSA-p6xx-57qc-3wxr

Cookie Attribute Injection in setCookie()

Affects: setCookie() from hono/cookie. Fixes cookie attribute manipulation by rejecting ;, \r, and \n in domain and path options. GHSA-5pq2-9x2x-5p6w

Middleware Bypass in Serve Static

Affects: Serve Static middleware. Fixes inconsistent URL decoding that could allow protected static resources to be accessed without triggering route-based middleware. GHSA-q5qw-h33p-qvwr

Users who uses Strreaming Helper, Cookie utility, and Serve Static are strongly encouraged to upgrade to this version.

Other changes

New Contributors

Full Changelog: honojs/hono@v4.12.3...v4.12.4

v4.12.3

Compare Source

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.12.2...v4.12.3

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.

@renovate renovate Bot force-pushed the renovate/npm-hono-vulnerability branch from cab9247 to 99ad34a Compare March 11, 2026 05:27
@renovate renovate Bot changed the title build(deps): update dependency hono to v4.12.4 [security] build(deps): update dependency hono to v4.12.7 [security] Mar 11, 2026
@renovate renovate Bot changed the title build(deps): update dependency hono to v4.12.7 [security] build(deps): update dependency hono to v4.12.7 [security] - autoclosed Mar 27, 2026
@renovate renovate Bot closed this Mar 27, 2026
@renovate renovate Bot deleted the renovate/npm-hono-vulnerability branch March 27, 2026 04:54
@renovate renovate Bot changed the title build(deps): update dependency hono to v4.12.7 [security] - autoclosed build(deps): update dependency hono to v4.12.7 [security] Mar 30, 2026
@renovate renovate Bot reopened this Mar 30, 2026
@renovate renovate Bot force-pushed the renovate/npm-hono-vulnerability branch 2 times, most recently from 99ad34a to fde794d Compare March 30, 2026 20:50
@renovate renovate Bot changed the title build(deps): update dependency hono to v4.12.7 [security] build(deps): update dependency hono to v4.12.12 [security] Apr 8, 2026
@renovate renovate Bot force-pushed the renovate/npm-hono-vulnerability branch from fde794d to 7aab626 Compare April 8, 2026 05:09
@renovate renovate Bot force-pushed the renovate/npm-hono-vulnerability branch from 7aab626 to eaa3719 Compare April 16, 2026 09:08
@renovate renovate Bot changed the title build(deps): update dependency hono to v4.12.12 [security] build(deps): update dependency hono to v4.12.14 [security] Apr 16, 2026
@renovate renovate Bot changed the title build(deps): update dependency hono to v4.12.14 [security] build(deps): update dependency hono to v4.12.14 [security] - autoclosed Apr 27, 2026
@renovate renovate Bot closed this Apr 27, 2026
@renovate renovate Bot changed the title build(deps): update dependency hono to v4.12.14 [security] - autoclosed build(deps): update dependency hono to v4.12.14 [security] Apr 27, 2026
@renovate renovate Bot reopened this Apr 27, 2026
@renovate renovate Bot force-pushed the renovate/npm-hono-vulnerability branch 2 times, most recently from eaa3719 to efee30e Compare April 27, 2026 22:46
@renovate renovate Bot changed the title build(deps): update dependency hono to v4.12.14 [security] build(deps): update dependency hono to v4.12.16 [security] May 8, 2026
@renovate renovate Bot force-pushed the renovate/npm-hono-vulnerability branch from efee30e to 2ded126 Compare May 8, 2026 14:02
@renovate renovate Bot changed the title build(deps): update dependency hono to v4.12.16 [security] build(deps): update dependency hono to v4.12.18 [security] May 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants