CVE-2026-47673

What it actually does

Hono versions prior to 4.12.21 have an authentication scheme validation flaw in the jwt and jwk middleware. The middleware parses two-part Authorization header values but does not require the first token to be the Bearer scheme. As a result, a request such as `Authorization: Basic <valid JWT>` or `Authorization: Token <valid JWT>` is processed the same as `Authorization: Bearer <valid JWT>`. This does not allow an attacker to forge or bypass JWT signature validation; exploitation still requires a valid JWT. The risk is scheme confusion: applications, proxies, gateways, logging rules, or authorization logic that distinguish Bearer tokens from other authentication schemes may be bypassed or misled.

Why it matters to the business

Applications using affected Hono JWT or JWK middleware may accept authenticated API requests that do not follow the intended Bearer-token contract. This can weaken access-control assumptions, break audit accuracy, and allow users or integrations with valid tokens to reach functionality that upstream controls intended to restrict based on authentication scheme. Because Hono is a web framework used across JavaScript runtimes, exposure can exist in APIs, edge functions, serverless services, and microservices that rely on the affected middleware. The CVSS and EPSS values indicate relatively low severity and low observed exploitation likelihood, and it is not listed in CISA KEV; however, remediation is still appropriate because the fix is straightforward and authentication parsing defects are easy to regression-test.

How an attack unfolds

An attacker first obtains a valid JWT for the target application, such as through normal registration, a compromised user account, a leaked token, or another token-acquisition path. Instead of sending the token in the expected `Authorization: Bearer <JWT>` format, the attacker sends a two-part Authorization header using another scheme name, for example `Authorization: Basic <JWT>`, `Authorization: Token <JWT>`, or another arbitrary scheme followed by the JWT. In vulnerable Hono versions, the jwt or jwk middleware ignores the scheme name and proceeds to validate the JWT. If the JWT is valid and otherwise satisfies application claims, the request is authenticated. The attacker may use this to bypass surrounding logic that only inspects or blocks Bearer authentication, evade detections that look exclusively for Bearer headers, or exploit inconsistencies between upstream components and the Hono application.

How to fix it

Upgrade Hono to version 4.12.21 or later wherever the jwt or jwk middleware is used. If exact package management is in use, update the relevant `hono` dependency in `package.json`, lockfiles, container builds, and serverless or edge-function bundles, then redeploy all affected services. As a defense-in-depth mitigation, add explicit validation before JWT verification that rejects any Authorization header not matching the expected Bearer format, for example requiring the case-insensitive pattern `Authorization: Bearer <token>` and rejecting `Basic`, `Token`, empty schemes, malformed two-part values, or multi-value Authorization headers. Review upstream proxies, API gateways, and WAF rules to ensure they do not make conflicting authentication decisions based only on the scheme name.

How to confirm the fix worked

Confirm that deployed applications use Hono 4.12.21 or later by inspecting dependency manifests, lockfiles, software bills of materials, container images, and runtime build artifacts. Functionally test protected endpoints with three request types: no Authorization header, a valid `Authorization: Bearer <JWT>` header, and a valid JWT supplied under a non-Bearer scheme such as `Authorization: Basic <JWT>`. The fixed behavior should accept only the valid Bearer request and reject the non-Bearer request with an authentication failure such as HTTP 401 or 403. Also test malformed values, lowercase or mixed-case Bearer if supported by policy, extra whitespace, and multiple Authorization headers to ensure behavior is consistent across proxies and the application runtime.

Typical attack path

1. Identify an API or route protected by Hono jwt or jwk middleware running a version prior to 4.12.21.
2. Obtain a valid JWT for the application through legitimate access, account compromise, token leakage, or another credential-access method.
3. Send requests to protected endpoints using a non-Bearer Authorization scheme followed by the valid JWT, such as `Authorization: Basic <JWT>` or `Authorization: Token <JWT>`.
4. Rely on the vulnerable middleware to validate the JWT while ignoring the incorrect scheme name.
5. Access protected functionality or bypass scheme-specific controls, monitoring, or gateway rules that expected only `Bearer` tokens.

How to detect it

To determine whether this was already exploited, review HTTP access logs, API gateway logs, reverse proxy logs, WAF logs, application request logs, and authentication middleware logs for protected routes. Look for successful requests where the Authorization header scheme is not `Bearer` but the credential value resembles a JWT, typically three Base64URL segments separated by dots and often beginning with `eyJ`. Give priority to requests using schemes such as `Basic`, `Token`, `JWT`, `Digest`, `ApiKey`, or arbitrary custom strings followed by a JWT-shaped value. Correlate these requests with response status codes, user identity resolved from the token, route sensitivity, source IP, user agent, and whether equivalent Bearer-format traffic is expected for that client. Because many systems redact Authorization headers by default, also check gateway debug logs, WAF sampled requests, application telemetry, authentication failure/success events, and packet captures where legally and operationally appropriate. There are no public reports of mature exploitation or KEV listing in the provided data, so detection should focus on scheme-confusion patterns rather than known actor-specific tooling.

• Authorization: Basic eyJ
• Authorization: Token eyJ
• Authorization: JWT eyJ
• Authorization: Jwt eyJ
• Authorization: Digest eyJ
• Authorization: ApiKey eyJ
• Authorization: Bearer eyJ
• Authorization: Basic [A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+
• Authorization: Token [A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+
• Authorization: JWT [A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+
• Authorization: Digest [A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+
• Authorization: ApiKey [A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+

What your security team should do

• Inventory services, APIs, serverless functions, and edge workloads that depend on Hono and use the jwt or jwk middleware.
• Prioritize upgrading all affected Hono deployments to 4.12.21 or later, especially internet-facing APIs and services where upstream controls distinguish between Bearer and non-Bearer authentication.
• Add automated dependency checks to flag Hono versions prior to 4.12.21 in repositories, CI/CD pipelines, container images, and SBOMs.
• Add regression tests that verify non-Bearer Authorization schemes carrying valid JWTs are rejected.
• Review API gateway, WAF, reverse proxy, and application logs for requests where the Authorization scheme is not Bearer but the second token resembles a JWT.
• Treat findings as potential authentication-control bypass attempts if they target protected routes and receive successful responses.
• Ensure SIEM detections do not only search for `Authorization: Bearer` when identifying JWT use; include suspicious non-Bearer schemes containing JWT-shaped values.