PyJWT key confusion bug lets DER public keys forge HS256 logins

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Maze's blog post: PyJWT key confusion let attackers forge JWT login tokens with DER-encoded public keys when applications mixed symmetric and asymmetric algorithms.

Why it matters: This matters because token verification logic sits inside authentication paths, and a single parsing gap can turn a public key into a valid signing secret.

Context

PyJWT’s bug sits in a familiar identity failure mode: verification logic assumed that rejecting one key representation was enough to stop misuse of the underlying credential material. When applications allow a token verifier to accept both HMAC and asymmetric algorithms in the same path, the trust boundary shifts from cryptography to input formatting.

JWT libraries often become the last control before session establishment, so a key handling mistake can affect authentication at scale rather than one isolated application. The issue is not just that DER was missed, but that the application model allowed incompatible verification assumptions to share a single decision path.

Key questions

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. That lets an attacker reuse public key material as an HMAC secret, because the application no longer enforces one trust model per verification path. The safe pattern is to bind each key to a single algorithm class and reject tokens that do not match it.

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. Teams should verify the key is stored separately, never derived deterministically from credentials, and regularly rotated through controlled secret management. If the key changes when a password changes, the design is too tightly coupled to identity.

Q: What is the difference between HS256 and RS256 in token governance?

A: HS256 is symmetric, so the same secret both signs and verifies. RS256 is asymmetric, so the private key signs while the public key verifies. In governance terms, RS256 separates minting authority from validation authority, which reduces the blast radius when many systems need to trust the same token.

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.

Technical breakdown

Why mixed JWT algorithm lists create key confusion

JWT verification becomes fragile when one verifier accepts both symmetric and asymmetric algorithms. HS256 uses the same secret for signing and verification, while RS256 uses a private key for signing and a public key for verification. If a library accepts both in one algorithms list, the application can end up treating public key material as if it were an HMAC secret. That is the core of key confusion: the verifier no longer knows which trust model it is enforcing for a given token, so the attacker focuses on whichever representation the parser mishandles. See the NHI Authentication Guide.

Practical implication: Keep algorithm families separate so a public key can never be evaluated as an HMAC secret.

Why DER-encoded keys bypassed the existing check

The vulnerable check looked for textual markers such as PEM headers and certain SSH prefixes, which is effective only when the key is still expressed as recognizable text. DER is a binary encoding, so the same public key can arrive in a form that does not match those text-based patterns even though it still parses as an asymmetric key. That means the check guarded against known string forms rather than the key object itself. Once binary encodings entered the flow, the denylist stopped representing the real security property. See the Cryptography Basics Guide.

Practical implication: Validate the parsed key type, not just its serialized wrapper.

Why one key, one algorithm is the stable configuration

A single allowed algorithm per key removes the ambiguity that key confusion exploits. If the application only accepts RS256 for a given key, an attacker cannot switch the same material into an HS256 verification path and reinterpret a public key as an HMAC secret. This is less about a patch version and more about keeping the cryptographic contract explicit at the application boundary. The safer pattern is to bind each verification key to one algorithm class and reject any token that arrives with a different expectation.

Practical implication: Bind each verification key to one algorithm class and refuse mixed-family verification paths.

NHI Mgmt Group analysis

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.

Format-aware checks do not equal identity-aware checks. A denylist that only recognizes PEM headers or SSH prefixes protects against known encodings, not against the identity of the key itself. PyJWT’s missed DER path shows why serialised text is a weak proxy for credential type. The practical lesson is that verification controls must evaluate the parsed credential object, not the wrapper it arrived in.

One key, one algorithm is a stronger security invariant than expanding reject lists. Every added format rule extends the patch history but also preserves a brittle model in which attackers can search for the next unhandled encoding. That is a classic example of control accretion without trust simplification. The better mental model is explicit algorithm binding at issuance and verification time.

Public-key material became a secret because the application accepted the wrong trust boundary. That boundary was designed for tokens whose legitimacy depends on the verifier knowing which key semantics apply. It fails when the verifier allows a public key to masquerade as an HMAC secret because the verification path is no longer unambiguous. The implication is that token governance must be built around key intent, not just key format.

DER-expanded the attack surface because the existing safeguard was built for a narrower encoding universe. This is the named concept that matters here: format-specific key confusion. It describes the gap between the key state a control expects and the state an attacker can supply without changing the underlying credential. Practitioners should assume any serialization boundary can become an identity boundary unless the parsed key type is enforced.

What this signals

Format-specific key confusion will keep showing up anywhere verification logic trusts serialized key shape more than parsed credential intent. The deeper pattern is not limited to JWT libraries. Any authentication layer that treats a public key, certificate, or raw byte string as interchangeable with an HMAC secret is building in a bypass opportunity.

Verification boundaries need to move from string matching to typed credential handling. When a security control can be defeated by changing the encoding of the same key material, the control is not governing identity semantics, only text patterns.

For practitioners

• Enforce single-algorithm verification Assign exactly one JWT algorithm class to each verification key and reject mixed HS* and RS* lists in application code. See the NHI Authentication Guide.
• 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. Read Securing the customer identity (CIAM) platform itself.
• Retire legacy library versions Move applications to PyJWT 2.14.0 or later, then test that the same key cannot verify both asymmetric and symmetric token paths.

Key takeaways

• 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.
• The affected path matters because mixed algorithm lists let attacker-controlled claims be evaluated under the wrong trust model, turning a public key into a forgery primitive.
• The durable fix is to bind each key to one algorithm class and validate the parsed key type before verification, not to expand deny lists indefinitely.

Related NHI Mgmt Group resources: NHI Authentication Guide · Cryptography Basics Guide · JWT Client Authentication Guide

Key terms

• HS256: HS256 is a JSON Web Token signature algorithm that uses HMAC with SHA-256. It signs the token with a shared secret, so the same key is used to create and verify the signature, which makes secret management and key rotation critical for trust.
• PyJWT Key Confusion Vulnerability: A flaw in JWT verification where the same key material can be interpreted under incompatible cryptographic rules. In this case, DER-encoded public keys could be treated as HMAC secrets when applications mixed symmetric and asymmetric algorithms, enabling forged login tokens.
• DER Encoding: DER encoding is a binary way to represent structured data using a single, unambiguous byte sequence. It is the strict encoding form of ASN.1, used for items such as X.509 certificates, signatures and public keys, where deterministic byte representation matters for parsing, verification and comparison.
• Key Confusion: Key confusion is a token verification flaw where a system uses the wrong cryptographic key type or source to validate a signature. It often happens when the verifier accepts attacker-controlled key identifiers, mixes symmetric and asymmetric key handling, or trusts a token header to choose the verification key.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.