Composer/Web-Token - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/vendors/composer/web-token/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioThu, 18 Jun 2026 21:15:29 +0000PHP JWT Library PBES2-HS*+A*KW Unbounded p2c Iteration Count Leads to DoShttps://feed.craftedsignal.io/briefs/2026-06-php-jwt-pbes2-dos/Thu, 18 Jun 2026 21:15:29 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-06-php-jwt-pbes2-dos/An unauthenticated attacker can exploit a vulnerability in the PHP JWT Library's PBES2AESKW::unwrapKey() function when processing JWE tokens that use PBES2-HS*+A*KW algorithms by crafting a JWE with an excessively large 'p2c' (PBKDF2 iteration count) parameter in the JOSE header, forcing the server to perform an unbounded and CPU-intensive PBKDF2 computation, resulting in a CPU-amplification denial of service.A high-severity denial-of-service vulnerability (CWE-400) has been discovered in the PHP JWT Library (composer/web-token/jwt-library and jwt-framework), affecting versions prior to 3.4.10, 4.0.7, and 4.1.7. This flaw allows an unauthenticated attacker to trigger an unbounded CPU consumption on a server processing JSON Web Encryption (JWE) tokens. Specifically, when JWEs utilize password-based key-encryption algorithms (PBES2-HS256+A128KW, PBES2-HS384+A192KW, PBES2-HS512+A256KW), the PBES2AESKW::unwrapKey() function reads the p2c (PBKDF2 iteration count) parameter directly from the attacker-controlled JOSE header. The absence of an upper bound on this parameter allows attackers to specify extremely high iteration counts (e.g., 100,000,000 or PHP_INT_MAX), causing the server to expend significant CPU resources on PBKDF2 computations before any key unwrapping validation occurs. This resource exhaustion can lead to severe service degradation or unavailability for targeted applications.

Attack Chain

  1. An unauthenticated attacker crafts a malicious JSON Web Encryption (JWE) token.
  2. The attacker manipulates the protected JOSE header of the JWE to include a p2c (PBKDF2 iteration count) parameter with an arbitrarily large integer value (e.g., 100,000,000 or PHP_INT_MAX).
  3. The attacker sends this crafted JWE token to a vulnerable application endpoint (e.g., via an HTTP header, request body, or URL parameter).
  4. The vulnerable PHP JWT Library receives the JWE and attempts to process it using a registered PBES2-HS*+A*KW algorithm for key unwrapping.
  5. The PBES2AESKW::unwrapKey() function extracts the p2c value from the JOSE header without adequate upper bound validation, as only is_int($p2c) && $p2c > 0 is checked.
  6. The function initiates hash_pbkdf2() with the excessively large p2c value, forcing the server's CPU to perform an intensive, prolonged computation for PBKDF2 key derivation.
  7. The server worker process becomes stalled, consuming significant CPU resources for an extended period (potentially tens of seconds per request), leading to resource exhaustion.
  8. If sufficient malicious JWEs are processed, the application or server becomes unresponsive, resulting in a denial-of-service condition due to uncontrolled resource consumption.

Impact

Successful exploitation of this vulnerability leads to a severe denial-of-service (DoS) condition. Attackers can force target servers to dedicate substantial CPU resources to perform computationally expensive PBKDF2 iterations, effectively stalling worker processes. This resource exhaustion prevents legitimate users from accessing the application, resulting in service unavailability and potential data loss if stateful operations are interrupted. While the vulnerability description does not specify observed victim counts or sectors, any application utilizing the affected PHP JWT Library and configured to accept JWEs with PBES2 algorithms is at risk, particularly those exposed to unauthenticated input. The cost to the attacker for generating the malicious JWE is negligible compared to the server's computational burden.

