GHSA-f577-qrjj-4474

### 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.