GHSA-5739-39V2-5754: Bleichenbacher / Marvin Padding Oracle in PHP JWE Decryption (RSAES-PKCS1-v1_5)

JSON Web Encryption (JWE) tokens use key management algorithms to wrap and securely transmit a symmetric Content Encryption Key (CEK). The web-token/jwt-framework library, a prominent PHP suite for JSON Object Signing and Encryption (JOSE) operations, includes support for the RSA1_5 key management algorithm (RSAES-PKCS1-v1_5). In implementations utilizing this algorithm, the private key holder decrypts the encrypted CEK block, validates its integrity, and passes the recovered CEK to downstream symmetric decryption components.

The vulnerability is located within the RSACrypt utility class of the web-token/jwt-library sub-package. When processing incoming JWEs that use the RSA1_5 key encryption mode, the validation routine for PKCS#1 v1.5 padding parameters fails to perform constant-time evaluations. Decryption operations early-terminate and throw structured exceptions when structural discrepancies are encountered.

This behavior exposes a distinct timing and logic side-channel to network-positioned attackers. By adaptively altering JWE ciphertext payloads and measuring response times or observing HTTP error conditions, attackers can differentiate between invalid PKCS#1 padding structures and valid padding with incorrect symmetric keys. This represents a modern realization of the classic Bleichenbacher and Marvin padding oracle attacks.

Under the RSAES-PKCS1-v1_5 standard detailed in RFC 8017, the decrypted RSA block must strictly follow a defined format before the payload message is extracted. The decrypted octet string (EM) has a structured block representation: EM = 0x00 || 0x02 || PS || 0x00 || M. The parameter PS is a padding string comprised of non-zero octets with a minimum length of 8 bytes, and M represents the actual message payload, which in JWE context is the wrapped symmetric key.

To prevent padding oracle side-channels, cryptographic libraries must employ the implicit rejection strategy. If the decrypted block fails padding validation or structure checks, the implementation must generate a deterministic, cryptographically secure pseudo-random payload of matching length in constant time. The implementation must then proceed to perform downstream symmetric decryption with this fake key, failing uniformly at the final authenticated integrity verification step.

Prior to the patch, the RSACrypt::decryptWithRSA15 method inspected the decrypted block sequentially using conditional logical branches. If the first two bytes did not equal 0x00 and 0x02, the function immediately raised an InvalidArgumentException. If the null separator byte was missing or placed such that the padding length was less than 8 bytes, the function similarly raised an exception. This logic established distinct code execution durations and discrete error types, allowing external entities to systematically identify successful PKCS#1 structure decryptions.

The patch modified RSA15.php and RSACrypt.php to transition from conditional branching to constant-time arithmetic extraction. The vulnerability fix introduces an expected CEK length lookup derived from the 'enc' parameter of the JWE header, passing it into the RSA decryption helper to enforce uniform behavior.

// Vulnerable logic in RSACrypt::decryptWithRSA15
if (ord($em[0]) !== 0 || ord($em[1]) > 2) {
    throw new InvalidArgumentException('Unable to decrypt');
}
$ps = substr($em, 2, (int) strpos($em, chr(0), 2) - 2);
$m = substr($em, strlen($ps) + 3, null);
if (strlen($ps) < 8) {
    throw new InvalidArgumentException('Unable to decrypt');
}
return $m;

The patched implementation implements a constant-time parser helper named extractRSA15KeyOrRandom. This method evaluates structural constraints and selects either the parsed candidate key or a random byte string using bitwise operators that avoid branching:

// Patched logic in RSACrypt::extractRSA15KeyOrRandom
private static function extractRSA15KeyOrRandom(string $em, int $expectedKeyLength): string
{
    $k = strlen($em);
    $random = random_bytes($expectedKeyLength);
    if ($k < $expectedKeyLength + 11) {
        return $random;
    }
    $candidate = substr($em, $k - $expectedKeyLength);
    $valid = self::ctEq(ord($em[0]), 0x00) & self::ctEq(ord($em[1]), 0x02);
    $seenSeparator = 0;
    $separatorIndex = 0;
    $psLength = 0;
    for ($i = 2; $i < $k; ++$i) {
        $isZero = self::ctEq(ord($em[$i]), 0x00);
        $firstZero = $isZero & (1 - $seenSeparator);
        $separatorIndex |= $firstZero * $i;
        $psLength += (1 - $seenSeparator) & (1 - $isZero);
        $seenSeparator |= $isZero;
    }
    $valid &= $seenSeparator;
    $valid &= self::ctGe($psLength, 8);
    $messageLength = $k - $separatorIndex - 1;
    $valid &= self::ctEq($messageLength, $expectedKeyLength);
    return self::ctSelect($valid, $candidate, $random);
}

Security engineers should analyze potential edge cases on 32-bit CPU architectures. The constant-time bitwise operations (($diff - 1) >> 63) & 1 assume a 64-bit platform environment. On 32-bit platforms, shifting an integer by 63 bits is undefined behavior in PHP, which can result in functional errors or unexpected timing discrepancies.

An unauthenticated remote attacker can exploit this timing discrepancy by targeting a service endpoint designed to receive and process JWE tokens. The endpoint must support token validation where the target public RSA key is configured to accept key management payloads of algorithm RSA1_5.

The exploitation technique progresses in structured stages. The attacker initializes the attack by taking an existing, valid JWE token and modifying the encrypted_key payload. They generate a sequence of math-derived values based on original ciphertexts using Bleichenbacher's step-by-step algorithms, computing updated structures c' = (c * s^e) mod n.

As each modified payload is submitted, the attacker tracks the server's HTTP response time. The fast-path failure (early rejection) is measurably quicker than the slow-path failure (downstream AEAD authentication error). By logging these variations over thousands of requests, the attacker reconstructs individual byte regions of the wrapped symmetric Content Encryption Key (CEK), ultimately recovering the key and exposing JWE payload data.

The successful execution of this attack compromises the confidentiality of messages encrypted inside JWE tokens. Since the vulnerability allows the extraction of the Content Encryption Key (CEK), any sensitive payload inside the targeted JWE structure can be decrypted offline without requiring access to the server's private key.

This flaw maintains a CVSS v4.0 severity score of 6.3 (Medium), characterized by the vector string CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N. The attack complexity is evaluated as High due to the significant volume of network requests required to execute adaptive queries and the prerequisite of minimal network latency variation to ensure timing measurements are precise.

The vulnerability does not present opportunities for direct remote code execution or integrity modifications of the local target system. However, the exposure of decrypted token payloads, such as session parameters, credentials, or administrative objects, often facilitates horizontal privilege escalation.

To mitigate this security issue, software administrators must immediately upgrade affected packages in their PHP deployments. The vulnerability was resolved in versions 3.4.10 (for the 3.4.x release line), 4.0.7 (for the 4.0.x line), and 4.1.7 (for the 4.1.x line).

If upgrading immediately is not feasible, security administrators should disable the RSA1_5 key encryption algorithm. The use of more modern key encapsulation and wrapping mechanisms, such as RSA-OAEP-256 or ECDH-ES, is highly recommended as they are mathematically structured to resist Bleichenbacher and Marvin style side-channel attacks.

From a monitoring perspective, intrusion detection systems (IDS) and web application firewalls (WAF) should be configured to detect anomalies in token verification patterns. A sharp rise in authentication failures from single source IPs or rapid sequences of token decryptions with invalid symmetric verification results indicates active scanning or exploit attempts.