GHSA-m732-5p4w-x69g Hono Improper Authorization vulnerability

• npm hono: >= 1.1.0, < 4.10.2 → fixed in 4.10.2

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.