GHSA-3PRJ-6HQW-CM82: CPU Amplification Denial of Service in web-token JWT Library

The vulnerability tracked under the identifier GHSA-3PRJ-6HQW-CM82 is an uncontrolled resource consumption flaw (CWE-400) within the password-based key-encryption (PBES2) algorithms of the web-token JWT library and framework ecosystem.

Specifically, the issue arises when parsing JSON Web Encryption (JWE) tokens utilizing PBES2-based key wrapping, such as PBES2-HS256+A128KW. The library exposes an unauthenticated attack surface through token parsing endpoints, where any incoming encrypted token is processed prior to validation.

An attacker can exploit this endpoint by specifying an extremely high PBES2 iteration count (p2c) in the JOSE header. Because the library fails to limit this iteration value, the processing server executes an excessively long key derivation cycle, resulting in thread exhaustion.

Under the JSON Web Encryption (JWE) standards outlined in RFC 7518 Section 4.8, PBES2 algorithms utilize the Password-Based Key Derivation Function 2 (PBKDF2) to derive key-wrapping keys. This derivation process relies on two parameters supplied in the JWE header: the salt input (p2s) and the iteration count (p2c).

The vulnerability is located in the PBES2AESKW::unwrapKey() method, which performs the key-unwrapping sequence. Prior to invoking the underlying PBKDF2 function, the method executes validation logic via checkHeaderAdditionalParameters() to ensure the parameters are valid.

However, this validation check was insufficient, verifying only that the p2c parameter was a positive integer. By sending a JWE with an arbitrary, extremely high p2c value (such as 2,147,483,647), an attacker forces the server to call the native PHP hash_pbkdf2() function with that count.

Because PBKDF2 is computationally intensive by design, executing billions of HMAC iterations blocks the executing thread. This execution blocks the backend process before any signature or cryptographic integrity checks are executed.

The vulnerability stems from the absence of a ceiling value for the p2c parameter in the PBES2AESKW abstract class. The following diff demonstrates the modifications applied to resolve this flaw:

--- a/src/Library/Encryption/Algorithm/KeyEncryption/PBES2AESKW.php
+++ b/src/Library/Encryption/Algorithm/KeyEncryption/PBES2AESKW.php
@@ -16,12 +16,16 @@
 use function in_array;
 use function is_int;
 use function is_string;
+use function sprintf;
 
 abstract readonly class PBES2AESKW implements KeyWrapping
 {
+    public const DEFAULT_MAX_COUNT = 1_000_000;
+
     public function __construct(
         private readonly int $salt_size = 64,
-        private readonly int $nb_count = 4096
+        private readonly int $nb_count = 4096,
+        private readonly int $max_count = self::DEFAULT_MAX_COUNT
     ) {
         if (! interface_exists(WrapperInterface::class)) {
             throw new RuntimeException('Please install "spomky-labs/aes-key-wrap" to use AES-KW algorithms');
@@ -139,6 +143,12 @@ protected function checkHeaderAdditionalParameters(array $header): void
         if (! is_int($header['p2c']) || $header['p2c'] <= 0) {
             throw new InvalidArgumentException('The header parameter "p2c" is not valid.');
         }
+        if ($header['p2c'] > $this->max_count) {
+            throw new InvalidArgumentException(sprintf(
+                'The header parameter "p2c" is too large. The maximum allowed value is %d.',
+                $this->max_count
+            ));
+        }
     }

The fix introduces a private parameter $max_count set to a default limit of 1,000,000. Inside checkHeaderAdditionalParameters(), the library compares the incoming p2c value against this ceiling before performing any decryption operations.

If the iteration count exceeds the maximum limit, the method immediately throws an InvalidArgumentException. This terminates token processing before calling hash_pbkdf2(), preventing CPU exhaustion.

To exploit this vulnerability, an attacker constructs a malformed JWE token with an inflated p2c parameter. This attack does not require a valid key, signature, or valid payload data, as the resource consumption occurs during the key derivation phase before ciphertext verification.

First, the attacker identifies an API endpoint that parses and decrypts JWE tokens. The attacker then prepares a JOSE header specifying a PBES2 algorithm and an inflated p2c value, such as 2,147,483,647.

The attacker encodes the JSON header using Base64URL and appends dummy values for the encrypted key, initialization vector, ciphertext, and authentication tag. When this JWE is transmitted via HTTP, the target server immediately blocks its processing worker, resulting in a denial-of-service condition if concurrent requests are sent.

The impact of this vulnerability is classified as High, with a CVSS v4 score of 8.7. The primary threat vector is application-level denial of service due to asymmetric CPU resource consumption.

Because the server performs key derivation prior to validating the cryptographic integrity of the token, the computational cost is highly asymmetric. The attacker spends minimal resources generating a small text string, while the server spends maximum CPU cycles performing billions of hash operations.

On standard hardware, an iteration count of 100,000,000 blocks a single thread for roughly 87 seconds. By sending multiple concurrent requests, an attacker can exhaust all available PHP-FPM worker processes, making the entire web application unavailable to legitimate traffic.

The primary defense against this vulnerability is updating the web-token dependencies to a patched release. Users of the 3.4.x branch should upgrade to 3.4.10, while users of the 4.0.x and 4.1.x branches should upgrade to 4.0.7 and 4.1.7 respectively.

If immediate updates are not feasible, you can mitigate the risk by hardening the constructor parameters. Explicitly configuring a lower, safer maximum limit (such as 10,000) restricts the permissible computational overhead.

Additionally, applications that do not strictly require PBES2 algorithms should remove them from the registered decryption AlgorithmManager. Implementing a custom pre-decryption middleware to parse the JWE header and reject excessive p2c parameters also mitigates the risk.