CVE-2026-47673

### Summary The `jwt` and `jwk` middlewares do not verify that the `Authorization` header value uses the`Bearer` scheme. Any two-part header value — regardless of the scheme name in the first position — proceeds to JWT verification. A request presenting a valid JWT under a non-`Bearer` scheme identifier (such as `Basic` or `Token`) is authenticated identically to a correctly formed `Bearer` request. ### Details When processing an `Authorization` (or custom) header, the middleware splits the value on whitespace and uses the second token as the JWT to verify. It does not check that the first token is `bearer` (case-insensitively). RFC 6750 specifies that JWT bearer tokens must be presented using the `Bearer` scheme; other scheme identifiers carry distinct semantics and may be subject to different policies in network-layer security controls. This discrepancy means that scheme-aware external controls — such as WAF rules, API gateways, or reverse proxies that apply policies specific to the `Bearer` scheme identifier — can be bypassed by presenting a valid JWT under a different scheme name. This issue affects `hono/jwt` and `hono/jwk` middleware. ### Impact An attacker who possesses a valid JWT may present it under a non-`Bearer` scheme identifier and still pass middleware authentication. This may lead to: - Bypass of network-layer security controls that inspect or filter requests based on the authorization scheme identifier - Token reuse across authentication schemes in applications that use multiple authorization mechanisms This issue affects applications where `hono/jwt` or `hono/jwk` authentication is combined with external controls that enforce scheme-based access policies.