Skip to content

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented Jan 14, 2026

This PR contains the following updates:

Package Change Age Confidence
hono (source) 4.11.34.11.7 age confidence

Hono JWK Auth Middleware has JWT algorithm confusion when JWK lacks "alg" (untrusted header.alg fallback)

CVE-2026-22818 / GHSA-3vhc-576x-3qv4

More information

Details

Summary

A flaw in Hono’s JWK/JWKS JWT verification middleware allowed the algorithm specified in the JWT header to influence signature verification when the selected JWK did not explicitly define an algorithm. This could enable JWT algorithm confusion and, in certain configurations, allow forged tokens to be accepted.

Details

When verifying JWTs using JWKs or a JWKS endpoint, the middleware selected the verification algorithm based on the JWK’s alg field if present. If the JWK did not specify an algorithm, the middleware fell back to using the alg value provided in the unverified JWT header.

Because the alg field in a JWK is optional and commonly omitted in real-world JWKS configurations, this behavior could allow an attacker to influence which algorithm is used for verification. In some environments, this may result in authentication or authorization bypass through crafted JWTs.

The practical impact depends on application configuration, including which algorithms are accepted and how JWTs are used to make authorization decisions.

Impact

In affected configurations, an attacker may be able to forge JWTs with attacker-controlled claims, potentially leading to authentication or authorization bypass.

Applications that do not use the JWK/JWKS middleware, do not rely on JWT-based authentication, or explicitly restrict allowed algorithms are not affected.

Resolution

Update to the latest patched release.

Breaking change:

The JWK/JWKS JWT verification middleware has been updated to require an explicit allowlist of asymmetric algorithms when verifying tokens. The middleware no longer derives the verification algorithm from untrusted JWT header values.

Instead, callers must explicitly specify which asymmetric algorithms are permitted, and only tokens signed with those algorithms will be accepted. This prevents JWT algorithm confusion by ensuring that algorithm selection is fully controlled by application
configuration.

As part of this fix, the alg option is now required when using the JWK/JWKS middleware, and symmetric (HS*) algorithms are no longer accepted in this context.

Before (vulnerable configuration)
import { jwk } from 'hono/jwk'

app.use(
  '/auth/*',
  jwk({
    jwks_uri: 'https://example.com/.well-known/jwks.json',
    // alg was optional
  })
)
After (patched configuration)
import { jwk } from 'hono/jwk'

app.use(
  '/auth/*',
  jwk({
    jwks_uri: 'https://example.com/.well-known/jwks.json',
    alg: ['RS256'], // required: explicit asymmetric algorithm allowlist
  })
)

Severity

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

References

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


Hono IPv4 address validation bypass in IP Restriction Middleware allows IP spoofing

CVE-2026-24398 / GHSA-r354-f388-2fhh

More information

Details

Summary

IP Restriction Middleware in Hono is vulnerable to an IP address validation bypass. The IPV4_REGEX pattern and convertIPv4ToBinary function in src/utils/ipaddr.ts do not properly validate that IPv4 octet values are within the valid range of 0-255, allowing attackers to craft malformed IP addresses that bypass IP-based access controls.

Details

The vulnerability exists in two components:

  1. Permissive regex pattern: The IPV4_REGEX (/^[0-9]{0,3}\.[0-9]{0,3}\.[0-9]{0,3}\.[0-9]{0,3}$/) accepts octet values greater than 255 (e.g., 999).
  2. Unsafe binary conversion: The convertIPv4ToBinary function does not validate octet ranges before performing bitwise operations. When an octet exceeds 255, it overflows into adjacent octets during the bit-shift calculation.

For example, the IP address 1.2.2.355 is accepted and converts to the same binary value as 1.2.3.99:

  • 355 = 256 + 99 = 0x163
  • After bit-shifting: (1 << 24) + (2 << 16) + (2 << 8) + 355 = 0x01020363 = 1.2.3.99
Impact

An attacker can bypass IP-based restrictions by crafting malformed IP addresses:

  • Blocklist bypass: If 1.2.3.0/24 is blocked, an attacker can use 1.2.2.355 (or similar) to bypass the restriction.
  • Allowlist bypass: Requests from unauthorized IP ranges may be incorrectly permitted.

This is exploitable when the application relies on client-provided IP addresses (e.g., X-Forwarded-For header) for access control decisions.

Affected Components
  • IP Restriction Middleware
  • src/utils/ipaddr.ts: IPV4_REGEX, convertIPv4ToBinary, distinctRemoteAddr

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 has an Arbitrary Key Read in Serve static Middleware (Cloudflare Workers Adapter)

CVE-2026-24473 / GHSA-w332-q679-j88p

More information

Details

Summary

Serve static Middleware for the Cloudflare Workers adapter contains an information disclosure vulnerability that may allow attackers to read arbitrary keys from the Workers environment. Improper validation of user-controlled paths can result in unintended access to internal asset keys.

Details

The vulnerability exists in the serve-static middleware used with the Cloudflare Workers adapter. When serving static assets, the middleware does not sufficiently validate or restrict user-supplied paths before resolving them against the Workers asset storage.

As a result, an attacker may craft requests that access arbitrary keys beyond the intended static asset scope. This issue only affects applications running on Cloudflare Workers that use Serve static Middleware with user-controllable request paths.

Impact

This vulnerability may lead to information disclosure by allowing unauthorized access to internal assets or data stored in the Workers environment. The exposed data is limited to readable asset keys and does not allow modification of stored data or execution of arbitrary code.

The impact is limited to applications that use Serve static Middleware in the Cloudflare Workers adapter and rely on it to safely handle untrusted request paths.

