Token Time Bomb: Evaluating JWT Implementations for Vulnerability Discovery

Token Time Bomb: Evaluating JWT Implementations for Vulnerability Discovery

Speakers: Jingcheng Yang

Conference: NDSS Symposium

YouTube: https://www.youtube.com/watch?v=CKSAgJsPsps

Overview

This research presents JWTable, the first systematic framework for automatically discovering vulnerabilities in JWT (JSON Web Token) implementations. By combining grammar-based fuzzing with differential analysis, the tool evaluated 43 JWT libraries across 10 programming languages and discovered 31 new vulnerabilities with 20 CVEs assigned. The vulnerabilities span three critical categories: sign/encryption confusion (authentication bypass), algorithm confusion (signature forgery), and JWT format confusion (payload spoofing), plus two denial-of-service categories via CPU and memory exhaustion.

The research also identified a real-world authentication bypass in Kubernetes (via the Go-JOSE library) and a pre-authentication denial-of-service in Apache James mail server. Proposed mitigations have been acknowledged and incorporated into the IETF RFC draft, making this research directly shape the JWT specification going forward.

Background

▶ Watch: JWT basics: JWS vs JWE and real-world adoption (0:00)

JSON Web Tokens (JWT) are compact, self-contained credential tokens widely adopted by industry leaders including Cloudflare, Kubernetes, Let's Encrypt, and Microsoft. JWTs come in two forms: JWS (JSON Web Signature) for integrity protection with visible payloads (three dot-separated parts), and JWE (JSON Web Encryption) for confidentiality with hidden payloads (five dot-separated parts).

JWT's flexibility and feature-rich specification inadvertently create opportunities for implementation vulnerabilities. A notable example is CVE-2023-29357 in Microsoft SharePoint, where a forged JWT led to admin privileges and remote code execution. Despite the severity of JWT vulnerabilities, most have been discovered manually in prior research, potentially leaving many overlooked.

The JWT ecosystem involves complex interactions between cryptographic algorithms, key types, encoding formats, and specification-defined claims that create a large surface for implementation errors and specification ambiguities.

Key Findings

▶ Watch: Grammar-based JWT generation with UCT optimization (4:00)

31 new vulnerabilities discovered across 43 libraries with 20 CVEs assigned. The systematic evaluation covered libraries in 10 programming languages, selected from jwt.io based on GitHub star count (minimum 100 stars for the top 16 languages).

Five vulnerability categories identified:

1. Sign/encryption confusion -- Implementations determine JWT type by counting dots; an attacker can craft a JWE encrypted with a public key that gets processed as a JWS, resulting in authentication bypass.
2. Algorithm confusion -- The classic RS256-to-HS256 attack: attacker changes the algorithm header and re-signs with the public key used as HMAC secret; vulnerable implementations trust the algorithm claim.
3. JWT format confusion -- RFC allows only compact format for JWT, but JWS RFC also defines JSON format; some implementations accept JSON format, enabling payload spoofing through custom fields.
4. CPU exhaustion (billing hashes) -- The P2C claim in PBES2 specifies hash iteration count; attackers set it to extremely large values (e.g., 1 billion), causing excessive hash computation.
5. Memory exhaustion (compression DoS) -- The zip header enables payload decompression; attackers craft JWE with highly compressed data that expands massively during decompression.

Kubernetes authentication bypass discovered. The API server extracts the iss claim by dot-splitting (assuming compact format) but delegates verification to Go-JOSE, which also accepts JSON format. An attacker crafts a JSON JWT with a spoofed issuer field; Go-JOSE verifies the real signature, but the API server reads the forged issuer. The same vulnerability was found in OpenShift.

Apache James pre-auth DoS. The mail server accepts the zip claim in JWS headers (violating RFC) and decompresses the payload before signature verification. An attacker sends a JWT with compressed data -- no credentials needed -- causing memory exhaustion.

Mitigations incorporated into IETF RFC draft. The researchers' proposals were acknowledged by IETF and are being incorporated into the JWT specification.

Technical Deep Dive

▶ Watch: Sign/encryption confusion and algorithm confusion attacks (8:00)

JWTable's architecture has two main modules:

Rule Generator: Extends traditional ABNF grammar with two new constructs: func (calls cryptographic functions within grammar rules, e.g., Base64 encoding, HMAC signing) and if (selects which function to call based on preceding claim values, e.g., HMAC vs RSA based on algorithm claim). The FBNF grammar is parsed into concrete syntax trees (CSTs) which are merged into a unified directed FBNF graph.

