CVE-2026-47673: Hono JWT Middleware Bearer Scheme Validation Bypass

Technical summary

The vulnerability stems from insufficient scheme validation in Hono's jwt and jwk middleware implementations. The middleware logic checks for the presence of a two-part Authorization header but does not verify that the first part matches the Bearer scheme before proceeding to JWT token validation. An Authorization header formatted as "Basic <valid_jwt>" or "Token <valid_jwt>" will be accepted and the JWT payload will be verified, bypassing the intended Bearer-only authentication model. This validation gap allows authentication to succeed under non-standard scheme identifiers, violating the OAuth 2.0 Bearer Token Usage specification (RFC 6750) which mandates Bearer as the exclusive scheme for JWT-based bearer tokens.

Business impact

Organizations using Hono applications rely on JWT-based authentication to control access to APIs and protected resources. This vulnerability reduces the security posture of that authentication layer by allowing attackers with a valid JWT to bypass scheme enforcement. In practice, an attacker who obtains a valid JWT—through token interception, compromise of a token-issuing service, or other means—gains a more flexible attack vector. They can present the token under alternative schemes that may be subject to different rate limiting, logging, or inspection rules, or they may exploit this to confuse security controls that depend on scheme-specific behavior. For applications that rely on scheme enforcement as part of a defense-in-depth strategy, this creates an authentication control weakness.

Affected systems

Hono versions prior to 4.12.21 are affected. Any deployment using the jwt or jwk middleware for authentication is at risk. The vulnerability exists across all JavaScript runtimes supported by Hono (Node.js, Deno, Bun, Cloudflare Workers, etc.), as the flawed validation logic is framework-level, not runtime-specific.

Exploitability

Exploitability requires two preconditions: the attacker must possess or be able to obtain a valid JWT issued by the application's token service, and the application must be running a vulnerable version of Hono with jwt or jwk middleware enabled. The vulnerability itself is trivial to exploit once those conditions are met—simply crafting an Authorization header with an alternative scheme name and the valid JWT requires only basic HTTP manipulation. No special tooling, network conditions, or user interaction is needed. The CVSS score reflects the relatively moderate impact (read and modify access, partial confidentiality and integrity loss) combined with the requirement that a valid token must already exist, which raises the attack complexity.

Remediation

Upgrade Hono to version 4.12.21 or later. This version introduces proper Bearer scheme validation in the jwt and jwk middleware, ensuring that only Authorization headers beginning with "Bearer " (case-insensitive) are accepted for JWT verification. Verify the upgrade across all environments (development, staging, production) where Hono-based applications are deployed. No configuration changes are required post-upgrade; the fix is transparent to application code.

Patch guidance

1. Review your Hono dependency version in package.json or equivalent dependency manifest. 2. Update to version 4.12.21 or the latest stable release. 3. Run your dependency lock file update (npm install, yarn install, or pnpm install) and commit changes. 4. Re-run your authentication test suite to confirm JWT validation behavior remains intact. 5. Deploy the updated application across all environments. 6. Monitor application logs post-deployment for any unexpected authentication rejections (which would indicate overly permissive schemes were previously in use).

Detection guidance

Review HTTP request logs for Authorization headers that contain valid JWT tokens but use non-Bearer scheme identifiers (e.g., "Authorization: Basic eyJ...", "Authorization: Token eyJ..."). Inspect middleware configuration in your Hono codebase to confirm whether jwt or jwk middleware is active. If you have network-level traffic inspection in place, look for patterns where the same JWT appears with varying scheme names across different requests. Enable debug logging in Hono's middleware layer (if available) to capture scheme information for each auth attempt. Check for any unusual authentication activity correlating to the introduction of alternative scheme names in your HTTP traffic.

Why prioritize this

This vulnerability merits prompt but not emergency attention. The CVSS score of 4.8 (MEDIUM) reflects that exploitation requires pre-existing valid tokens and does not grant complete system compromise. However, it does weaken a critical authentication control. The fact that it is not yet in CISA's Known Exploited Vulnerabilities catalog suggests active exploitation in the wild is not widespread. Prioritize patching in public-facing or internet-accessible Hono applications and in environments processing sensitive data or identity verification. Delay is acceptable only if your threat model depends entirely on scheme-based controls being unbypassable—which is never the case with modern security practices—or if your Hono instances are isolated from untrusted networks.

Risk score, explained

The CVSS 3.1 score of 4.8 is derived from: Network Attack Vector (AV:N) reflecting that the flaw can be exploited over the network; High Attack Complexity (AC:H) because the attacker must already possess a valid JWT; No Privilege Requirement (PR:N) as any unauthenticated user can submit a crafted request; No User Interaction (UI:N); Unchanged Scope (S:U); Low Confidentiality Impact (C:L) and Low Integrity Impact (I:L) indicating partial unauthorized access and data modification capability; and No Availability Impact (A:N). The HIGH attack complexity is the primary moderating factor, preventing a HIGHER severity rating despite the network-accessible nature and authentication bypass nature of the flaw.

Frequently asked questions