GHSA-3PRJ-6HQW-CM82

PHP JWT Library: PBES2-HS+AKW unwrap accepts an unbounded p2c iteration count, enabling CPU-amplification denial of service

When a JWE uses a password-based key-encryption algorithm (PBES2-HS256+A128KW, PBES2-HS384+A192KW, PBES2-HS512+A256KW), PBES2AESKW::unwrapKey() reads the p2c (PBKDF2 iteration count) parameter directly from the attacker-controlled JOSE header and passes it to hash_pbkdf2() with no upper bound. The only validation performed (checkHeaderAdditionalParameters()) was is_int($p2c) && $p2c > 0.

An unauthenticated attacker can craft a single JWE whose protected header sets a very large p2c (e.g. 100_000_000 ≈ 87 s of CPU, or PHP_INT_MAX), forcing a worker to spend an arbitrary amount of CPU inside PBKDF2 before the key unwrap can even fail. The decrypter swallows the eventual exception, so the attacker pays almost nothing while the server burns CPU. JSON General serialization (multiple recipients) and multi-key JWKSets multiply the cost. This is a classic uncontrolled-resource-consumption (CWE-400) denial of service.

Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.

Kodem intelligence

Already deployed Kodem?

PBES2AESKW now enforces a configurable maximum iteration count (DEFAULT_MAX_COUNT = 1_000_000, well above realistic legitimate values which are a few thousand) in checkHeaderAdditionalParameters(), before any PBKDF2 computation. The bound is exposed as a constructor argument so operators can tune it.

1. What is GHSA-3PRJ-6HQW-CM82? GHSA-3PRJ-6HQW-CM82 is a high-severity uncontrolled resource consumption vulnerability in web-token/jwt-library (composer), affecting versions < 3.4.10. It is fixed in 3.4.10, 4.0.7, 4.1.7. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
2. Which packages are affected by GHSA-3PRJ-6HQW-CM82?
   • web-token/jwt-library (composer) (versions < 3.4.10)
   • web-token/jwt-framework (composer) (versions < 3.4.10)
3. Is there a fix for GHSA-3PRJ-6HQW-CM82? Yes. GHSA-3PRJ-6HQW-CM82 is fixed in 3.4.10, 4.0.7, 4.1.7. Upgrade to this version or later.
4. Is GHSA-3PRJ-6HQW-CM82 exploitable, and should I be worried? Whether GHSA-3PRJ-6HQW-CM82 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether GHSA-3PRJ-6HQW-CM82 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix GHSA-3PRJ-6HQW-CM82?
   • Upgrade web-token/jwt-library to 3.4.10 or later
   • Upgrade web-token/jwt-library to 4.0.7 or later
   • Upgrade web-token/jwt-library to 4.1.7 or later
   • Upgrade web-token/jwt-framework to 3.4.10 or later
   • Upgrade web-token/jwt-framework to 4.0.7 or later
   • Upgrade web-token/jwt-framework to 4.1.7 or later

Other vulnerabilities in web-token/jwt-library