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

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
hono (source)	4.12.14 → 4.12.18

---

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

• https://github.com/honojs/hono/security/advisories/GHSA-9vqf-7f2p-gf9v
• https://github.com/advisories/GHSA-9vqf-7f2p-gf9v

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

• https://github.com/honojs/hono/security/advisories/GHSA-69xw-7hcm-h432
• https://github.com/advisories/GHSA-69xw-7hcm-h432

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

• https://github.com/honojs/hono/security/advisories/GHSA-p77w-8qqv-26rm
• https://github.com/advisories/GHSA-p77w-8qqv-26rm

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

• https://github.com/honojs/hono/security/advisories/GHSA-hm8q-7f3q-5f36
• https://github.com/advisories/GHSA-hm8q-7f3q-5f36

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

• https://github.com/honojs/hono/security/advisories/GHSA-qp7p-654g-cw7p
• https://github.com/advisories/GHSA-qp7p-654g-cw7p

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

• https://github.com/honojs/hono/security/advisories/GHSA-69xw-7hcm-h432
• https://github.com/honojs/hono

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

• https://github.com/honojs/hono/security/advisories/GHSA-9vqf-7f2p-gf9v
• https://github.com/honojs/hono

This data is provided by OSV and 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

• fix(jwt): support single-line PEM keys by @​hiendv in #​4889

New Contributors

• @​hiendv made their first contribution in #​4889

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

---

Configuration

📅 Schedule: (in timezone Europe/Copenhagen)

• 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.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	hono@​4.12.14 ⏵ 4.12.18	+1	+6	+1

View full report