Identity Theft on the Edge: Exploiting JWT Algorithm Confusion in Hono

If you are building modern edge applications—whether on Cloudflare Workers, Deno, or Bun—you are probably using Hono. It is lightweight, ultrafast, and generally a joy to use. But recently, a classic cryptographic ghost came back to haunt this modern framework: JWT Algorithm Confusion.

JSON Web Tokens (JWTs) are the standard for stateless authentication, but they suffer from a notorious design flaw in their specification. The token itself tells the server how to verify it via the alg header. This is like a criminal handing a police officer a note saying, "Please verify my identity using this napkin I wrote on, not the government database."

In CVE-2026-22817, Hono's middleware was a little too trusting. It allowed the client (the attacker) to dictate the rules of engagement. If the developer didn't explicitly shout, "ONLY USE RS256!" at the middleware, Hono would look at the token, shrug, and say, "Okay, the user wants to use HS256, let's roll with that." This oversight turns a robust public-key infrastructure into a broken symmetric key system using public data as the password.

To understand this bug, you have to understand the difference between HMAC (Symmetric) and RSA/ECDSA (Asymmetric) verification.

In an Asymmetric setup (e.g., RS256), the server holds a Private Key (to sign) and distributes a Public Key (to verify). Everyone knows the Public Key. It is literally designed to be public. In a Symmetric setup (e.g., HS256), the server and the client share a single secret key. This key must never be known by anyone else.

The vulnerability arises when the server expects an Asymmetric verification but the code is tricked into performing a Symmetric one. Here is the logic flaw in pre-4.11.4 Hono:

1. The server loads its Public Key, intending to verify RS256 signatures.
2. The attacker sends a token with "alg": "HS256" in the header.
3. The middleware sees HS256 and switches its internal logic to HMAC mode.
4. The middleware asks, "What is the secret key?" It looks at the configuration, sees the Public Key object, and says, "Okay, this blob of bytes is the secret."

The fatal mistake is that a Public Key is just a string of bytes. To an HMAC algorithm, it looks just like any other password. Since the attacker also has the Public Key, they can use it as the HMAC secret to sign their own forged tokens. The server verifies the signature against its own Public Key (thinking it's a secret), the math checks out, and the attacker is logged in as admin.

The vulnerability lived in the ambiguity of the verify logic. Let's look at why Hono failed to catch this. In the vulnerable versions, the middleware would prioritize the header's algorithm if the configuration didn't strictly forbid it. This is a common pattern in libraries trying to be "helpful" and compliant with RFC 7517, which marks alg as optional in some contexts.

The fix, introduced in commit cc0aa7ae327ed84cc391d29086dec2a3e44e7a1f, changed the game by forcing the developer to be explicit. It's a shift from "Allow unless forbidden" to "Deny unless explicitly allowed."

Here is a conceptual diff of the logic change:

// VULNERABLE (simplified logic)
// If the JWK doesn't have an alg, trust the token header
const algorithm = key.alg || header.alg;
if (algorithm === 'HS256') {
  // Dangerous: potentially using a public key as an HMAC secret
  verifyHMAC(header, payload, key.k);
}
 
// PATCHED (v4.11.4)
// Algorithm is now REQUIRED in config
if (!options.alg) {
   throw new JwtAlgorithmRequired('Algorithm not specified');
}
 
// Strict matching against the trusted config
if (header.alg !== options.alg) {
   throw new JwtAlgorithmMismatch();
}

The patch adds a critical check: JwtAlgorithmMismatch. It no longer matters what the token header says; if the server config expects RS256 and the token says HS256, the server throws an exception before even attempting crypto operations.

Let's walk through a practical attack scenario. Assume a target Hono application uses jwk() middleware to verify tokens from an Auth0 or Cognito issuer. These issuers publish their public keys at /.well-known/jwks.json.

Step 1: Reconnaissance The attacker accesses the JWKS endpoint and downloads the server's Public Key. This is not a hack; it's standard protocol behavior.

Step 2: The Forge The attacker creates a malicious JSON payload: {"sub": "admin", "role": "superuser"}. They then construct a JWT header, but with a twist: {"alg": "HS256", "typ": "JWT"}.

Step 3: Signing Using a script, the attacker takes the Public Key (usually a PEM string) and treats it as the HMAC secret key. They sign the malicious payload using the HS256 algorithm.

// Attacker's Node.js Script
const jwt = require('jsonwebtoken');
const fs = require('fs');
 
// The public key we downloaded from the target
const publicKey = fs.readFileSync('public_key.pem');
 
// We sign it using HS256, using the PUBLIC KEY as the secret
const forgedToken = jwt.sign(
  { sub: 'admin', role: 'superuser' }, 
  publicKey, 
  { algorithm: 'HS256' }
);
 
console.log("Forged Token:", forgedToken);

Step 4: Injection The attacker sends Authorization: Bearer <forgedToken> to the Hono app. The app sees HS256, grabs its local copy of the public key (the same one the attacker used), performs the HMAC verification, and grants access.

This is not a denial of service or a minor information leak. This is a full authentication bypass.

Because JWTs are often used to carry identity claims (sub, email, role) that the application trusts implicitly after verification, an attacker can impersonate any user. They can become the system administrator, access other users' data, or perform privileged actions.

Furthermore, because Hono is often deployed in edge environments (Cloudflare Workers) handling high-throughput API traffic, this vulnerability exposes the very gateway of your infrastructure. If your API gateway is compromised, every microservice behind it is effectively exposed. The attack is silent, leaves minimal logs (besides valid-looking requests), and requires zero interaction from a victim.

The remediation is straightforward but requires code changes. Simply updating the package is not enough if your configuration remains ambiguous.

1. Update Hono Upgrade to version 4.11.4 or higher immediately.

2. Enforce Algorithms Do not rely on defaults. Explicitly whitelist the algorithms you intend to support. If you are using RS256, say so.

// SECURE CONFIGURATION
app.use('/auth/*', jwt({
  secret: publicKey,
  alg: 'RS256' // <--- This is now mandatory and critical
}))

3. Audit JWKs If you are using the jwk() middleware, ensure you are passing an alg allowlist to prevent the middleware from accepting symmetric algorithms for an asymmetric key set.

jwk({
  provider: 'https://...', 
  alg: ['RS256'] // Whitelist allows strictly asymmetric algorithms
})