JWT Vulnerabilities.

JSON Web Tokens carry authentication and authorization claims, but the flexibility of their header-declared signing algorithm has produced several recurring vulnerability classes. The alg=none bug, disclosed by Tim McLean in 2015, occurs when a verifier trusts the token's own alg header and dispatches to a "none" verifier that returns true for an empty signature — letting an attacker rewrite the payload and drop the signature. It was fixed in Node's jsonwebtoken before 4.2.2 (CVE-2015-9235).

Key confusion (CVE-2016-10555) is subtler: if a server accepts both RS256 and HS256, an attacker signs a token with HMAC using the server's public RSA key as the shared secret; a naive verifier feeds that public key into HS256.verify() and the forgery passes. Related issues include weak HS256 secrets crackable offline with hashcat, missing exp/nbf checks, and header-injection sinks — kid path traversal or SQL injection, and attacker-controlled jwk/jku/x5u fields that point verification at a key the attacker owns. In 2022, CVE-2022-23529 in jsonwebtoken raised RCE concerns via a crafted key object (later retracted after exploit prerequisites were disputed).

Defences: pin the accepted algorithm(s) server-side and never read alg from untrusted input, use strong asymmetric keys, validate kid against an allowlist, ignore embedded key URLs, enforce expiry, and treat every JWT field as hostile input.

flowchart TD
  A[Attacker gets a valid JWT] --> B{Tamper header}
  B -->|alg none, drop sig| C[Verifier skips check?]
  B -->|RS256 to HS256| D[HMAC with public key]
  B -->|jku / kid points to attacker key| E[Verify against rogue key]
  C -->|Yes| F[Forged token accepted]
  D -->|Yes| F
  E -->|Yes| F
  F --> G[Privilege escalation / auth bypass]
  C -->|Pinned alg| H[Rejected]
  D -->|Pinned alg| H
  E -->|Allowlist kid| H