<\/p>\n
Most JWT vulnerabilities<\/strong> are not flaws in the token format. They are flaws in the few lines of code that verify it, and a token that is verified badly still looks like it works. The result is an API that accepts forged or replayed tokens while every happy-path test stays green.<\/p>\n Last updated: 2026-11-02. CVE details and standards status below were checked against the primary sources listed at the end on that date.<\/em><\/p>\n Key takeaways<\/strong><\/p>\n A JSON Web Token carries claims as JSON, wrapped as a signed (JWS) or encrypted (JWE) object. According to RFC 7519<\/a>, the format was published in May 2015.<\/p>\n Most API tokens are signed, not encrypted. A signed token is base64url encoded, so anyone who holds it can read the payload. As the OWASP JSON Web Token Cheat Sheet<\/a> notes, keep sensitive data out of it.<\/p>\n What you get is integrity: the contents were not changed after issue. You only get that if the verifier is strict about which algorithm, which key, and which claims it accepts. RFC 8725<\/a> (the JWT Best Current Practices) exists because libraries left those choices to the caller. Every mistake below lives in that gap.<\/p>\n The JWT header names the algorithm used to sign the token. One legal value is If your verify call lets the token’s header decide, an attacker can strip the signature and your API may still accept it.<\/p>\n This shipped in practice. According to CVE-2022-23540<\/a>, Blocklists do not save you. The OWASP testing guide (WSTG-SESS-10)<\/a> tells testers to try case variants of The standards are tightening further. The IETF working-group draft rfc8725bis<\/a> (a draft, not yet an RFC) would add a MUST for applications to opt in explicitly to How to check:<\/strong> find every verify and decode call in your codebase. Each one should pass an explicit list of allowed algorithms.<\/p>\n Here the server expects an asymmetric algorithm such as RS256. The attacker sends a token that claims This is the oldest repeat offender in the JWT world:<\/p>\n RFC 8725 (section 3.1) says libraries MUST let callers specify allowed algorithms, and that each key should be used with exactly one algorithm. OWASP’s guidance is the same: do not mix public-key and MAC algorithms in one verifier.<\/p>\n How to check:<\/strong> confirm each key maps to exactly one algorithm in code, and that a token claiming a different one is rejected.<\/p>\n With HS256, anyone who captures one valid token can try guesses against it offline. There is no login endpoint to rate-limit and nothing to lock out. RFC 8725 (section 2.2) describes this directly. A weak secret turns into a forged-token factory.<\/p>\n The rules are clear:<\/p>\n The failure pattern we look for is mundane: a placeholder such as How to check:<\/strong> read your production signing key’s source. If a person typed it, replace it with a random value of at least 256 bits and use a different one per service.<\/p>\n JWT headers can carry hints about which key to use: The clearest real case is CVE-2018-0114<\/a>. Cisco’s The other three fail in different ways, according to the OWASP testing guide and RFC 8725 (section 3.10):<\/p>\n How to check:<\/strong> keys should come from your server config, or from a pinned key-set URL for an issuer you already trust. Never from the token itself.<\/p>\n A perfect signature proves who issued the token. It does not prove the token was meant for this<\/em> API, or that it is the kind<\/em> of token you expect.<\/p>\n Say one identity-provider tenant issues tokens for several apps and APIs. If your API never checks the audience ( This is an integration mistake, not a vendor bug. It is easy to make with any identity provider.<\/p>\n ID tokens, email-verification tokens, and refresh tokens are all JWTs too. If your API accepts any validly signed token, one of those can be presented as an access token. RFC 8725 (sections 3.11 and 3.12) recommends explicit Per the OWASP cheat sheet, PyJWT needs the How to check:<\/strong> take a valid token from one service and send it to another. Then try an ID or refresh token on a protected route. Both should fail.<\/p>\n Sometimes your code is right and the runtime is wrong. CVE-2022-21449<\/a> (“psychic signatures”) let Java’s ECDSA implementation accept a signature with The researcher who found it reports a wider range, Java 15 to 18, fixed in the April 2022 Critical Patch Update, and says he reported it to OpenJDK on 11 November 2021. That account is his own write-up<\/a>. We cite NVD for the affected versions and treat the wider range as reported.<\/p>\n The lesson is practical. Patching the runtime and the JWT library is part of auth security. And your tests need negative cases: forged and malformed tokens must fail, not just valid ones succeed.<\/p>\n Here is the defensive version in Python with PyJWT 2.4.0 or later. The key comes from config, the algorithm is pinned, and the claims are required.<\/p>\n The Node equivalent on Note the last comment. A valid token with a missing object-level check is the next bug in line. That is the classic IDOR pattern: the app knows who you are but never asks whether this object is yours.<\/p>\n A JWT is valid until its That is a trade-off, not a reason to avoid JWTs:<\/p>\n This is the order we would fix things, cheapest and highest-impact first.<\/p>\n\n
alg: none<\/code>, algorithm confusion, weak HMAC secrets, trusting keys the token points to, skipping iss<\/code>\/aud<\/code>\/typ<\/code> checks, and unpatched crypto underneath.<\/li>\nWhat a JWT does and does not guarantee<\/h2>\n
Mistake 1: letting the token choose
alg: none<\/code><\/h2>\nnone<\/code>, an unsecured token with no signature at all. RFC 7518<\/a> (section 3.6) says implementations “MUST NOT accept Unsecured JWSs by default.”<\/p>\njsonwebtoken<\/code> for Node, versions up to 8.5.1, could default to none<\/code> when verify()<\/code> was called without an algorithms<\/code> option. It was fixed in 9.0.0. NVD scores it 7.6 and the GitHub CNA scores it 6.4.<\/p>\nnone<\/code> against case-insensitive filters.<\/p>\nnone<\/code>.<\/p>\nMistake 2: algorithm confusion (RS256 key used as an HS256 secret)<\/h2>\n
HS256<\/code>, signed using the server’s public<\/em> key as the HMAC secret. Public keys are, by design, public. A naive library sees “HS256”, takes the key you gave it, and the signature checks out.<\/p>\n\n
jsonwebtoken<\/code> before 4.2.2. NVD rates it CVSS 3.0 9.8.<\/li>\njsonwebtoken<\/code> up to 8.5.1, a key-retrieval misconfiguration issue. NVD rates it 6.3.<\/li>\nMistake 3: a guessable HMAC secret<\/h2>\n
\n
secret<\/code> or changeme<\/code>, a framework’s example value, or a .env.example<\/code> that made it to production. We are describing a pattern, not quoting a statistic.<\/p>\nMistake 4: trusting keys the token points to<\/h2>\n
jwk<\/code> (an embedded key), jku<\/code> and x5u<\/code> (URLs to fetch keys from), and kid<\/code> (a key identifier). Every one of those is attacker-controlled input.<\/p>\nnode-jose<\/code> before 0.11.0 trusted a public key embedded in the token header, so an attacker could re-sign tokens with their own key. NVD rates it 7.5.<\/p>\n\n
kid<\/code> used in a file path or a database lookup opens the door to path traversal or injection.<\/li>\njku<\/code> and x5u<\/code> make your server fetch a URL the attacker chose. That is forgery plus server-side request forgery.<\/li>\nkid<\/code> and allowlist any jku<\/code>\/x5u<\/code> hosts.<\/li>\n<\/ul>\nMistake 5: valid signature, wrong token<\/h2>\n
Replay across services<\/h3>\n
aud<\/code>) claim, a token minted for service A is accepted by service B. RFC 8725 (section 3.9) says that when multiple relying parties share an issuer, aud<\/code> MUST be present and checked.<\/p>\nConfusing token types<\/h3>\n
typ<\/code> values and mutually exclusive validation rules. RFC 9068<\/a> defines typ: at+jwt<\/code> for OAuth access tokens, and resource servers should reject other types.<\/p>\nLibrary gotchas<\/h3>\n
issuer=<\/code> and audience=<\/code> arguments to actually compare values. The verify_iss<\/code>\/verify_aud<\/code> options alone do not. Also pick keys only from the matched issuer’s key set, never a union across issuers.<\/p>\nMistake 6: assuming the crypto underneath is correct<\/h2>\n
r = s = 0<\/code> for any message. ES256 JWTs verified by an affected JVM could be forged. NVD rates it 7.5 and lists Java SE 17.0.2 and 18 as affected.<\/p>\nWhat a correct verify call looks like<\/h2>\n
import jwt # PyJWT >= 2.4.0\n\nclaims = jwt.decode(\n token,\n key=public_key, # from config \/ pinned JWKS for THIS issuer\n algorithms=[\"RS256\"], # explicit allowlist; never read from the token\n audience=\"https:\/\/api.example.com\", # this service only\n issuer=\"https:\/\/auth.example.com\", # exact match\n options={\"require\": [\"exp\", \"iss\", \"aud\"]},\n)\n# Then: check header typ == \"at+jwt\" (if your IdP issues RFC 9068 tokens)\n# and authorize the specific object being requested.<\/code><\/pre>\njsonwebtoken<\/code> 9.0.0 or later is jwt.verify(token, key, { algorithms: ['RS256'], audience, issuer })<\/code>.<\/p>\nRevocation, theft, and what “stateless” costs you<\/h2>\n
exp<\/code> time. Revoking one early means keeping a denylist keyed on jti<\/code> plus issuer (not the raw token) or a status list. OWASP is clear that either one brings state back.<\/p>\n\n
JWT security best practices, in priority order<\/h2>\n
\n
jsonwebtoken<\/code> 9.0.0 or later, PyJWT 2.4.0 or later, and a patched JDK.<\/li>\njwk<\/code>\/x5c<\/code> in headers, allowlist jku<\/code>\/x5u<\/code>, and treat kid<\/code> as untrusted input.<\/li>\nexp<\/code>, iss<\/code>, aud<\/code>,<\/strong> plus typ<\/code> where your provider sets it.<\/li>\nnone<\/code>, the wrong algorithm, the wrong audience, an expired time, or the wrong type must all be rejected.<\/li>\n<\/ol>\nHow long this has been known<\/h2>\n