Skip to content

fix(deps): update dependency hono to v4.12.25 [security]#559

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

fix(deps): update dependency hono to v4.12.25 [security]#559
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-hono-vulnerability

Conversation

@renovate

@renovate renovate Bot commented May 7, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
hono (source) 4.12.14 → 4.12.25 age confidence

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/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'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).

Hono: JWT middleware accepts any Authorization scheme, not only Bearer

CVE-2026-47673 / GHSA-f577-qrjj-4474

More information

Details

Summary

The jwt and jwk middlewares do not verify that the Authorization header value uses theBearer scheme. Any two-part header value — regardless of the scheme name in the first position — proceeds to JWT verification. A request presenting a valid JWT under a non-Bearer scheme identifier (such as Basic or Token) is authenticated identically to a correctly formed Bearer request.

Details

When processing an Authorization (or custom) header, the middleware splits the value on whitespace and uses the second token as the JWT to verify. It does not check that the first token is bearer (case-insensitively). RFC 6750 specifies that JWT bearer tokens must be presented using the Bearer scheme; other scheme identifiers carry distinct semantics and may be subject to different policies in network-layer security controls.

This discrepancy means that scheme-aware external controls — such as WAF rules, API gateways, or reverse proxies that apply policies specific to the Bearer scheme identifier — can be bypassed by presenting a valid JWT under a different scheme name.

This issue affects hono/jwt and hono/jwk middleware.

Impact

An attacker who possesses a valid JWT may present it under a non-Bearer scheme identifier and still pass middleware authentication.

This may lead to:

  • Bypass of network-layer security controls that inspect or filter requests based on the authorization scheme identifier
  • Token reuse across authentication schemes in applications that use multiple authorization mechanisms

This issue affects applications where hono/jwt or hono/jwk authentication is combined with external controls that enforce scheme-based access policies.

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: IP Restriction bypasses static deny rules for non-canonical IPv6

CVE-2026-47674 / GHSA-xrhx-7g5j-rcj5

More information

Details

Summary

The ip-restriction middleware (hono/ip-restriction) compares incoming IP addresses against configured deny and allow rules using string equality after partial normalization. Non-canonical IPv6 representations of an address already listed in a static rule — such as compressed forms, explicit-zero forms, or hex-notation IPv4-mapped addresses — do not match the normalized rule entry, causing the rule to be silently skipped.

Details

When the rule matcher is built, each configured IP rule is normalized to a canonical string form. Incoming IP addresses received at request time are then compared against those canonical strings without applying the same normalization. Because IPv6 permits multiple syntactically different representations of the same numeric address, a non-canonical form of a denied address fails the string lookup and proceeds to the CIDR check, which also finds no match for rules registered as static (no prefix length). The request is then allowed.

Affected non-canonical forms include:

  • Compressed versus expanded notation (2001:db8::1 vs 2001:db8:0:0:0:0:0:1)
  • Hex-notation IPv4-mapped addresses (::ffff:7f00:1 vs ::ffff:127.0.0.1)
  • Zone identifier suffixes (e.g., fe80::1%eth0)

Additionally, invalid IP address strings provided as the remote address are not rejected and may result in unexpected allow or deny behavior.

This issue arises when applications use ipRestriction() with static (non-CIDR) rules and the IP address source can supply addresses in non-canonical IPv6 form.

Impact

A request from an IP address covered by a static deny rule may bypass the restriction if the address is presented in a non-canonical IPv6 form.

This may lead to:

  • Unauthorized access to endpoints intended to be restricted to specific IP addresses
  • Bypass of IP-based access controls in environments where the runtime or an upstream proxy provides source addresses in a form that differs from the canonical form used in the rule configuration

This issue affects applications using hono/ip-restriction with static deny rules for IPv4 or IPv6 addresses, particularly when the source address is derived from proxy headers or custom getIP implementations that may return non-canonical forms.

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:L/A:N

References

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

Hono: Cookie helper does not sanitize sameSite and priority, allowing Set-Cookie injection

