GHSA-3prj-6hqw-cm82
PHP JWT Library: PBES2-HS*+A*KW unwrap accepts an unbounded p2c iteration count, enabling CPU-amplification denial of service
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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- None
- Availability
- High
What each source reports
GitHub Advisories Score used
PHP JWT Library: PBES2-HS*+A*KW unwrap accepts an unbounded p2c iteration count, enabling CPU-amplification denial of service
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.
- Record
GHSA-3prj-6hqw-cm82- CVSS 4.0
- 8.7 High
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 - Weakness
- CWE-400, CWE-770
- Updated
- 2026-11-02
OSV
PHP JWT Library: PBES2-HS*+A*KW unwrap accepts an unbounded p2c iteration count, enabling CPU-amplification denial of service
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.
- Record
GHSA-3prj-6hqw-cm82- CVSS 4.0
- 8.7 High
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 - Weakness
- CWE-400, CWE-770
- Updated
- 2026-11-02
Affected packages
| Package | Affected | Fixed |
|---|---|---|
web-token/jwt-libraryPackagist | before 3.4.10 | 3.4.10 |
web-token/jwt-libraryPackagist | 4.0.0 up to 4.0.7 | 4.0.7 |
web-token/jwt-libraryPackagist | 4.1.0 up to 4.1.7 | 4.1.7 |
web-token/jwt-frameworkPackagist | before 3.4.10 | 3.4.10 |
web-token/jwt-frameworkPackagist | 4.0.0 up to 4.0.7 | 4.0.7 |
web-token/jwt-frameworkPackagist | 4.1.0 up to 4.1.7 | 4.1.7 |
web-token/jwt-libraryPackagist | before 3.4.10, plus listed versions 3.3.03.3.13.3.23.3.33.3.4 Show 11 moreShow less3.3.53.4.03.4.13.4.23.4.33.4.43.4.53.4.63.4.73.4.83.4.9 | 3.4.10 |
web-token/jwt-frameworkPackagist | before 3.4.10, plus listed versions 3.1.03.1.13.1.23.1.33.1.4 Show 45 moreShow less3.1.53.1.63.1.73.2.03.2.13.2.103.2.23.2.33.2.43.2.53.2.63.2.73.2.83.2.93.3.03.3.0-alpha13.3.0-alpha23.3.0-alpha33.3.13.3.23.3.33.3.43.3.53.4.03.4.13.4.23.4.33.4.43.4.53.4.63.4.73.4.83.4.9v0.0.0v0.0.1v0.0.2v0.1.0v0.2.0v0.2.1v0.2.2v0.2.3v0.3.0v0.3.1v0.3.2v0.4.0 | 3.4.10 |
web-token/jwt-libraryPackagist | 4.0.0 up to 4.0.7, plus listed versions 4.0.14.0.24.0.34.0.44.0.54.0.6 | 4.0.7 |
web-token/jwt-libraryPackagist | 4.1.0 up to 4.1.7, plus listed versions 4.1.14.1.24.1.34.1.44.1.54.1.6 | 4.1.7 |
web-token/jwt-frameworkPackagist | 4.0.0 up to 4.0.7, plus listed versions 4.0.14.0.24.0.34.0.44.0.54.0.6 | 4.0.7 |
web-token/jwt-frameworkPackagist | 4.1.0 up to 4.1.7, plus listed versions 4.1.14.1.24.1.34.1.44.1.54.1.6 | 4.1.7 |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | GitHub Advisories, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
GHSA-3prj-6hqw-cm82 is a high vulnerability (CVSS 8.7) in web-token/jwt-library, published June 18, 2026. No source lists public exploit code. Fixed in web-token/jwt-library 3.4.10.
References
github.com/web-token/jwt-framework/security/advisories/GHSA-3prj-6hqw-cm82
Left out here: 81 versions. The JSON record has them.