CVE-2026-22818: 
JavaScript vulnerability analysis and mitigation

CVE-2026-22818 is a JWT algorithm confusion vulnerability in the Hono web framework's JWK/JWKS JWT verification middleware. Prior to version 4.11.4, the middleware allowed the algorithm specified in an attacker-controlled JWT header to influence signature verification when the selected JWK did not explicitly define an alg field — a common real-world configuration. This could enable forged tokens to be accepted, leading to authentication or authorization bypass. The vulnerability was published on January 13, 2026, and affects all Hono versions before 4.11.4 on Node.js. The CNA (GitHub) assigned a CVSS v3.1 score of 8.2 (High), while NVD assessed it at 6.5 (Medium) (Github Advisory, Hono Security Advisory).

The root cause is classified as CWE-347 (Improper Verification of Cryptographic Signature). When verifying JWTs using JWKs or a JWKS endpoint, the middleware selected the verification algorithm from the JWK's alg field if present; if absent, it fell back to the alg value in the unverified JWT header. Since the alg field is optional in the JWK specification and commonly omitted in real-world JWKS configurations, an attacker could craft a JWT with an attacker-chosen alg header value to influence which cryptographic algorithm is used for verification. In certain configurations — particularly those accepting multiple algorithm types — this could allow a forged token with attacker-controlled claims to pass verification without a valid signature. The fix, introduced in commit 190f6e2, makes the alg option a required explicit allowlist of asymmetric algorithms and rejects all symmetric (HS*) algorithms in the JWK/JWKS context (Hono Security Advisory, Patch Commit).

Successful exploitation allows an unauthenticated remote attacker to forge JWT tokens with arbitrary claims, bypassing authentication and authorization controls in applications using Hono's JWK/JWKS middleware. This can result in unauthorized access to protected API routes and sensitive data (low confidentiality impact) and the ability to perform privileged actions as any user or role (high integrity impact). Availability is not directly affected. Applications not using the JWK/JWKS middleware, not relying on JWT-based authentication, or already explicitly restricting allowed algorithms are not affected. IBM watsonx Orchestrate with watsonx Assistant Cartridge is also listed as an affected product (Github Advisory, IBM Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The vulnerability requires no authentication, no user interaction, and is exploitable over the network, making it low-complexity to attempt. The EPSS score is approximately 0.021% (6th percentile), indicating a currently low probability of exploitation in the near term. This CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The vulnerability was reported by security researchers calloc134 and devanshbatham (Hono Security Advisory).

1. Identify target: Locate a Hono application (version < 4.11.4) that uses the JWK/JWKS JWT verification middleware without an explicit alg allowlist, and whose JWKS endpoint serves keys without an alg field.
2. Obtain a valid JWKS key ID (kid): Retrieve the application's JWKS endpoint (e.g., https://example.com/.well-known/jwks.json) to identify a valid kid value for a key that lacks an alg field.
3. Craft a malicious JWT header: Construct a JWT header specifying a chosen algorithm (e.g., {"alg": "HS256", "typ": "JWT", "kid": "<valid-kid>"}) that the attacker can sign with a known or weak secret.
4. Forge JWT payload: Create a JWT payload with attacker-controlled claims (e.g., elevated roles, arbitrary user identity).
5. Sign the token: Sign the crafted header and payload using the algorithm specified in the header (e.g., HMAC-SHA256 with an attacker-controlled secret or an asymmetric key pair generated by the attacker).
6. Submit the forged token: Send the crafted JWT in the Authorization: Bearer <token> header to a protected endpoint. The vulnerable middleware, lacking an explicit algorithm allowlist, uses the attacker-supplied alg from the JWT header for verification, potentially accepting the forged token.
7. Achieve authorization bypass: If accepted, the attacker gains access to protected resources with the claims specified in the forged token (Hono Security Advisory, Patch Commit).

• Network: Unexpected or repeated requests to protected API endpoints with JWT tokens using unusual or mismatched alg values (e.g., HS256 where RS256 is expected); requests with JWTs whose kid matches a known key but whose algorithm differs from the key type.
• Logs: Application access logs showing successful authentication to privileged endpoints from unexpected users or IP addresses; JWT decode logs (if enabled) showing alg values inconsistent with the configured JWKS key types.
• Application Behavior: Authenticated sessions or API responses reflecting unexpected user roles or claims not issued by the legitimate identity provider; anomalous access patterns to resources that should be restricted to specific roles.

Upgrade Hono to version 4.11.4 or later, which makes the alg option a required parameter in the JWK/JWKS middleware and rejects symmetric (HS*) algorithms entirely in this context. After upgrading, update all middleware configurations to explicitly specify an asymmetric algorithm allowlist (e.g., alg: ['RS256']). There is no configuration-based workaround for versions prior to 4.11.4 other than disabling the JWK/JWKS middleware or implementing external JWT validation. IBM watsonx Orchestrate users should refer to the IBM advisory for product-specific remediation guidance (Hono Security Advisory, IBM Advisory, Patch Commit).

The vulnerability was disclosed by Hono maintainer yusukebe on January 13, 2026, with credit to reporters calloc134 and devanshbatham. The advisory was noted by TheHackerWire on Mastodon and Bluesky shortly after disclosure, indicating moderate community awareness. The fix introduces a breaking change requiring explicit algorithm specification, which has been highlighted in migration guidance (Hono Security Advisory).