Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
JWSVerifier::getAlgorithm() in src/Library/Signature/JWSVerifier.php (line 144) merges protected and unprotected headers using PHP's spread operator: In PHP, when spreading arrays with duplicate string keys, the last array's values take precedence. Since the unprotected header (getHeader()) is spread second, an attacker can override the integrity-protected alg parameter by placing a different value in the unprotected header. This creates a Time-of-Check/Time-of-Use (TOCTOU) vulnerability: 1. HeaderCheckerManager validates alg from the protected header 2. JWSVerifier uses alg from the unprotected header for actual verification The same issue exists in JWEDecrypter.php (lines 120-124) where arraymerge() exhibits the same last-wins behavior for alg and enc. Affected Code JWSVerifier.php line 144 — Spread operator merge order allows unprotected header to override alg: JWEDecrypter.php lines 120-124 — arraymerge() with same last-wins behavior: Attack Vectors Vector A — Mixed key…
Recommended action: Upgrade to 4.1.7, 4.0.7 or 3.4.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 hashpbkdf2() with no upper bound. The only validation performed (checkHeaderAdditionalParameters()) was isint($p2c) && $p2c 0. An unauthenticated attacker can craft a single JWE whose protected header sets a very large p2c (e.g. 100000000 ≈ 87 s of CPU, or PHPINTMAX), 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+AKW…
Recommended action: Upgrade to 4.1.7, 4.0.7 or 3.4.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.