Hono CVE-2025-62610

Requires all of: (1) an application using Hono's JWT auth middleware (hono/jwt, or likely the jwk/verifyWithJwks variants) in a version from 1.1.0 to before 4.10.2; (2) a multi-service architecture where several services share the same JWT issuer and signing key/secret; and (3) tokens that carry an aud claim scoped to a different service. Because pre-4.10.2 Hono had no aud verification option at all (docs covered only iss/nbf/iat/exp), any such shared-key deployment was vulnerable by default with no misconfiguration needed. LIMITING FACTORS: single-service deployments, or deployments that do not share issuer/keys across services, are not meaningfully affected; and the attacker must already possess a valid, correctly-signed token issued for another audience in the same trust domain, so a fully anonymous outsider cannot exploit it.

Signals are mixed and point to a conditional, moderate real-world priority rather than a drop-everything emergency. The vendor CVSS of 8.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N) implies a serious network-reachable confidentiality/integrity break, but this is contradicted by the softer real-world indicators: EPSS is only 0.38% (30th percentile), there is no CISA KEV listing (not actively exploited), and the GitHub advisory itself classifies the fix as a 'security hardening improvement.' POC is marked publicly available, yet the GHSA deliberately omits reproduction steps, so a weaponized exploit is not independently confirmed. The CVSS vector also looks optimistic for this bug class: UI:R and PR:N are questionable because the attack is a confused-deputy/token-mix-up that depends entirely on a specific deployment shape (multiple services sharing one issuer/signing key, with tokens carrying an aud claim) and requires the attacker to already hold a valid token for a sibling audience - not something an anonymous remote user typically has. Net: this is a real authorization weakness worth patching, but its blast radius is gated by non-default architecture, so for most single-service Hono deployments the practical risk is low despite the high base score.

An organization runs two microservices (Service A and Service B) behind Hono's JWT auth middleware that share the same issuer and signing secret/keys. An attacker who is a legitimate user of Service A takes their valid token - scoped via aud to Service A - and replays it against Service B's Hono-protected API; because the middleware performed no audience validation before 4.10.2, Service B accepts the token and grants cross-service access it was never intended to allow. A public advisory exists (GHSA-m732-5p4w-x69g), though it intentionally withholds step-by-step PoC reproduction.