CVE-2026-39999: Apache APISIX jwt-auth authentication bypass via algorithm confusion

Apache APISIX's jwt-auth plugin selected the JWT signature verification primitive from the attacker-controlled JWT header alg field, while independently selecting the verification key from trusted consumer configuration. When a consumer was configured with an RS256 (asymmetric) algorithm, the plugin used the consumer's RSA public key as the verification key. An attacker who knew that public key could forge a JWT whose header declared alg=HS256 and whose HMAC-SHA256 signature was computed over the token using the public key PEM as the HMAC secret. The plugin then verified the forged token with HMAC-SHA256 — using the same public key as the secret — and accepted it, bypassing authentication entirely. This is the classic JWT algorithm confusion attack (CVE-2015-9235 pattern) realized in APISIX's jwt-auth verifier.

• Package/component affected: apisix/plugins/jwt-auth (the jwt-auth authentication plugin), specifically the find_consumer() → get_auth_secret() → verify_signature() path in apisix/plugins/jwt-auth.lua and apisix/plugins/jwt-auth/parser.lua.
• Affected versions: Apache APISIX 2.2.0 through 3.16.0 (all versions that supported asymmetric algorithms in jwt-auth and lacked the algorithm-match enforcement).
• Fixed in: 3.17.0 (commit e4de423fc583fdf82f47a1dda6c666aa2f2b3dca — "fix(jwt-auth): enforce algorithm match before signature verification (#13182)").
• Risk level: Critical. An unauthenticated remote attacker who can obtain a consumer's configured public key (which is, by definition, public) can forge a valid-looking JWT and access any route protected by that consumer's jwt-auth configuration. No private key material is required.

Impact Parity

