CVE-2025-62610: CWE-285: Improper Authorization in honojs hono
Hono is a Web application framework that provides support for any JavaScript runtime. In versions from 1.1.0 to before 4.10.2, 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. This issue has been patched in version 4.10.2.
AI Analysis
Technical Summary
CVE-2025-62610 is an improper authorization vulnerability classified under CWE-285 affecting the Hono JavaScript web framework versions from 1.1.0 up to before 4.10.2. Hono’s JWT Auth Middleware does not natively verify the 'aud' (audience) claim in JSON Web Tokens, which is a critical security check mandated by RFC 7519. The 'aud' claim ensures that a token is accepted only by the intended recipient service. Without this verification, tokens issued for one service can be mistakenly accepted by another service sharing the same issuer and cryptographic keys, leading to confused-deputy or token mix-up attacks. This flaw can allow an attacker to gain unauthorized access to APIs or services by presenting a valid token meant for a different service, thereby compromising confidentiality and integrity of data and operations. The vulnerability does not affect availability and requires user interaction, such as submitting a crafted token. The CVSS v3.1 score is 8.1 (high severity), reflecting network attack vector, low attack complexity, no privileges required, and user interaction needed. The vulnerability was publicly disclosed on October 22, 2025, and patched in Hono version 4.10.2. No known exploits in the wild have been reported yet. Organizations using Hono in multi-service environments must be aware that relying solely on issuer and key validation without audience claim checks is insufficient for secure token validation.
Potential Impact
For European organizations, this vulnerability poses a significant risk in environments where multiple services share the same JWT issuer and signing keys but serve different audiences. Attackers can exploit this flaw to gain unauthorized access to services by presenting tokens issued for other services, potentially leading to data breaches, unauthorized actions, and lateral movement within enterprise systems. This can compromise sensitive customer data, intellectual property, and internal APIs, impacting confidentiality and integrity. The risk is particularly acute for organizations adopting microservices architectures or API ecosystems using Hono for authentication. Regulatory compliance frameworks such as GDPR may impose penalties if unauthorized data access occurs. The lack of availability impact reduces the risk of service disruption but does not mitigate the serious confidentiality and integrity concerns. The absence of known exploits suggests a window for proactive mitigation before widespread attacks occur.
Mitigation Recommendations
1. Upgrade all Hono framework instances to version 4.10.2 or later, where the 'aud' claim verification is implemented and enforced by default. 2. If upgrading immediately is not feasible, implement custom middleware to explicitly validate the 'aud' claim in JWTs against the expected audience for each service, rejecting tokens that do not match. 3. Review and segregate JWT issuers and signing keys per service to minimize token reuse risks across services. 4. Conduct a thorough audit of all services using Hono to identify those sharing issuer and keys and assess exposure. 5. Enhance logging and monitoring to detect anomalous token usage patterns indicative of token mix-up exploitation. 6. Educate development teams on proper JWT validation practices aligned with RFC 7519, emphasizing the importance of audience claim checks. 7. Integrate automated security testing in CI/CD pipelines to verify JWT validation logic correctness. 8. Coordinate with identity providers to ensure tokens issued include correct and consistent 'aud' claims. 9. Prepare incident response plans for potential unauthorized access scenarios stemming from this vulnerability.
Affected Countries
Germany, France, United Kingdom, Netherlands, Sweden, Italy
CVE-2025-62610: CWE-285: Improper Authorization in honojs hono
Description
Hono is a Web application framework that provides support for any JavaScript runtime. In versions from 1.1.0 to before 4.10.2, 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. This issue has been patched in version 4.10.2.
AI-Powered Analysis
Technical Analysis
CVE-2025-62610 is an improper authorization vulnerability classified under CWE-285 affecting the Hono JavaScript web framework versions from 1.1.0 up to before 4.10.2. Hono’s JWT Auth Middleware does not natively verify the 'aud' (audience) claim in JSON Web Tokens, which is a critical security check mandated by RFC 7519. The 'aud' claim ensures that a token is accepted only by the intended recipient service. Without this verification, tokens issued for one service can be mistakenly accepted by another service sharing the same issuer and cryptographic keys, leading to confused-deputy or token mix-up attacks. This flaw can allow an attacker to gain unauthorized access to APIs or services by presenting a valid token meant for a different service, thereby compromising confidentiality and integrity of data and operations. The vulnerability does not affect availability and requires user interaction, such as submitting a crafted token. The CVSS v3.1 score is 8.1 (high severity), reflecting network attack vector, low attack complexity, no privileges required, and user interaction needed. The vulnerability was publicly disclosed on October 22, 2025, and patched in Hono version 4.10.2. No known exploits in the wild have been reported yet. Organizations using Hono in multi-service environments must be aware that relying solely on issuer and key validation without audience claim checks is insufficient for secure token validation.
Potential Impact
For European organizations, this vulnerability poses a significant risk in environments where multiple services share the same JWT issuer and signing keys but serve different audiences. Attackers can exploit this flaw to gain unauthorized access to services by presenting tokens issued for other services, potentially leading to data breaches, unauthorized actions, and lateral movement within enterprise systems. This can compromise sensitive customer data, intellectual property, and internal APIs, impacting confidentiality and integrity. The risk is particularly acute for organizations adopting microservices architectures or API ecosystems using Hono for authentication. Regulatory compliance frameworks such as GDPR may impose penalties if unauthorized data access occurs. The lack of availability impact reduces the risk of service disruption but does not mitigate the serious confidentiality and integrity concerns. The absence of known exploits suggests a window for proactive mitigation before widespread attacks occur.
Mitigation Recommendations
1. Upgrade all Hono framework instances to version 4.10.2 or later, where the 'aud' claim verification is implemented and enforced by default. 2. If upgrading immediately is not feasible, implement custom middleware to explicitly validate the 'aud' claim in JWTs against the expected audience for each service, rejecting tokens that do not match. 3. Review and segregate JWT issuers and signing keys per service to minimize token reuse risks across services. 4. Conduct a thorough audit of all services using Hono to identify those sharing issuer and keys and assess exposure. 5. Enhance logging and monitoring to detect anomalous token usage patterns indicative of token mix-up exploitation. 6. Educate development teams on proper JWT validation practices aligned with RFC 7519, emphasizing the importance of audience claim checks. 7. Integrate automated security testing in CI/CD pipelines to verify JWT validation logic correctness. 8. Coordinate with identity providers to ensure tokens issued include correct and consistent 'aud' claims. 9. Prepare incident response plans for potential unauthorized access scenarios stemming from this vulnerability.
Affected Countries
For access to advanced analysis and higher rate limits, contact root@offseq.com
Technical Details
- Data Version
- 5.1
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2025-10-16T19:24:37.268Z
- Cvss Version
- 3.1
- State
- PUBLISHED
Threat ID: 68f932a662bc771d0f4e4aa5
Added to database: 10/22/2025, 7:38:14 PM
Last enriched: 10/29/2025, 7:55:07 PM
Last updated: 12/7/2025, 7:55:08 AM
Views: 225
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Related Threats
CVE-2025-14186: Basic Cross Site Scripting in Grandstream GXP1625
MediumCVE-2025-14185: SQL Injection in Yonyou U8 Cloud
MediumCVE-2025-14184: Command Injection in SGAI Space1 NAS N1211DS
MediumCVE-2025-14183: Unprotected Storage of Credentials in SGAI Space1 NAS N1211DS
MediumCVE-2025-14182: Path Traversal in Sobey Media Convergence System
MediumActions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need enhanced features?
Contact root@offseq.com for Pro access with improved analysis and higher rate limits.