CVE-2024-25189

What it actually does

The library performs JWT signature or claim verification using non-constant-time strcmp, allowing remote attackers to measure response-time differences and progressively guess valid authentication tokens byte-by-byte over the network.

Why it matters to the business

Attackers can obtain unauthorized access to any system relying on this library for authentication, resulting in data exposure, privilege escalation, and service compromise without requiring credentials or user interaction.

How an attack unfolds

An attacker repeatedly submits modified JWT tokens to an endpoint protected by libjwt, records the server response latency for each guess, and uses the timing differential from strcmp to brute-force a valid token; once obtained, the token grants full authenticated access. Public exploit code is available and the vulnerability has remained unpatched for years.

How to fix it

Replace libjwt with a maintained fork or alternative library that uses constant-time comparison functions (e.g., CRYPTO_memcmp or sodium_memcmp) for all authentication checks; monitor the upstream project for a future release containing the fix and rebuild all dependent applications.

How to confirm the fix worked

Review source code or binary for calls to strcmp (or equivalent) inside JWT verification paths; perform timing analysis tests against authentication endpoints before and after the change to confirm constant-time behavior.

Typical attack path

1. Identify an endpoint that accepts JWTs validated by the vulnerable libjwt library
2. Craft token variations that differ by single bytes in the signature or claims section
3. Measure and compare server response times across many requests to recover the correct token
4. Replay the recovered valid token to access protected resources or APIs

How to detect it

Search authentication and application logs for high volumes of requests to JWT-protected endpoints from single sources with systematically varying token values; correlate with unusual timing patterns or spikes in failed verification attempts.

What your security team should do

• Treat as high-priority because public exploit code exists and the flaw has been known since 2024 without a listed fix
• Inventory all builds and containers that statically or dynamically link the bencollins jwt c library
• Replace the library or implement a local patch using constant-time comparison immediately
• Add runtime detection for anomalous authentication request patterns while the fix is deployed