CVE-2025-62610

Executive Summary

CVE-2025-62610 is a high-severity vulnerability in the Hono web application framework (versions 1.1.0 to before 4.10.2) affecting its JWT Auth Middleware. The flaw stems from the middleware’s lack of built-in aud (Audience) claim verification, as required by RFC 7519. This omission enables a confused-deputy / token-mix-up attack: an API may accept a valid JWT that was issued for a different audience (e.g., another service) when multiple services share the same issuer and signing keys. This can lead to unintended cross-service access, potentially allowing an attacker to escalate privileges or access sensitive data across services.

The vulnerability has a CVSS score of 8.1 (High) and is currently unpatched in affected versions. The fix is available in Hono version 4.10.2.

Supply Chain & Package Security

Hono is a JavaScript/TypeScript web framework distributed via npm. This vulnerability affects the entire supply chain of applications using Hono’s JWT middleware. Organizations must ensure that their dependency manifests (package.json, yarn.lock, package-lock.json) are updated to version 4.10.2 or later. Failure to do so could expose internal services to token-mix-up attacks, especially in microservice architectures where multiple services share the same JWT issuer and keys.

CVSS Breakdown & Threat Level

• CVSS Score: 8.1 (High)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: High (C:H)
• Integrity Impact: High (I:H)
• Availability Impact: None (A:N)

The high confidentiality and integrity impacts reflect the potential for an attacker to access or modify data across services by reusing tokens intended for a different audience.

Deep Dive & Mechanics

The vulnerability lies in Hono’s JWT Auth Middleware, which validates JWT tokens but does not enforce the aud (Audience) claim. According to RFC 7519, when an aud claim is present, the token MUST be rejected unless the processing party identifies itself in that claim. Without this check, a token issued for Service A (e.g., aud: "service-a") can be accepted by Service B if both services share the same issuer and signing keys. This is a classic confused-deputy problem.

Attack Scenario:

1. An attacker obtains a valid JWT for Service A (e.g., by compromising a user account or exploiting another vulnerability).
2. The attacker presents this token to Service B, which uses the same JWT issuer and keys.
3. Service B, lacking aud verification, accepts the token and grants access as if the token was intended for Service B.
4. The attacker gains unauthorized access to Service B’s resources.

The Hono documentation only lists verification options for iss, nbf, iat, and exp, omitting aud. This design flaw makes the middleware non-compliant with RFC 7519.

Vulnerable vs. Patched Code

Vulnerable Code (before 4.10.2): The JWT middleware only checks iss, nbf, iat, and exp claims. No aud verification is performed.

// Example vulnerable middleware configuration
app.use('/api/*', jwt({
  secret: 'my-secret',
  // No aud option
}));

Patched Code (4.10.2): The patched version adds an aud option to the middleware configuration, allowing developers to specify the expected audience. The middleware now rejects tokens where the aud claim does not match the expected value.

// Example patched middleware configuration
app.use('/api/*', jwt({
  secret: 'my-secret',
  aud: 'service-b' // Expected audience
}));

The patch also updates the documentation to include aud as a supported verification option.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• Two services (Service A and Service B) using Hono with JWT middleware, sharing the same issuer and signing keys.
• A valid JWT for Service A (e.g., with aud: "service-a").

Steps:

1. Obtain a valid JWT for Service A (e.g., via legitimate login or token leakage).
2. Send a request to Service B’s protected endpoint with the stolen token.
3. Observe that Service B accepts the token and grants access.

Example Request:

curl -X GET https://service-b.internal/api/sensitive-data \
  -H "Authorization: Bearer <stolen-token-for-service-a>"

Expected Result: Service B returns sensitive data, confirming the token-mix-up.

Blue Team (Defense & Detection)

Detection:

• Monitor for JWT tokens with unexpected aud claims across services.
• Log and alert on authentication events where the aud claim does not match the expected service identifier.

Mitigation:

• Immediately update Hono to version 4.10.2 or later.
• If immediate patching is not possible, implement custom middleware to validate the aud claim manually.
• Ensure that each service uses a unique aud value and that tokens are validated against it.

Example Custom Middleware (for temporary mitigation):

app.use('/api/*', async (c, next) => {
  const token = c.req.header('Authorization')?.replace('Bearer ', '');
  if (token) {
    const decoded = jwt.decode(token);
    if (decoded.aud !== 'service-b') {
      return c.text('Unauthorized', 401);
    }
  }
  await next();
});

Indicators of Compromise (IOCs)

• Network: HTTP requests with JWT tokens where the aud claim does not match the target service.
• Logs: Authentication logs showing successful access to a service using a token with an aud claim for a different service.
• Application: Unexpected access to sensitive endpoints by users or tokens that should not have access.

Detection Engineering

YARA Rule

rule CVE_2025_62610_JWT_Aud_Missing {
    meta:
        description = "Detects JWT tokens without aud claim or with mismatched aud in Hono applications"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-62610"
    strings:
        $jwt_header = /eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+/
        $aud_claim = /"aud"\s*:\s*"[^"]*"/
    condition:
        $jwt_header and not $aud_claim
}

Sigma Rule

title: CVE-2025-62610 - JWT Token Without Audience Claim
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects JWT tokens without the aud claim in Hono applications
author: Valters IT
date: 2025-04-10
logsource:
    category: application
    product: hono
detection:
    selection:
        event: "jwt_validation"
        claims|contains: "aud"
    condition: not selection
falsepositives:
    - Legitimate tokens without aud claim (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-62610 - JWT Token Without Audience Claim"; flow:to_server; content:"Authorization"; nocase; content:"Bearer "; distance:0; pcre:"/eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+/R"; pcre:"/\"aud\"\s*:\s*\"[^\"]*\"/"; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Patch: Update Hono to version 4.10.2 or later. This is the only complete fix.
2. Temporary Workaround: Implement custom middleware to validate the aud claim manually (see Blue Team section).
3. Audit: Review all services using Hono’s JWT middleware to ensure they are updated.
4. Documentation: Update internal documentation to emphasize the importance of aud verification.
5. Monitoring: Enable logging for JWT validation failures and monitor for tokens with unexpected aud claims.

Valters IT
Securing the digital frontier, one CVE at a time.