vulnerability / NVI-00002831 / Revision 1
PHP JWT Library: PBES2-HS*+A*KW unwrap accepts an unbounded p2c iteration count, enabling CPU-amplification denial of service
OSV carries this publisher advisory for web-token/jwt-library, web-token/jwt-framework, web-token/jwt-library, web-token/jwt-library, web-token/jwt-framework. This is an aggregated source copy; consult the original publisher and compare update dates.
This report has not inspected your inventory, configuration, deployed build, reachability or evidence. A catalog listing and a severity score do not establish exposure or compromise.
01 / Meaning
Why it matters
Published affected context helps an owner decide what evidence to gather. This report has not examined your application.
02 / Applicability
The affected context
Affected versions, configuration prerequisites and known exclusions are public. Confirm each one against the deployed service.
web-token/jwt-library
source listedECOSYSTEM: introduced 0; fixed 3.4.10
### 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
web-token/jwt-framework
source listedECOSYSTEM: introduced 0; fixed 3.4.10
### 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
web-token/jwt-library
source listedECOSYSTEM: introduced 4.0.0; fixed 4.0.7
### 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
web-token/jwt-library
source listedECOSYSTEM: introduced 4.1.0; fixed 4.1.7
### 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
web-token/jwt-framework
source listedECOSYSTEM: introduced 4.0.0; fixed 4.0.7
### 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
web-token/jwt-framework
source listedECOSYSTEM: introduced 4.1.0; fixed 4.1.7
### 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
03 / Response
What to do next
- vendor patch
The original advisory lists fixed boundaries 3.4.10 for web-token/jwt-library. Confirm the publisher’s latest guidance.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database via OSV
- vendor patch
The original advisory lists fixed boundaries 3.4.10 for web-token/jwt-framework. Confirm the publisher’s latest guidance.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database via OSV
- vendor patch
The original advisory lists fixed boundaries 4.0.7 for web-token/jwt-library. Confirm the publisher’s latest guidance.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database via OSV
- vendor patch
The original advisory lists fixed boundaries 4.1.7 for web-token/jwt-library. Confirm the publisher’s latest guidance.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database via OSV
- vendor patch
The original advisory lists fixed boundaries 4.0.7 for web-token/jwt-framework. Confirm the publisher’s latest guidance.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database via OSV
- vendor patch
The original advisory lists fixed boundaries 4.1.7 for web-token/jwt-framework. Confirm the publisher’s latest guidance.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database via OSV
A fixed release is not deployment evidence.
Check current vendor support and compatibility. After making a change, verify the deployed build and relevant runtime conditions. Keep the evidence, owner and time. An updated lockfile alone does not prove what is running.
04 / Limits
What this report cannot establish
- Customer inventory, deployment, reachability and exploitation have not been inspected.
05 / Provenance
Sources you can inspect
Each assertion retains its source. Mirrored records may repeat one underlying publisher; additional links are not independent corroboration.
- GHSA-3prj-6hqw-cm82 ↗
GitHub Advisory Database via OSV · vendor advisory
Observed . GitHub-origin advisory, CC-BY-4.0; OSV is an aggregate copy, not independent corroboration.
Public revision history
Only published revisions appear here. Routine fetches do not create a material-change event.
- Revision 1 ·
First indexed by Null; source disclosure date is shown separately.