CVE-2025-62610

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:

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

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.

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.

CVE-2025-62610 has a CVSS score of 8.1 (High). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.10.2); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2025-62610? CVE-2025-62610 is a high-severity security vulnerability in hono (npm), affecting versions >= 1.1.0, < 4.10.2. It is fixed in 4.10.2.
2. How severe is CVE-2025-62610? CVE-2025-62610 has a CVSS score of 8.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of hono are affected by CVE-2025-62610? hono (npm) versions >= 1.1.0, < 4.10.2 is affected.
4. Is there a fix for CVE-2025-62610? Yes. CVE-2025-62610 is fixed in 4.10.2. Upgrade to this version or later.
5. Is CVE-2025-62610 exploitable, and should I be worried? Whether CVE-2025-62610 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2025-62610 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2025-62610? Upgrade hono to 4.10.2 or later.