GHSA-wwq7-mh3q-hwrh: 
PHP Schwachstellenanalyse und -minderung

Impact

On PHP installations without the GMP extension, a single small JWE using ECDH-ES or ECDH-ES+A128KW/A192KW/A256KW keeps a worker busy for seconds, or minutes, before it is rejected. No key and no valid token are needed, only the curve of the recipient's EC key (P-256, P-384, P-521 or a Brainpool curve). AbstractECDH::calculateAgreementKey() asks OpenSSL for the shared secret. When OpenSSL refuses the public key, the failure is swallowed and the pure PHP elliptic curve code takes over. checkKey() verifies that the epk members exist but not their length, and that fallback converts x and y to big integers with brick/math before any range check. Without GMP, that conversion is cubic in the length of the coordinate with brick/math's native calculator, and quadratic with BCMath. Measured with one compact token, one recipient and one P-256 key (PHP 8.5, brick/math 1.0):

Affected configurations

Applications that decrypt ECDH-ES or ECDH-ES+A*KW tokens with an EC key on PHP without the GMP extension, for instance encrypted request objects or ID tokens. Without BCMath, a 2 kB token, which fits in an HTTP header, is enough. With BCMath, the token must be tens of kilobytes. The GMP and BCMath extensions are suggested by the library, not required. Not affected: X25519 and X448 keys, and installations with the GMP extension. The recipient limit and the JSON decoding limit introduced by other advisories do not cover this case: one compact recipient is enough, and the coordinate is a single string. The pure PHP fallback has used brick/math, and therefore run without GMP, since 2.2.0. Every release since then is affected.

Patches

Fixed in 3.4.13, 4.0.9, 4.1.11 and 4.2.6. 3.4.13 is the last release of the 3.4 line. When OpenSSL can load the recipient's private key, it now computes the agreement and its refusal of the public key is final: the pure PHP elliptic curve code no longer checks a refused epk a second time, and its curve object is only built when that code runs. That code is kept for private keys OpenSSL cannot load and for installations without openssl_pkey_derive(); there, a coordinate longer than the curve is refused before it is converted to a big integer. On PHP without GMP and BCMath, the tokens of the table above are rejected in a few milliseconds, an epk that is not on the curve costs less than a millisecond per attempt, and a legitimate token is decrypted in 1 to 3 ms. Compatibility. Every valid key and token gives the same result as before. The changes concern invalid input:

• an invalid public key (not on the curve, a coordinate longer than the curve, an empty coordinate) is rejected with RuntimeException("Unable to derive the key"), where the pure PHP code raised other messages; an empty x used to raise an exception of brick/math, or an InvalidArgumentException from 4.1 on. JWEDecrypter and JWELoader reject such tokens as before;
• ECDH-SS with a sender key on another curve than the recipient key is now refused with the same exception. It used to return a key the other party could not derive, so the token it produced could not be decrypted;
• on 3.4, PHP 8.5 no longer raises a deprecation notice for each ECDH operation (the $key_length argument of openssl_pkey_derive() is no longer passed).

Workarounds

Install the GMP extension. Otherwise, refuse tokens whose epk coordinates are longer than the curve size before decryption (a header checker when JWELoader is used), and bound the size of the tokens you accept.

References

• RFC 7518, section 4.6 (ECDH-ES) and section 6.2.1 (the coordinates are the full size of a coordinate of the curve)
• NIST SP 800-56A Rev. 3, section 5.6.2.3 (public key validation)

Credits

Reported by Anthropic's OSS Scanner (ANT-2026-F5AOY80H).