CVE-2026-47675 / GHSA-3hrh-pfw6-9m5x

More information

Details

Summary

The serialize() function in hono/cookie validates domain and path options against characters that corrupt Set-Cookie header syntax (;, \r, \n), but does not apply the same validation to sameSite and priority. An application that passes user-controlled input into either option may produce a Set-Cookie response header containing attacker-chosen additional attributes.

Details

When constructing a Set-Cookie header value, serialize() appends the sameSite and priority option values directly into the output string after a presentation-only transformation (capitalizing the first character). Although the TypeScript type signature constrains these options to specific string literals, that constraint is not enforced at runtime; any string value, including one containing ; or line-feed characters, passes through unchanged.

The validation guard that rejects ;, \r, and \n from domain and path is not applied to sameSite or priority. An application that passes a request-derived value to either option therefore provides an injection point into the header line.

This issue arises when an application passes user-controlled input to the sameSite or priority option of setCookie() or serialize().

Impact

An attacker who can control the sameSite or priority option value may inject additional attributes into a Set-Cookie response header.

This may lead to:

  • Cookie attribute injection — overriding Domain, Path, HttpOnly, Secure, or Max-Age for the affected cookie
  • HTTP response header injection on runtimes that do not strictly validate header values, enabling a second attacker-controlled Set-Cookie header in the same response

This issue affects applications that pass user-derived input into the sameSite or priority option of hono/cookie serialization functions.

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: app.mount() strips mount prefix using undecoded path, causing incorrect routing for percent-encoded paths

CVE-2026-47676 / GHSA-2gcr-mfcq-wcc3

More information

Details

Summary

app.mount() strips the mount prefix from the incoming request path using the raw URL pathname, while route matching is performed against the percent-decoded path. This inconsistency causes the prefix to be stripped at the wrong position when the path contains percent-encoded multi-byte characters, resulting in the mounted sub-application receiving an incorrect path.

Details

When app.mount(prefix, subApp) is called, Hono calculates the number of characters to strip based on the decoded mount prefix length, but then applies that slice to the raw URL pathname. When the URL contains percent-encoded characters that expand to fewer characters when decoded (such as encoded non-ASCII characters), the two representations have different lengths, so the prefix is stripped at the wrong byte offset.

As a result, the sub-application receives a path that does not correspond to the intended sub-path — it may receive a partial or garbled path instead of the expected value after the mount prefix is removed.

This issue arises when an application uses app.mount() with paths that contain percent-encoded characters, particularly when the mount prefix itself or the request path contains encoded non-ASCII characters.

Impact

A mounted sub-application may receive an incorrectly stripped path, causing requests to be routed to unintended handlers within the sub-application.

This may lead to:

  • Middleware or route handlers in the sub-application being bypassed or incorrectly matched due to the malformed path
  • Requests reaching sub-application routes that the developer did not intend to be accessible via the mounted path

This issue affects applications that use app.mount() where the request URL may contain percent-encoded characters in the mount prefix or subsequent path segments.

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: AWS Lambda adapter merges multiple Set-Cookie headers into one value, dropping cookies on ALB single-header and Lattice

CVE-2026-54287 / GHSA-j6c9-x7qj-28xf

More information

Details

Summary

On AWS Lambda, the ALB single-header response and the VPC Lattice v2 response join multiple Set-Cookie headers into one comma-separated value. Because commas also appear inside cookie attributes (for example Expires dates), clients cannot split the value back into individual cookies and silently drop or misparse them.

Details

Per RFC 6265, each cookie must be its own Set-Cookie header line, and commas may appear inside attribute values. Joining cookies with ", " collides with those commas, producing a value that clients cannot reliably split. Only ALB single-header mode and VPC Lattice v2 are affected; API Gateway v1/v2 and ALB with multi-value headers enabled already use an array and are unaffected.

Impact

A client may receive only one of the cookies, a malformed cookie, or none. Session, CSRF, or preference cookies can silently fail to apply, breaking sessions or forcing re-authentication. This affects applications that set multiple cookies per response and run on AWS Lambda behind an ALB in single-header mode (the default) or VPC Lattice v2.

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:L/A:N