Affected Components
  • Serve static Middleware (Cloudflare Workers adapter)

Severity

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

References

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


Hono vulnerable to XSS through ErrorBoundary component

CVE-2026-24771 / GHSA-9r54-q6cx-xmh5

More information

Details

Summary

A Cross-Site Scripting (XSS) vulnerability exists in the ErrorBoundary component of the hono/jsx library. Under certain usage patterns, untrusted user-controlled strings may be rendered as raw HTML, allowing arbitrary script execution in the victim's browser.

Details

The issue is in the ErrorBoundary component (src/jsx/components.ts). ErrorBoundary previously forced certain rendered output paths to be treated as raw HTML, bypassing the library's default escaping behavior. This could result in unescaped rendering when developers pass user-controlled strings directly as children, or when fallbackRender returns user-controlled strings (for example, reflecting error messages that contain attacker input).

This vulnerability is only exploitable when an application renders untrusted user input within ErrorBoundary without appropriate escaping or sanitization.

Impact

Successful exploitation may allow attackers to execute arbitrary JavaScript in the victim’s browser (reflected XSS). Depending on the application context, this can lead to actions such as session compromise, data exfiltration, or performing unauthorized actions as the victim.

Affected Components
  • hono/jsx: ErrorBoundary component

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 cache middleware ignores "Cache-Control: private" leading to Web Cache Deception

CVE-2026-24472 / GHSA-6wqw-2p9w-4vw4

More information

Details

Summary

Cache Middleware contains an information disclosure vulnerability caused by improper handling of HTTP cache control directives. The middleware does not respect standard cache control headers such as Cache-Control: private or Cache-Control: no-store, which may result in private or authenticated responses being cached and subsequently exposed to unauthorized users.

Details

The vulnerability exists in the cache decision logic of Cache Middleware. When determining whether a response should be cached, the middleware does not take HTTP cache control semantics into account and may cache responses that are explicitly marked as private by the application. While some runtimes, such as Cloudflare Workers, enforce cache control restrictions at the platform level, other runtimes including Deno, Bun, and Node.js rely on the middleware’s behavior. As a result, applications running on these runtimes may unintentionally cache sensitive responses.

Impact

This issue can lead to Web Cache Deception and information disclosure. If an authenticated user accesses an endpoint that returns user-specific or sensitive data and the response is cached despite being marked as private, subsequent unauthenticated requests may receive the cached response. This may result in the exposure of personally identifiable information or session-related data. The impact is limited to applications that use the hono/cache middleware and rely on it to correctly honor HTTP cache control directives.

Affected Components
  • Cache Middleware

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


Release Notes

honojs/hono (hono)

v4.11.7

Compare Source

Security Release

This release includes security fixes for multiple vulnerabilities in Hono and related middleware. We recommend upgrading if you are using any of the affected components.

IP Restriction Middleware

Fixed an IPv4 address validation bypass that could allow IP-based access control to be bypassed under certain configurations.

Cache Middleware

Fixed an issue where responses marked with Cache-Control: private or no-store could be cached, potentially leading to information disclosure on some runtimes.

Serve Static Middleware (Cloudflare Workers adapter)

Fixed an issue that could allow unintended access to internal asset keys when serving static files with user-controlled paths.

hono/jsx ErrorBoundary

Fixed a reflected Cross-Site Scripting (XSS) issue in the ErrorBoundary component that could occur when untrusted strings were rendered without proper escaping.

Recommendation

Users are encouraged to upgrade to this release, especially if they:

  • Use IP Restriction Middleware
  • Use Cache Middleware on Deno, Bun, or Node.js
  • Use Serve Static Middleware with user-controlled paths on Cloudflare Workers
  • Render untrusted data inside ErrorBoundary components

Security Advisories & CVEs


Full Changelog: honojs/hono@v4.11.6...v4.11.7

v4.11.6

Compare Source

v4.11.5

Compare Source

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.11.4...v4.11.5

v4.11.4

Compare Source

Security

Fixed a JWT algorithm confusion issue in the JWT and JWK/JWKS middleware.

Both middlewares now require an explicit algorithm configuration to prevent the verification algorithm from being influenced by untrusted JWT header values.

If you are using the JWT or JWK/JWKS middleware, please update to the latest version as soon as possible.

JWT middleware
import { jwt } from 'hono/jwt'

app.use(
  '/auth/*',
  jwt({
    secret: 'it-is-very-secret',
    alg: 'HS256', // required
  })
)
JWK/JWKS middleware
import { jwk } from 'hono/jwk'

app.use(
  '/auth/*',
  jwk({
    jwks_uri: 'https://example.com/.well-known/jwks.json',
    alg: ['RS256'], // required (asymmetric algorithms only)
  })
)

For more details, see the Security Advisory.

What's Changed

New Contributors

Full Changelog: honojs/hono@v4.11.3...v4.11.4


Configuration

📅 Schedule: Branch creation - "" (UTC), 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.

@changeset-bot
Copy link

changeset-bot bot commented Jan 14, 2026

⚠️ No Changeset found

Latest commit: 84b1a8b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@coderabbitai
Copy link

coderabbitai bot commented Jan 14, 2026

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

  • 🔍 Trigger a full review

Comment @coderabbitai help to get the list of available commands and usage tips.

@renovate renovate bot changed the title fix(deps): update dependency hono to v4.11.4 [security] fix(deps): update dependency hono to v4.11.7 [security] Jan 28, 2026
@renovate renovate bot force-pushed the renovate/npm-hono-vulnerability branch from 1a42efa to 84b1a8b Compare January 28, 2026 06:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants