Topic starter
11/11/2026 5:57 pm
TL;DR: When applications mixed algorithm families and accepted DER-encoded public keys, forged HS256 tokens could verify through PyJWT’s key confusion bug, Maze reports. JWT verification needs strict algorithm separation, because a format-specific bypass turns public key material into an authentication secret.
Editorial analysis by NHI Mgmt Group, based on content published by Maze: “There’s a ten-year-old key confusion bug in PyJWT, fixed in 2.14.0”.
Key questions
Q: How do security teams know whether their JWT implementation is actually using a safe signing key?
A: A safe JWT implementation uses a dedicated, high-entropy signing key that is independent of any user password or account attribute.
Q: What is the difference between HS256 and RS256 in token governance?
A: HS256 is symmetric, so the same secret both signs and verifies.
Q: How do mixed JWT algorithms create key confusion?
A: Mixed JWT algorithms create key confusion when one verifier accepts both symmetric and asymmetric signing families for the same key.
Practitioner guidance
- Enforce single-algorithm verification Assign exactly one JWT algorithm class to each verification key and reject mixed HS* and RS* lists in application code.
- Validate parsed key type Check the decoded key object before verification so binary encodings cannot bypass a text-based denylist.
- Review token verification paths for ambiguity Inventory every place a JWT verifier accepts key material and confirm the code cannot reinterpret public keys as HMAC secrets.
Bottom line: The bug shows that token verification can fail even when a library appears to block obvious key misuse, because format-specific checks may not enforce the real cryptographic boundary.
Glossary terms: HS256, PyJWT Key Confusion Vulnerability, DER Encoding, Key Confusion
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 5:57 pm
Key confusion is a governance failure in verification design, not a narrow parser bug. The real issue is that one application boundary was allowed to enforce two incompatible cryptographic trust models at once. That creates ambiguity about what a key is allowed to mean, which is exactly how attacker-controlled token claims slip through. Practitioners should treat mixed algorithm verification as a design flaw, not a tuning issue.
A question worth separating out:
Q: What signs suggest JWT verification is misconfigured?
A: Common signs are tokens accepted with the wrong signing key, the wrong issuer or audience, or a missing expiry check. A weak single algorithm boundary can let a verifier accept unsigned or differently signed tokens, while permissive handling of header fields such as alg or kid can enable token forgery or replay. Proper verification enforces a fixed algorithm, exact claim checks and key lookup from trusted metadata.
👉 Read our full editorial: PyJWT key confusion bug lets DER public keys forge HS256 logins