Cloud Vulnerability DB
A community-led vulnerabilities database
Vulnerability DatabaseGHSA-jc6j-46g2-xwqc
GHSA-jc6j-46g2-xwqc:
PHP vulnerability analysis and mitigation
Impact
With direct encryption ("alg": "dir"), the application's oct key is the content encryption key (CEK). Neither JWEBuilder nor JWEDecrypter compared its length with the size the content encryption algorithm requires.
The AES-CBC-HMAC-SHA2 algorithms split the CEK into MAC_KEY followed by ENC_KEY, and need keys of 256, 384 and 512 bits for A128CBC-HS256, A192CBC-HS384 and A256CBC-HS512. Given a key of the size the algorithm name suggests (128, 192 or 256 bits), the whole key becomes MAC_KEY and ENC_KEY is empty. PHP's OpenSSL extension pads a short key with zero bytes, so the content is encrypted under an all-zero AES key. Anyone who obtains the token can read it, without any key. The library built and decrypted these tokens without any error.
enc | dir key | AES key actually used |
|---|---|---|
| A128CBC-HS256 | 128 bits | 16 zero bytes |
| A192CBC-HS384 | 192 bits | 24 zero bytes |
| A256CBC-HS512 | 256 bits | 32 zero bytes |
| A128CBC-HS256 | 192 bits | 8 secret bytes, then 8 zero bytes |
| A192CBC-HS384 | 256 bits | 8 secret bytes, then 16 zero bytes |
| A256CBC-HS512 | 384 bits | 16 secret bytes, then 16 zero bytes |
MAC_KEY stays secret, so integrity is not affected, except with an empty key. An empty key ({"kty":"oct","k":""}, which JWKFactory::createFromSecret() returns for an empty string) leaves both keys empty: anyone can read the tokens the application issues and make tokens its decrypter accepts. This holds for AES-GCM too, where an empty key is an all-zero key. | ||
An attacker cannot cause the condition, which depends on the configured key. Nothing warned about it either: no key analyzer reports a 128-bit oct key used with A128CBC-HS256, and conforming implementations refuse such a key, while this library accepted it silently. A key of half the size is an easy mistake, for example JWKFactory::createOctKey(128) for A128CBC-HS256, or a 32-character secret given to JWKFactory::createFromSecret() for A256CBC-HS512. |
Affected configurations
JWE produced with alg set to dir and enc set to A128CBC-HS256, A192CBC-HS384 or A256CBC-HS512, with a key shorter than 256, 384 or 512 bits respectively. With a key of half the required size or less, the content is readable by anyone. With a key between half and full size, only the bytes past the first half of the key protect the content.
With A128GCM, A192GCM and A256GCM, a short key is padded with zero bytes as well: the content is protected by the secret bytes of the key only, and not at all by an empty key.
Not affected: dir keys of the required size or longer, and the other key management modes. Wrapped and encrypted keys were already checked, and keys obtained by key agreement are checked since GHSA-5pj7-wx9m-cjh6.
The AES-CBC-HMAC algorithms checked the key length until 0.5.0 (2017), and AES-GCM never did. Every release since 0.5.0 is affected.
Patches
Fixed in 3.4.13, 4.0.9, 4.1.11 and 4.2.6. JWEBuilder refuses a dir key shorter than the CEK size of the content encryption algorithm, with the InvalidArgumentException ("Invalid CEK size") already used for the other key management modes. JWEDecrypter no longer decrypts with such a key and moves on to the next key of the set, and JWELoader rejects the token as it rejects any token it cannot decrypt.
A dir key longer than the CEK size exposes nothing, because only its first bytes are used, and it keeps working in these releases. It does not conform, though: it is deprecated as of 4.3.0 and refused from 5.0.0.
3.4.13 is the last release of the 3.4 line, which reaches its end of life with it. Upgrade to 4.x to keep receiving fixes.
Compatibility.
- An application whose
dirkey is shorter than the CEK size can no longer build tokens with it, and can no longer decrypt the tokens it issued with it. With a key of half the size or less, those tokens were readable by anyone: consider their content disclosed and replace the key. - Keys of the required size and the other key management modes are not affected.
- From 4.3.0, a longer
dirkey triggers a deprecation notice when it encrypts a token or decrypts one; 5.0.0 refuses it. A token issued with a longer key can be decrypted with the first bytes of that key, as many as the CEK has.
Workarounds
Use a dir key of exactly 256, 384 or 512 bits with A128CBC-HS256, A192CBC-HS384 or A256CBC-HS512, and of 128, 192 or 256 bits with A128GCM, A192GCM or A256GCM, generated randomly (JWKFactory::createOctKey()). Never build a dir key from a text secret or from an environment variable that may be empty. Consider the content of every token already produced with a shorter key as disclosed, and replace the key.
References
- RFC 7518, section 5.2 (AES_CBC_HMAC_SHA2 algorithms), sections 5.2.2.1 and 5.2.3 to 5.2.5 for the key sizes, and section 5.3 (AES GCM)
- GHSA-5pj7-wx9m-cjh6, the same consequence through the ECDH-ES key derivation
- GHSA-4mxj-75j2-j8hc, the same missing length check on the AES key wrapping keys
Credits
Reported by Anthropic's OSS Scanner (ANT-2026-H0WISIVW).
Source: NVD
