GitHub Advisoryadvisory · Packagist
GHSA-3prj-6hqw-cm82 PHP JWT Library: PBES2-HS*+A*KW unwrap accepts an unbounded p2c iteration count, enabling CPU-amplification denial of service
HIGH
Official page ↗
- Ecosystem
- Packagist
- Packages
- web-token/jwt-library, web-token/jwt-framework
- Severity
- High
- CVSS vector
- CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
- Weaknesses
- CWE-400, CWE-770
- Reviewed
- 2026-06-18
Affected packages
• Packagist web-token/jwt-library: < 3.4.10 → fixed in 3.4.10
• Packagist web-token/jwt-framework: < 3.4.10 → fixed in 3.4.10
• Packagist web-token/jwt-library: >= 4.0.0, < 4.0.7 → fixed in 4.0.7
• Packagist web-token/jwt-library: >= 4.1.0, < 4.1.7 → fixed in 4.1.7
• Packagist web-token/jwt-framework: >= 4.0.0, < 4.0.7 → fixed in 4.0.7
• Packagist web-token/jwt-framework: >= 4.1.0, < 4.1.7 → fixed in 4.1.7
Description
Impact
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.
Affected configurations
Applications that register any `PBES2-HS*+A*KW` algorithm in their decryption `AlgorithmManager`.
Patches
`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.
Workarounds
Before upgrading: validate/limit the `p2c` header with a custom header checker, or do not enable PBES2 algorithms for untrusted tokens.
References
• RFC 7518 §4.8 (PBES2)
• CWE-400: Uncontrolled Resource Consumption
Résolution
Un correctif a été préparé sur une branche dédiée basée sur `3.4.x`, avec des tests anti-régression dédiés (fork privé temporaire de cette advisory, PR #1).
PBES2 — `PBES2AESKW::unwrapKey()` borne désormais le paramètre `p2c` (constante `DEFAULT_MAX_COUNT = 1_000_000`, configurable via le constructeur) avant tout appel à `hash_pbkdf2()`, empêchant l'amplification CPU (DoS).
Validation : `php -l` OK, PHPUnit vert, aucune nouvelle erreur PHPStan introduite (différentiel nul vs `3.4.x`), aucun commentaire ajouté dans le code source. Après merge, cascade prévue `3.4.x → 4.0.x → 4.1.x`.
Related
References
- https://github.com/web-token/jwt-framework/security/advisories/GHSA-3prj-6hqw-cm82 web
- https://github.com/FriendsOfPHP/security-advisories/blob/master/web-token/jwt-library/GHSA-3prj-6hqw-cm82.yaml web
- https://github.com/web-token/jwt-framework package
- https://github.com/web-token/jwt-framework/releases/tag/3.4.10 web
- https://github.com/web-token/jwt-framework/releases/tag/4.0.7 web
- https://github.com/web-token/jwt-framework/releases/tag/4.1.7 web