Grammar-Based Fuzzing Module: Uses depth-first traversal of the FBNF graph with node-type-specific strategies:

• AND nodes: Traverse all subtrees
• OR nodes: Select subtrees using UCT (Upper Confidence Bound for Trees) algorithm
• RAND nodes: Randomize traversal count
• FUNC nodes: Traverse subtrees and call the function
• IF nodes: Select function based on preceding values

Mutator applies two-level random mutation: structure-level (delete/replace non-terminal nodes) and content-level (insert/delete characters in terminal values).

UCT Update provides feedback-driven optimization: if >50% of implementations accept a JWT, the selection path is marked successful with increased weight, biasing future exploration toward more likely-accepted structures.

Differential Analyzer detects vulnerabilities in two ways: (1) Between implementations -- comparing parse/accept results across libraries for the same JWT input, and (2) Within implementations -- detecting abnormal CPU and memory usage using Chebyshev's inequality for statistically significant deviations.

Testing generated 100,000 test cases, producing 1,840 differences across implementations. The false positive rate was 35%, all from implementation-specific feature differences in sign/encryption confusion.

Demo / Proof of Concept

▶ Watch: Format confusion and DoS via billion hashes and compression bombs (10:00)

Kubernetes authentication bypass: Crafting a JSON-format JWT with a spoofed issuer field bypasses Kubernetes API server authentication. Go-JOSE verifies the signature on the JSON format, but the API server extracts claims by dot-splitting the compact format assumption. Bug bounty awarded; same vulnerability found in OpenShift with CVE assigned.

Apache James pre-auth DoS: Sending a JWT with a zip header containing compressed data to the SMTP authentication endpoint causes memory exhaustion before any signature verification occurs. No credentials required. Fixed by Apache.

Ablation study: Without UCT update, coverage grows slower and vulnerability discovery takes longer. Without the mutator, vulnerability types are missed entirely. JWTable achieves higher coverage and discovers all five vulnerability types automatically, compared to existing tools (JWTTwist, JWT_Editor) which only detect known vulnerabilities using predefined payloads.

Defensive Implications

▶ Watch: Root causes, mitigations, and IETF RFC draft adoption (14:00)

The research identifies three root causes and proposes mitigations at specification and implementation levels:

Root Cause 1: Misunderstanding algorithm/key usage. Implementations fail to enforce algorithm-key compatibility, allowing key confusion attacks. Mitigation: Strictly bind keys to allowed algorithms; enforce user-specified algorithm constraints rather than trusting the token's algorithm claim.

Root Cause 2: Non-compliant implementation. Libraries accept formats not allowed by RFC (JSON format JWS when processing JWT) and accept invalid claim usage (zip in JWS). Mitigation: Strictly follow RFC specifications; reject non-compliant formats.

Root Cause 3: Insufficient security warnings. Dangerous claims (P2C, zip) lack explicit limits; security guidance is outdated. Mitigation: Limit P2C claim size; set upper limits on decompression size; recommend enforcing the use claim in JWK.

Immediate actions for organizations: Audit which JWT libraries are in use across your stack. Check against the 20 assigned CVEs. Ensure algorithm-key binding is enforced. Consider whether pre-verification decompression is enabled. Test with JWTable (to be open-sourced on GitHub).

Key Takeaways

• 31 new JWT vulnerabilities discovered across 43 libraries in 10 languages, with 20 CVEs assigned
• Three critical vulnerability categories: sign/encryption confusion, algorithm confusion, and format confusion enable authentication bypass
• Two DoS categories: billion-hash CPU exhaustion via P2C claim and compression bomb memory exhaustion via zip header
• Kubernetes authentication bypass discovered via JSON format confusion between Go-JOSE and API server
• Apache James pre-auth denial-of-service requires no credentials -- just a crafted JWT to the SMTP endpoint
• Proposed mitigations incorporated into IETF RFC draft, directly improving the JWT specification
• JWTable to be open-sourced as the first systematic JWT vulnerability discovery framework

About the Speaker(s)

Jingcheng Yang is the first author but was unable to attend in person. The talk was presented by Joy Jang, an MPG student from the University of Technology Sydney. The research team focuses on web security, authentication protocol analysis, and automated vulnerability discovery through grammar-based fuzzing.