CVE-2025-62610: 
JavaScript vulnerability analysis and mitigation

CVE-2025-62610 is an Improper Authorization vulnerability in the Hono web application framework's JWT Auth Middleware, caused by the absence of built-in aud (Audience) claim verification. This omission enables confused-deputy / token-mix-up attacks: a valid JWT issued for one service can be accepted by another service sharing the same issuer or signing keys. The vulnerability affects Hono versions >= 1.1.0 and < 4.10.2 (npm package). It was published by the GitHub Advisory Database on October 21–22, 2025, and carries a CVSS v3.1 base score of 8.1 (High) (Github Advisory, Hono Security Advisory).

The root cause is classified as CWE-285 (Improper Authorization): Hono's JWT middleware verifyOptions only enumerated iss, nbf, iat, and exp claims — there was no aud option — violating RFC 7519 §4.1.3, which mandates that a JWT MUST be rejected if the processing party does not identify itself in the aud claim (Hono Security Advisory). An attacker exploits this by obtaining a legitimate JWT from a shared Identity Provider (e.g., Google OIDC, where iss is always https://accounts.google.com) intended for one service (Service B), then presenting it to a different Hono-protected service (Service A) that shares the same issuer/keys but does not enforce audience validation. The fix, introduced in commit 45ba3bf, adds a verification.aud option (accepting string | string[] | RegExp) to the JWT middleware and enforces RFC 7519-compliant audience matching (Patch Commit). The same omission was noted to potentially affect JWK/JWKS-based middleware flows as well (Github Advisory).

Successful exploitation allows an attacker to gain unauthorized cross-service access by reusing a valid JWT token issued for a different audience, effectively bypassing authentication boundaries. This results in high confidentiality and integrity impact — an attacker can invoke sensitive API endpoints with a victim user's privileges, access protected data, and perform unauthorized actions across service boundaries. Availability is not directly impacted. The risk is highest in multi-service deployments using a single Identity Provider or shared JWKS, such as those relying on Google Identity (OIDC) or similar federated identity systems (Hono Security Advisory).

1. Identify target environment: Determine that the target Hono application (versions 1.1.0–4.10.2) uses JWT middleware without explicit aud validation and shares an issuer/signing keys with at least one other service (e.g., both services use Google OIDC or a shared internal IdP).
2. Register a controlled service: Set up or control a separate service (Service B) that accepts tokens from the same IdP/JWKS as the target (Service A). For example, register a Google OAuth application to obtain Google-issued ID tokens.
3. Obtain a valid JWT for Service B: Authenticate a victim user (or yourself) against Service B / the shared IdP to receive a valid, properly signed JWT. This token will have aud set to Service B's client ID and iss matching the shared issuer.
4. Present the token to Service A: Send an HTTP request to the target Hono API (Service A) with the JWT obtained for Service B in the Authorization: Bearer <token> header. Because Hono's middleware does not validate aud by default, the token passes signature and iss checks.
5. Achieve unauthorized access: The target API accepts the token and grants access with the victim user's identity and privileges, enabling data exfiltration, unauthorized actions, or further lateral movement within the service (Hono Security Advisory).

• Logs: API access logs showing successful authenticated requests where the JWT aud claim does not match the intended service's audience identifier; requests authenticated with tokens whose aud value corresponds to a different known service or OAuth client ID.
• Network: Unexpected cross-service API calls authenticated with JWTs bearing mismatched aud values; tokens from external IdPs (e.g., iss: https://accounts.google.com) used to access internal APIs not registered for that OAuth client.
• Application Behavior: Authenticated sessions or API calls originating from users who have not directly authenticated to the target service; access to sensitive endpoints by accounts that should only have access to a different service in the same IdP ecosystem.

Upgrade to Hono version 4.10.2 or later, which introduces the verification.aud configuration option for RFC 7519-compliant audience validation (Github Advisory, Patch Commit). After upgrading, explicitly configure audience validation in the JWT middleware:

import { Hono } from 'hono'
import { jwt } from 'hono/jwt'
const app = new Hono()
app.use('/api/*', jwt({
  secret: 'my-secret',
  verification: { aud: 'service-a' },
}))

For deployments that cannot upgrade immediately, implement a custom middleware to manually validate the aud claim against the expected service identifier. Additionally, review all services sharing an issuer/JWKS to ensure each enforces audience validation, including any JWK/JWKS-based middleware flows.

The advisory was published by Hono maintainer yusukebe on October 21, 2025, and credited reporter okazu-dm for responsible disclosure (Hono Security Advisory). Red Hat also tracked the vulnerability (Red Hat CVE). The issue was noted in the security community as a standards compliance gap rather than a novel attack technique, with the fix classified as a security hardening improvement. No significant broader media coverage or notable social media controversy was observed.