Recommendation

  • Upgrade the composer/web-token/jwt-library to versions 3.4.10, 4.0.7, or 4.1.7, or composer/web-token/jwt-framework to version 4.1.7 or later, which enforce a DEFAULT_MAX_COUNT = 1_000_000 for p2c.
  • If immediate upgrade is not feasible, implement a custom header checker to validate and limit the p2c header parameter for JWEs before they are processed by the vulnerable library, as described in the source.
  • Disable PBES2 algorithms for JWE decryption if they are not strictly required, especially for tokens originating from untrusted sources.
  • Deploy the provided Sigma rules to your SIEM to detect attempts to exploit this vulnerability or identify applications configured to use the affected PBES2 algorithms.
  • Monitor web server and PHP application logs for HTTP requests containing JWEs that use PBES2 algorithms or include abnormally large p2c values, as described in the detection rules.
]]>mediumadvisorydenial-of-servicewebphpjwtjwecwe-400PHP JWT Framework Algorithm Confusion Vulnerability (TOCTOU)https://feed.craftedsignal.io/briefs/2026-06-php-jwt-algo-confusion/Thu, 18 Jun 2026 21:14:03 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-06-php-jwt-algo-confusion/A Time-of-Check/Time-of-Use (TOCTOU) vulnerability exists in the `JWSVerifier` and `JWEDecrypter` components of the `web-token/jwt-framework` and `web-token/jwt-library` PHP packages, allowing an attacker to override the integrity-protected `alg` parameter from the unprotected header, leading to authentication bypass and unauthorized access.The web-token/jwt-framework and web-token/jwt-library PHP packages are affected by a Time-of-Check/Time-of-Use (TOCTOU) vulnerability that allows attackers to perform algorithm confusion attacks. Specifically, in JWSVerifier::getAlgorithm() and JWEDecrypter, header merging logic (... spread operator or array_merge()) incorrectly prioritizes the unprotected alg (algorithm) parameter over the integrity-protected one when duplicate keys exist. This means that while the protected header's alg might be validated (e.g., RS256), the actual signature verification or decryption might proceed with an attacker-specified alg from the unprotected header (e.g., HS256 or none). This bypasses cryptographic integrity checks, enabling authentication bypass, unauthorized access, or information disclosure, making it critical for applications relying on these libraries for secure JWT handling.

Attack Chain

  1. Initial Access / Reconnaissance: An attacker identifies a web application utilizing JSON Web Tokens (JWTs) for authentication or authorization.
  2. Malicious JWT Creation: The attacker crafts a JWT containing a protected header with a strong, integrity-protected algorithm (e.g., alg: RS256) and an unprotected header specifying a weaker or symmetric algorithm (e.g., alg: HS256 or alg: none), intending for the unprotected alg to override the protected one.
  3. Token Submission: The attacker sends this crafted, malicious JWT to the vulnerable web application, typically within an HTTP Authorization header or as a cookie.
  4. Header Merging (TOCTOU): Upon receiving the JWT, the application's JWSVerifier or JWEDecrypter component merges the protected and unprotected headers. Due to the vulnerability, the alg parameter from the unprotected header overwrites the alg from the protected header in the internal merged array.
  5. Algorithm Validation (Time-of-Check): An initial check (e.g., by HeaderCheckerManager) might validate the alg from the protected header (e.g., RS256), which passes, creating a false sense of security.
  6. Signature/Decryption (Time-of-Use): The JWSVerifier or JWEDecrypter proceeds to verify the JWT signature (or decrypt the payload) using the alg parameter that was overridden by the unprotected header (e.g., HS256 or none).
  7. Authentication Bypass / Data Compromise: If the attacker chose an alg like none or could forge a valid signature for a symmetric key (HS256), the system may successfully validate the JWT.
  8. Impact: This leads to unauthorized access, impersonation of legitimate users, or decryption of sensitive data, allowing the attacker to bypass authentication mechanisms.

Impact

If exploited, this vulnerability leads to a severe authentication bypass, allowing attackers to forge valid JSON Web Tokens (JWTs) and gain unauthorized access to web applications. This could result in full account takeover, privilege escalation, and access to sensitive data or functionality that should be restricted. The impact is significant for applications that rely on web-token/jwt-framework or web-token/jwt-library for secure session management, API authentication, or inter-service communication. Organizations across all sectors using PHP applications with these specific JWT libraries are at risk, as the integrity of their authentication and authorization mechanisms is compromised.

Recommendation

  • Immediately update composer/web-token/jwt-framework to a patched version (e.g., newer than 4.2.99) to address the algorithm confusion vulnerability.
  • Immediately update composer/web-token/jwt-library to a patched version (e.g., >= 3.4.10, >= 4.0.7, >= 4.1.7) to address the algorithm confusion vulnerability.
  • Review application logs for entries indicating JWT verification failures or unexpected algorithm usage for authentication (refer to the Detect JWT Algorithm Verification Errors rule).
  • Ensure verbose application logging is enabled for JWT processing and verification steps to aid in detection of anomalous alg parameter usage (refer to the Detect JWT 'none' Algorithm Usage rule).
  • Deploy the Sigma rules in this brief to your SIEM and tune for your environment, specifically for webserver logs that might contain application-level JWT processing details.
]]>highadvisoryvulnerabilityphpjwtwebauthentication-bypass