• Disclosed/claimed maximum impact: Authentication bypass / authorization bypass (authz_bypass) on remote API requests authenticated via jwt-auth with an RS256-style consumer.
• Reproduced impact from this run: Full authentication bypass demonstrated end-to-end against a running Apache APISIX 3.16.0 gateway. A forged HS256 JWT (signed with the consumer's RSA public key as the HMAC secret) was accepted by the protected route (HTTP 200, request proxied to upstream), while the identical forged token was rejected by the fixed 3.17.0 gateway (HTTP 401, "failed to verify jwt: algorithm mismatch, expected RS256").
• Parity: full. The remote API authentication bypass described in the advisory was reproduced exactly, and the negative control on the fixed version confirms the fix closes the bypass.
• Not demonstrated: N/A — the claim is authorization bypass, not code execution, and the bypass itself was demonstrated in full.

Root Cause

In the vulnerable find_consumer() function (apisix/plugins/jwt-auth.lua, 3.16.0):

1. The JWT is parsed and the consumer is located by the key claim in the payload (consumer_mod.find_consumer(plugin_name, "key", user_key)).
2. get_auth_secret(consumer) returns the verification key based on the consumer's configured algorithm:

   local function get_auth_secret(consumer)
       if not consumer.auth_conf.algorithm or
          consumer.auth_conf.algorithm:sub(1, 2) == "HS" then
           return get_secret(consumer.auth_conf)     -- HMAC secret
       else
           return consumer.auth_conf.public_key      -- RSA public key (for RS256)
       end
   end
   

   For an RS256 consumer, the returned key is the RSA public key.
3. jwt:verify_signature(auth_secret) in parser.lua selects the verification primitive from self.header.alg — the JWT header, which is attacker-controlled:

   function _M.verify_signature(self, key)
       return alg_verify[self.header.alg](self.raw_header .. "." ..
                  self.raw_payload, base64_decode(self.signature), key)
   end
   

4. There was no check that self.header.alg matched consumer.auth_conf.algorithm. So when the attacker sets alg=HS256, alg_verify["HS256"](data, signature, public_key) is invoked, which computes HMAC-SHA256(data, public_key) and compares it to the attacker-supplied signature. Because the public key is public, the attacker can compute the identical HMAC and produce a matching signature → authentication bypass.

The fix (commit e4de423f, released in 3.17.0) inserts an algorithm-match enforcement before verify_signature:

-- Enforce that the JWT header's "alg" matches the consumer's configured algorithm
local expected_alg = consumer.auth_conf.algorithm or "HS256"
local token_alg = jwt.header and jwt.header.alg
if token_alg ~= expected_alg then
    local err = "failed to verify jwt: algorithm mismatch, expected " .. expected_alg
    ...
    return nil, nil, "failed to verify jwt"
end

This rejects any token whose header alg differs from the consumer's configured algorithm (e.g. an HS256 token against an RS256 consumer) before signature verification, closing the confusion.

Reproduction Steps

1. Script: bundle/repro/reproduction_steps.sh (self-contained, idempotent).
2. What it does:
   • Generates a fresh RSA-2048 keypair with openssl.
   • Deploys the real Apache APISIX gateway inside Docker containers on an isolated bridge network: bitnamilegacy/etcd:3.6 (config store), python:3-slim (upstream HTTP backend + client helper), and apache/apisix:3.16.0-debian (vulnerable) then apache/apisix:3.17.0-debian (fixed).
   • Uses the APISIX Admin API to create a consumer (jack) with the jwt-auth plugin configured for RS256 using the generated RSA public key, and a route (/) protected by jwt-auth with the upstream backend.
   • Verifies the route is genuinely protected: a request without a JWT returns HTTP 401.
   • Forges a JWT with header {"typ":"JWT","alg":"HS256"} and payload {"key":"jack-key"}, signing the header.payload input with HMAC-SHA256(..., RSA_public_key_PEM) — using the consumer's public key as the HMAC secret.
   • Sends the forged token to the protected route via Authorization: Bearer <jwt>.
   • On the vulnerable 3.16.0 gateway: the request is accepted (HTTP 200, proxied to upstream) → authentication bypass.
   • On the fixed 3.17.0 gateway (fresh etcd, same consumer/route): the identical forged token is rejected (HTTP 401, "failed to verify jwt") with the log algorithm mismatch, expected RS256 → fix confirmed.
3. Expected evidence: Two consecutive runs both show vulnerable→200 (bypass) and fixed→401 (reject); APISIX error logs on 3.17.0 contain the jwt-auth.lua:338: ... algorithm mismatch, expected RS256 line.

Evidence

• bundle/logs/harness_vulnerable.log — exploit harness output on 3.16.0 (forged HS256 JWT → HTTP 200, [+] VULNERABLE: forged HS256 JWT accepted -> authentication BYPASS).
• bundle/logs/harness_fixed.log — exploit harness output on 3.17.0 (forged HS256 JWT → HTTP 401, [+] FIXED: forged HS256 JWT rejected).
• bundle/logs/apisix_fixed.log — APISIX 3.17.0 nginx error log containing: [lua] jwt-auth.lua:338: find_consumer(): failed to verify jwt: algorithm mismatch, expected RS256.
• bundle/artifacts/results_vulnerable.json — {"forged_jwt_code": 200, "no_jwt_code": 401, ...}.
• bundle/artifacts/results_fixed.json — {"forged_jwt_code": 401, "no_jwt_code": 401, "forged_jwt_body": "{\"message\":\"failed to verify jwt\"}"}.
• bundle/artifacts/rsa_public.pem / rsa_private.pem — the RSA keypair used.
• bundle/artifacts/apisix_config.yaml — the APISIX deployment config (etcd + admin key).
• bundle/repro/runtime_manifest.json — structured runtime evidence manifest.

Key excerpt (vulnerable, 3.16.0):

[*] no-jwt: 401 (expect 401)
[*] forged HS256 JWT: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJrZXkiOiJqYWNrLWtleSJ9...
[*] forged-jwt: 200  body=<!DOCTYPE HTML>...
[+] VULNERABLE: forged HS256 JWT accepted -> authentication BYPASS

Key excerpt (fixed, 3.17.0):

[*] forged-jwt: 401  body={"message":"failed to verify jwt"}
[+] FIXED: forged HS256 JWT rejected (401) -> algorithm mismatch enforced

Environment: Docker (Apache APISIX official images), isolated bridge network, OpenResty/LuaJIT runtime inside the apache/apisix:*-debian images; APISIX versions verified via apisix version (3.16.0 / 3.17.0).

Recommendations / Next Steps

• Upgrade to Apache APISIX 3.17.0 or later, which enforces that the JWT header alg matches the consumer's configured algorithm before signature verification.
• Defense in depth: Consider also key-type/algorithm binding at the verifier primitive level (e.g. refuse to use an asymmetric key material with an HMAC primitive, and vice versa), so that a single missing upper-layer check cannot reintroduce the confusion.
• Audit existing jwt-auth consumers: any consumer configured with an asymmetric algorithm (RS*/ES*/PS*/EdDSA) whose public key is exposed was exploitable prior to the fix; rotate keys and review access logs for forged-token usage.
• Testing: Add a regression test that submits an HS256-forged token against an RS256 consumer and asserts a 401 (the fix commit e4de423f already added such tests in t/plugin/jwt-auth.t).

Additional Notes

• Idempotency: The script cleans up all containers/networks on exit and was run twice consecutively with identical results (vulnerable→200, fixed→401) — reproducibility confirmed.
• The forged JWT contains only the key claim (matching the consumer) and omits exp/nbf; on 3.16.0 verify_claims only validates those claims when present, so the token passes claim validation. This keeps the proof focused on the algorithm confusion and avoids confounding it with expiry behavior.
• The attack requires only the consumer's public key (which is public by design for RS256); no private key, no secrets, and no prior authentication are needed.
• Networking note: the sandbox runs Docker-in-Docker where host port publishing is not directly reachable from the shell; the script therefore drives all HTTP traffic through a python:3-slim client container on the same bridge network, addressing the APISIX gateway by its container alias.