CVE-2025-62610: Hono JWT Auth Bypass Vulnerability

CVE-2025-62610 Overview

CVE-2025-62610 is an Authorization Bypass vulnerability in Hono, a popular Web application framework that provides support for any JavaScript runtime. The vulnerability exists in Hono's JWT Auth Middleware, which lacks a built-in aud (Audience) verification option. This missing security control can lead to confused-deputy and token-mix-up issues, allowing an API to accept valid tokens that were issued for a different audience (such as another service) when multiple services share the same issuer or cryptographic keys.

Critical Impact

This vulnerability enables unintended cross-service access through JWT token confusion. Attackers can leverage valid tokens from one service to authenticate against other services sharing the same issuer/keys, potentially gaining unauthorized access to sensitive resources and operations.

Affected Products

• Hono versions 1.1.0 to 4.10.1 (Node.js)
• Hono-based applications using JWT Auth Middleware
• Multi-service architectures sharing JWT issuers/keys

Discovery Timeline

• 2025-10-22 - CVE CVE-2025-62610 published to NVD
• 2026-02-04 - Last updated in NVD database

Technical Details for CVE-2025-62610

Vulnerability Analysis

The root of this vulnerability lies in Hono's JWT Auth Middleware implementation, which provides verification options for iss (issuer), nbf (not before), iat (issued at), and exp (expiration) claims but notably omits support for the aud (audience) claim verification. According to RFC 7519, when an aud claim is present in a JWT, the processing party MUST reject the token unless it identifies itself in that claim. By not enforcing this requirement, Hono allows tokens intended for one service to be accepted by another.

This creates a classic confused-deputy problem in microservice architectures. When multiple services trust the same identity provider or share signing keys, a token legitimately issued for Service A can be presented to Service B. Without audience verification, Service B has no mechanism to determine the token was not intended for its consumption and will process it as valid.

Root Cause

The vulnerability stems from an incomplete implementation of JWT validation within Hono's authentication middleware. The framework's documentation explicitly lists verification options for iss/nbf/iat/exp claims but provides no aud support. This architectural omission means developers using the middleware have no built-in mechanism to enforce audience restrictions, violating RFC 7519 compliance requirements for proper JWT handling.

Attack Vector

The attack is network-accessible and exploits trust relationships between services. An attacker who obtains a valid JWT token from one service in a multi-service ecosystem can present that token to a different service sharing the same issuer or cryptographic keys.

The attack scenario proceeds as follows: An attacker authenticates legitimately with Service A and receives a valid JWT. This token, which should only be valid for Service A, is then submitted to Service B's API endpoints. Because Hono's middleware cannot verify the audience claim, Service B accepts the token as valid authentication, granting the attacker access to resources and operations they should not have permission to use.

This attack requires user interaction in that the attacker must first obtain a valid token through some legitimate authentication flow, but once obtained, the token can be misused across service boundaries without any additional privileges.

Detection Methods for CVE-2025-62610

Indicators of Compromise

• JWT tokens being used across multiple distinct service endpoints when audience should be restricted
• Authentication logs showing successful token validation where the aud claim does not match the receiving service identifier
• Unexpected cross-service access patterns in application logs
• API access from services that should not have authorization for specific endpoints

Detection Strategies

• Implement logging that captures and monitors the aud claim value for all incoming JWT tokens
• Compare aud claim values against expected service identifiers in security monitoring tools
• Configure alerts for authentication events where tokens originate from unexpected issuers or contain mismatched audience claims
• Review authentication middleware configurations to identify missing audience verification

Monitoring Recommendations

• Enable verbose JWT validation logging to capture all claim values during authentication
• Establish baseline patterns for legitimate token usage across services and alert on deviations
• Implement distributed tracing to track token usage across microservice boundaries
• Monitor for elevated API error rates that may indicate token confusion attempts

How to Mitigate CVE-2025-62610

Immediate Actions Required

• Upgrade Hono to version 4.10.2 or later immediately
• Audit all JWT Auth Middleware configurations across your services
• Review service architectures that share JWT issuers or signing keys for potential exposure
• Implement manual audience verification as an interim measure if immediate upgrade is not possible

Patch Information

The vulnerability has been addressed in Hono version 4.10.2. The fix introduces proper aud claim verification support in the JWT Auth Middleware, allowing developers to specify expected audience values that will be enforced during token validation. The security patch is available through the GitHub commit. Additional details are documented in the GitHub Security Advisory GHSA-m732-5p4w-x69g.

Workarounds

• Implement custom middleware that manually validates the aud claim before processing requests
• Use unique signing keys per service to prevent cross-service token acceptance
• Deploy API gateways that enforce audience verification before routing to backend services
• Consider implementing additional authorization checks beyond JWT validation to verify service-specific permissions

# Update Hono to patched version
npm update hono@4.10.2

# Verify installed version
npm list hono