Summary

When parseBody() expands dot-separated form field names into nested objects, it does not limit the nesting depth or the total number of objects created. A request body well within a normal size limit can therefore allocate an object graph far larger than the request itself, and concurrent requests can exhaust the heap and terminate the process.

Details

Each dot-separated segment of a field name creates an intermediate object. Neither the segments within a single field name nor the total across a request was bounded, and empty segments were preserved, so a field name could encode one nesting level per byte.

Both shapes produce the effect: a single deeply dotted field name, and a large number of shallowly dotted ones within one body. A request body size limit does not prevent it, because the amplification happens after the body has been accepted.

Dot-notation parsing is not enabled by default.

Impact

An attacker who can reach an endpoint that parses request bodies with dot-notation enabled can send concurrent requests whose memory cost is disproportionate to their size.

This may lead to:

- exhaustion of the JavaScript heap and termination of the server process - the service remaining unavailable until it is restarted

This issue affects applications that explicitly enable dot-notation parsing. Applications using the default behaviour are not affected.

Summary

Hono's query parsing does not stop at the URL fragment: a ? appearing after a # is treated as the start of a query string. As a result, the application can read request parameters that no other component involved in handling the request can see.

Details

A fragment is never part of the query, and every standard URL consumer — browsers, new URL(), reverse proxies — ignores everything from the first # onward. Hono's routing followed that rule; its query helpers did not.

For one and the same request, this produces an interpretation differential:

- A component in front of the application that inspects the query string — filtering rules, parameter allow/deny lists, access logging — observes no parameters, while the application reads and acts on them. - The cache middleware removed the fragment when building its cache key, so a response influenced by parameters carried inside the fragment could be stored under a key that did not reflect them and later returned to other users.

The same divergence reaches request validation and any middleware that reads query parameters.

This requires a request target containing a literal # to reach the application. Deployments on runtimes that normalise such a target — including Cloudflare Workers — are not affected, and neither are those behind an intermediary that strips the fragment.

Impact

An attacker can cause the application to act on parameters that components in front of it never observe.

This may lead to:

- filtering rules, allow/deny lists, and audit logging being blind to parameters the application still processes - a cached response being stored under a key that does not reflect the parameters used to produce it, and served to other users - stored cross-site scripting, where such a parameter is reflected into a cached HTML response without escaping

This issue affects applications that read query parameters and run on a runtime that passes a literal # through to the request URL.

Summary

The Proxy Helper (hono/proxy) does not remove response headers named by the origin's Connection header. Headers that the origin marked as connection-scoped are therefore forwarded to clients.

Details

Per RFC 9110 Section 7.6.1, an intermediary must remove the header fields listed in a message's Connection header field before forwarding the message, in addition to the well-known hop-by-hop headers. The proxy() function removed the well-known hop-by-hop headers (including Connection itself) from origin responses, but did not remove the headers that the response's Connection header field designated as connection-scoped.

This issue arises when an application proxies responses from an origin that declares additional, non-standard headers as hop-by-hop via the Connection response header.

Impact

A client may receive response headers that the origin intended only for its immediate peer. This may lead to:

- Disclosure of connection-scoped or internal metadata contained in such headers

This issue affects applications that use the Proxy Helper (hono/proxy) to forward responses from origins that list custom header names in their Connection response header. Applications whose origins only use the standard hop-by-hop headers are not affected.

Hono before 4.12.7 allows proto key in parseBody with dot option enabled, permitting specially crafted form field names to create objects with proto properties. When parsed results are merged into regular JavaScript objects using unsafe merge patterns, attackers can exploit this to achieve prototype pollution and modify object behavior.

Hono before 4.10.2 (fixed in 4.10.3) contains a flaw in its CORS middleware: when the origin is not set to "", the middleware copies the Vary header from the incoming request into the response. Because Vary is a response header that should be managed by the server, an attacker can supply arbitrary Vary values that are reflected into the response, potentially causing cache key pollution and inconsistent CORS enforcement in environments that rely on shared caches or proxies.

Improper Authorization in Hono (JWT Audience Validation)

Hono’s JWT authentication middleware did not validate the aud (Audience) claim by default. As a result, applications using the middleware without an explicit audience check could accept tokens intended for other audiences, leading to potential cross-service access (token mix-up).

The issue is addressed by adding a new verification.aud configuration option to allow RFC 7519–compliant audience validation. This change is classified as a security hardening improvement, but the lack of validation can still be considered a vulnerability in deployments that rely on default JWT verification.

Recommended secure configuration

You can enable RFC 7519–compliant audience validation using the new verification.aud option:

ts import { Hono } from 'hono' import { jwt } from 'hono/jwt'

const app = new Hono()

app.use( '/api/', jwt({ secret: 'my-secret', verification: { // Require this API to only accept tokens with aud = 'service-a' aud: 'service-a', }, }) )

Below is the original description by the reporter. For security reasons, it does not include PoC reproduction steps, as the vulnerability can be clearly understood from the technical description.

---

The original description by the reporter

Summary Hono’s JWT Auth Middleware does not provide a built-in aud (Audience) verification option, which can cause confused-deputy / token-mix-up issues: an API may accept a valid token that was issued for a different audience (e.g., another service) when multiple services share the same issuer/keys. This can lead to unintended cross-service access. Hono’s docs list verification options for iss/nbf/iat/exp only, with no aud support; RFC 7519 requires that when an aud claim is present, tokens MUST be rejected unless the processing party identifies itself in that claim.

Note: This problem likely exists in the JWK/JWKS-based middleware as well (e.g., jwk / verifyWithJwks)

Details - The middleware’s verifyOptions enumerate only iss, nbf, iat, and exp; there is no aud option. The same omission appears in the JWT Helper’s “Payload Validation” list. Developers relying on the middleware for complete standards-aligned validation therefore won’t check audience by default. - Standards requirement: RFC 7519 §4.1.3 states that each principal intended to process the JWT MUST identify itself with a value in the aud claim; if it does not, the JWT MUST be rejected (when aud is present). Lack of a first-class aud check increases the risk that tokens issued for Service B are accepted by Service A. - Real-world effect: In deployments with a single IdP/JWKS and shared keys across multiple services, a token minted for one audience can be mistakenly accepted by another audience unless developers implement a custom audience check. - For example, with Google Identity (OIDC), iss is always https://accounts.google.com (shared across apps), but aud differs per application because it is that app’s OAuth client ID; therefore, an attacker can host a separate service that supports “Sign in with Google,” obtain a valid ID token (JWT) for the victim user, and—if your API does not verify aud—use that token to access your API with the victim’s privileges.

Impact Type: Authentication/authorization weakness via token mix-up (confused-deputy).

Who is impacted: Any Hono user who: - shares an issuer/keys across multiple services (common with a single IdP/JWKS) - distinguishes tokens by intended recipient using aud.

What can happen: - Cross-service access: A token for Service B may be accepted by Service A. - Boundary erosion: ID tokens and access tokens, or separate API audiences, can be inadvertently intermixed. - This may causes unauthorized invocation of sensitive endpoints.

Recommended remediation: 1) Add verifyOptions.aud (string | string[] | RegExp) to the middleware and enforce RFC 7519 semantics: In verify method, if aud is present and does not match with specified audiences, reject. 2) Ensure equivalent aud handling exists in the JWK/JWKS flow (jwk middleware / verifyWithJwks) so users of external IdPs can enforce audience consistently.