CVE-2025-30204

What it actually does

The parse.ParseUnverified function splits untrusted input on periods via strings.Split, resulting in O(n) allocations proportional to input length when the Authorization header contains many period characters.

Why it matters to the business

Applications relying on this library for token handling can suffer denial of service through memory exhaustion, disrupting authentication flows and service availability; although published over a year ago with low exploit probability and no ransomware usage, its presence in Debian packages and Go ecosystems creates ongoing exposure for dependent services.

How an attack unfolds

An attacker sends an HTTP request whose Authorization header begins with 'Bearer ' followed by a large number of '.' characters; when the target application invokes parse.ParseUnverified on this untrusted data, the library performs excessive allocations leading to resource exhaustion.

How to fix it

Upgrade golang-jwt to version 5.2.2 or 4.5.2; on Debian 13 systems install package version 6.12.3-1 or later.

How to confirm the fix worked

Confirm golang-jwt version meets or exceeds 5.2.2 / 4.5.2 (or Debian package 6.12.3-1); replay a test request with an Authorization header of several thousand periods and verify memory usage remains bounded.

Typical attack path

1. Craft HTTP request containing 'Bearer ' followed by thousands of period characters in the Authorization header
2. Target an endpoint that performs JWT parsing without prior verification
3. Invoke ParseUnverified on the malicious header value
4. Trigger O(n) memory allocations causing service degradation or crash

How to detect it

Search web-server and application logs for Authorization headers containing unusually long sequences of period characters; correlate spikes in memory consumption with authentication endpoints.

• Authorization: Bearer \.{1000,}
• strings containing repeated '.' characters in HTTP auth headers
• high allocation counts in jwt.ParseUnverified calls

What your security team should do

• Upgrade all instances of golang-jwt to a fixed version without delay
• Audit Go applications for direct or transitive use of the vulnerable library
• Add length limits or sanitization on incoming Authorization headers as a defense-in-depth measure
• Review memory and request-volume monitoring to detect similar resource-exhaustion attempts