References

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

hono: Path traversal in serve-static on Windows via encoded backslash (%5C)

CVE-2026-54286 / GHSA-wwfh-h76j-fc44

More information

Details

Summary

On Windows hosts, an encoded backslash (%5C) in the request path decodes to \, which the Windows path resolver treats as a separator. serve-static then resolves a single URL segment such as admin\secret.txt into a nested file under the root and serves it, letting an attacker read static files meant to be protected behind prefix-mounted middleware. Directory escape (..) remains blocked.

Details

The router splits paths only on /, so /admin%5Csecret.txt is one segment and middleware on /admin/* does not run. The serve-static guard rejects ./.. and consecutive separators but lets a lone \ through; on Windows the file resolver re-splits it into the protected subtree.

This affects Windows hosts serving static files via the Node, Bun, or Deno adapters that guard a static subtree with prefix-mounted middleware.

Impact

An unauthenticated attacker can read static files under a middleware-guarded prefix on Windows hosts. The read stays within the configured root; escape outside the root is not possible.

Severity

  • CVSS Score: 5.9 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/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: CORS Middleware reflects any Origin with credentials when origin defaults to the wildcard

CVE-2026-54290 / GHSA-88fw-hqm2-52qc

More information

Details

Summary

With credentials: true and no explicit origin (the default wildcard), the CORS Middleware reflects the request's Origin and sends Access-Control-Allow-Credentials: true. Any site can then make credentialed cross-origin requests and read the responses, exposing cookie-authenticated endpoints to arbitrary origins.

Details

The spec forbids Access-Control-Allow-Origin: * with credentials and browsers reject it, so this configuration used to fail closed. In affected versions the middleware reflects the request Origin instead, so it now succeeds for every origin, including null. The preflight also echoes the requested headers back, approving non-simple credentialed requests too.

This issue arises when an application enables credentials: true and leaves origin unset or set to the wildcard.

Impact

Any third-party page a logged-in user visits can read the application's cookie-authenticated endpoints and perform credentialed state-changing requests. This affects applications that enable credentialed CORS without restricting origin.

Severity

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

References

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

hono: Lambda@Edge adapter keeps only the last value of a repeated request header, dropping the rest

CVE-2026-54289 / GHSA-wgpf-jwqj-8h8p

More information

Details

Summary

On AWS Lambda@Edge, CloudFront delivers a request header that appears more than once as several separate entries. The adapter writes each value with Headers.set instead of Headers.append, so every value overwrites the previous one and only the last reaches the application. Repeated request headers such as X-Forwarded-For, Forwarded, and Via are silently truncated to a single value.

Details

A repeated request header carries an ordered list of values. The adapter iterates the list but overwrites on each step, keeping only the final value. Middleware that depends on the full list — for example IP restriction that walks the X-Forwarded-For chain, or auditing based on Forwarded/Via hops — receives incomplete data. The API Gateway adapter already appends repeated values and is not affected.

This issue arises only on Lambda@Edge deployments, for requests that contain the same header more than once.

Impact

Request middleware sees only the last value of a repeated header instead of the full chain. For applications that base access control on the X-Forwarded-For chain, this can weaken or alter that decision; for auditing, hop history is lost. This affects applications deployed on AWS Lambda@Edge that rely on multi-value request headers.

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: Body Limit Middleware can be bypassed on AWS Lambda by understating Content-Length

CVE-2026-54288 / GHSA-rv63-4mwf-qqc2

More information

Details

Summary

The Body Limit Middleware trusts the request's Content-Length header to decide whether a body is within the limit. On AWS Lambda (API Gateway v1/v2, ALB, VPC Lattice, and Lambda@Edge) the body is delivered fully buffered and the adapter builds the request with the client-declared Content-Length, which need not match the actual payload. A client can declare a tiny Content-Length while sending a much larger body, slipping past the limit.

Details

When Content-Length is present and Transfer-Encoding is absent, the middleware compares the declared value against the limit and passes the request through if it is small enough. On standards-based runtimes the transport enforces that Content-Length matches the body, so this is safe. The Lambda adapters instead reconstruct the request from a buffered payload and copy the client's Content-Length verbatim, so the declared length and the real body size are decoupled.

This issue affects applications deployed on AWS Lambda that rely on the Body Limit Middleware to cap request body size.

Impact

The declared body-size limit can be bypassed: a handler reads a payload larger than the configured maximum. Processing the oversized payload (large JSON, multipart, etc.) consumes additional CPU and memory per request. The payload remains bounded by the platform's request size limits, and Lambda isolates invocations, so the impact is increased per-request resource usage rather than full denial of service. This affects applications deployed on AWS Lambda that use the Body Limit Middleware.

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/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 OSV and 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 OSV and 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 OSV and 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 OSV and 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 OSV and the GitHub Advisory Database (CC-BY 4.0).

Hono: app.mount() strips mount prefix using undecoded path, causing incorrect routing for percent-encoded paths

CVE-2026-47676 / GHSA-2gcr-mfcq-wcc3

More information

Details

Summary

app.mount() strips the mount prefix from the incoming request path using the raw URL pathname, while route matching is performed against the percent-decoded path. This inconsistency causes the prefix to be stripped at the wrong position when the path contains percent-encoded multi-byte characters, resulting in the mounted sub-application receiving an incorrect path.

Details

When app.mount(prefix, subApp) is called, Hono calculates the number of characters to strip based on the decoded mount prefix length, but then applies that slice to the raw URL pathname. When the URL contains percent-encoded characters that expand to fewer characters when decoded (such as encoded non-ASCII characters), the two representations have different lengths, so the prefix is stripped at the wrong byte offset.

As a result, the sub-application receives a path that does not correspond to the intended sub-path — it may receive a partial or garbled path instead of the expected value after the mount prefix is removed.

This issue arises when an application uses app.mount() with paths that contain percent-encoded characters, particularly when the mount prefix itself or the request path contains encoded non-ASCII characters.

Impact

A mounted sub-application may receive an incorrectly stripped path, causing requests to be routed to unintended handlers within the sub-application.

This may lead to:

  • Middleware or route handlers in the sub-application being bypassed or incorrectly matched due to the malformed path
  • Requests reaching sub-application routes that the developer did not intend to be accessible via the mounted path

This issue affects applications that use app.mount() where the request URL may contain percent-encoded characters in the mount prefix or subsequent path segments.

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 OSV and the GitHub Advisory Database (CC-BY 4.0).

Hono: Cookie helper does not sanitize sameSite and priority, allowing Set-Cookie injection

CVE-2026-47675 / GHSA-3hrh-pfw6-9m5x

More information

Details

Summary

The serialize() function in hono/cookie validates domain and path options against characters that corrupt Set-Cookie header syntax (;, \r, \n), but does not apply the same validation to sameSite and priority. An application that passes user-controlled input into either option may produce a Set-Cookie response header containing attacker-chosen additional attributes.

Details

When constructing a Set-Cookie header value, serialize() appends the sameSite and priority option values directly into the output string after a presentation-only transformation (capitalizing the first character). Although the TypeScript type signature constrains these options to specific string literals, that constraint is not enforced at runtime; any string value, including one containing ; or line-feed characters, passes through unchanged.

The validation guard that rejects ;, \r, and \n from domain and path is not applied to sameSite or priority. An application that passes a request-derived value to either option therefore provides an injection point into the header line.

This issue arises when an application passes user-controlled input to the sameSite or priority option of setCookie() or serialize().

Impact

An attacker who can control the sameSite or priority option value may inject additional attributes into a Set-Cookie response header.

This may lead to:

  • Cookie attribute injection — overriding Domain, Path, HttpOnly, Secure, or Max-Age for the affected cookie
  • HTTP response header injection on runtimes that do not strictly validate header values, enabling a second attacker-controlled Set-Cookie header in the same response

This issue affects applications that pass user-derived input into the sameSite or priority option of hono/cookie serialization functions.

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 OSV and the GitHub Advisory Database (CC-BY 4.0).

Hono: JWT middleware accepts any Authorization scheme, not only Bearer

CVE-2026-47673 / GHSA-f577-qrjj-4474

More information

Details

Summary

The jwt and jwk middlewares do not verify that the Authorization header value uses theBearer scheme. Any two-part header value — regardless of the scheme name in the first position — proceeds to JWT verification. A request presenting a valid JWT under a non-Bearer scheme identifier (such as Basic or Token) is authenticated identically to a correctly formed Bearer request.

Details

When processing an Authorization (or custom) header, the middleware splits the value on whitespace and uses the second token as the JWT to verify. It does not check that the first token is bearer (case-insensitively). RFC 6750 specifies that JWT bearer tokens must be presented using the Bearer scheme; other scheme identifiers carry distinct semantics and may be subject to different policies in network-layer security controls.

This discrepancy means that scheme-aware external controls — such as WAF rules, API gateways, or reverse proxies that apply policies specific to the Bearer scheme identifier — can be bypassed by presenting a valid JWT under a different scheme name.

This issue affects hono/jwt and hono/jwk middleware.

Impact

An attacker who possesses a valid JWT may present it under a non-Bearer scheme identifier and still pass middleware authentication.

This may lead to:

  • Bypass of network-layer security controls that inspect or filter requests based on the authorization scheme identifier
  • Token reuse across authentication schemes in applications that use multiple authorization mechanisms

This issue affects applications where hono/jwt or hono/jwk authentication is combined with external controls that enforce scheme-based access policies.

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 OSV and the GitHub Advisory Database (CC-BY 4.0).

Hono: IP Restriction bypasses static de

✂ Note

PR body was truncated to here.

@renovate renovate Bot requested a review from tqer39 as a code owner May 7, 2026 05:53
@renovate renovate Bot enabled auto-merge (squash) May 7, 2026 05:53
@renovate renovate Bot added the security label May 7, 2026
renovate-approve-2[bot]
renovate-approve-2 Bot previously approved these changes May 7, 2026
View reviewed changes
renovate-approve[bot]
renovate-approve Bot previously approved these changes May 7, 2026
View reviewed changes
@renovate renovate Bot force-pushed the renovate/npm-hono-vulnerability branch from 80add90 to fd0a89d Compare May 9, 2026 04:46
@renovate renovate Bot changed the title fix(deps): update dependency hono to v4.12.16 [security] fix(deps): update dependency hono to v4.12.18 [security] May 9, 2026
renovate-approve[bot]
renovate-approve Bot previously approved these changes May 9, 2026
View reviewed changes
renovate-approve-2[bot]
renovate-approve-2 Bot previously approved these changes May 9, 2026
View reviewed changes
@renovate renovate Bot changed the title fix(deps): update dependency hono to v4.12.18 [security] fix(deps): update dependency hono to v4.12.21 [security] Jun 4, 2026
@renovate renovate Bot force-pushed the renovate/npm-hono-vulnerability branch from fd0a89d to b9bd8ac Compare June 4, 2026 20:56
renovate-approve[bot]
renovate-approve Bot previously approved these changes Jun 4, 2026
View reviewed changes
renovate-approve-2[bot]
renovate-approve-2 Bot previously approved these changes Jun 4, 2026
View reviewed changes
@renovate renovate Bot force-pushed the renovate/npm-hono-vulnerability branch from b9bd8ac to 0e074fe Compare June 16, 2026 20:33
@renovate renovate Bot changed the title fix(deps): update dependency hono to v4.12.21 [security] fix(deps): update dependency hono to v4.12.25 [security] Jun 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@renovate-approve renovate-approve[bot] renovate-approve[bot] approved these changes
@renovate-approve-2 renovate-approve-2[bot] renovate-approve-2[bot] approved these changes
@tqer39 tqer39 Awaiting requested review from tqer39 tqer39 is a code owner

Assignees

@renovate renovate[bot]

Labels

patch security

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@tqer39