GHSA-6vvh-pxr4-25r7: Cryptographic Integrity Degradation in JWT Framework ChaCha20-Poly1305 Key Encryption

The experimental implementation of the Chacha20Poly1305 key-encryption algorithm in the PHP web-token/jwt-framework library contains a critical flaw that undermines the integrity of JSON Web Encryption (JWE) tokens. JWE depends on Authenticated Encryption with Associated Data (AEAD) to protect both the confidentiality of the payload and the integrity of the key wrapping structure.

In standard JWE configurations, key encryption algorithms wrap the Content Encryption Key (CEK) using a Key Encryption Key (KEK). When using ChaCha20-Poly1305, the Poly1305 Message Authentication Code (MAC) tag is expected to secure the wrapped key against unauthorized modifications. This vulnerability, tracked under GHSA-6vvh-pxr4-25r7, arises because the implementation fails to persist and verify this cryptographic tag.

The resulting system suffers from missing support for integrity checks (CWE-353) and improper verification of cryptographic signatures (CWE-347). Because the system permits decryption without verification, the cryptographic mechanism degrades from authenticated encryption to an unauthenticated stream cipher, exposing wrapped keys to active tampering during transit.

The core cryptographic vulnerability lies in how the Chacha20Poly1305 class wraps and unwraps the Content Encryption Key (CEK) using the PHP OpenSSL extension. In a secure ChaCha20-Poly1305 AEAD operation, the cipher generates both ciphertext and a 16-byte authentication tag (Poly1305 MAC) based on the key, nonce, and plaintext. During decryption, this tag must be supplied alongside the ciphertext to verify that no alteration occurred during transit.

Inside the vulnerable encryptKey() function, the library invokes openssl_encrypt() with the chacha20-poly1305 cipher and passes a local variable $tag by reference to capture the generated MAC. Although PHP successfully populates $tag with the 16-byte Poly1305 output, the library fails to store this tag in the JWE header (specifically, $additionalHeader['tag'] is never populated). This step discards the cryptographic guarantee of integrity, sending the JWE token over the wire with only the ciphertext and the nonce.

During decryption, the decryptKey() function extracts the nonce but fails to retrieve or expect a tag. The function calls openssl_decrypt() with only five parameters, omitting the critical sixth parameter which is the expected authentication tag. When PHP's OpenSSL extension is asked to decrypt an AEAD cipher like ChaCha20-Poly1305 without an authentication tag, the extension silently downgrades the operation, treating the cipher as unauthenticated ChaCha20 stream data and bypassing all integrity checks.

To understand the vulnerability, look at the vulnerable implementation of the encryptKey and decryptKey methods in the library. In encryptKey, the $tag reference variable is populated but never exported into the $additionalHeader array. This results in the tag being discarded at the end of the execution scope.

// VULNERABLE
public function encryptKey(JWK $key, string $cek, array $completeHeader, array &$additionalHeader): string
{
    $k = $this->getKey($key);
    $nonce = random_bytes(12);
    $additionalHeader['nonce'] = Base64UrlSafe::encodeUnpadded($nonce);
    $tag = null;
    // The tag is generated by reference but never added to $additionalHeader
    $result = openssl_encrypt($cek, 'chacha20-poly1305', $k, OPENSSL_RAW_DATA, $nonce, $tag);
    if ($result === false || ! is_string($tag)) {
        throw new RuntimeException('Unable to encrypt the CEK');
    }
    return $result;
}

On the decryption side, the decryptKey function similarly omits any verification of the tag. It calls openssl_decrypt using only five arguments, completely ignoring the authentication parameter.

// VULNERABLE
public function decryptKey(JWK $key, string $encrypted_cek, array $header): string
{
    $k = $this->getKey($key);
    $nonce = Base64UrlSafe::decodeNoPadding($header['nonce']);
    if (mb_strlen($nonce, '8bit') !== 12) {
        throw new InvalidArgumentException('The header parameter "nonce" is not valid.');
    }
    // Decryption occurs without providing the $tag parameter
    $result = openssl_decrypt($encrypted_cek, 'chacha20-poly1305', $k, OPENSSL_RAW_DATA, $nonce);
    if ($result === false) {
        throw new RuntimeException('Unable to decrypt the CEK');
    }
    return $result;
}

To correct this vulnerability, the patch implements strict verification on both sides. In the fixed version, the tag is validated to be exactly 16 bytes and is written to $additionalHeader['tag']. On decryption, the presence, type, and length of the tag are enforced, and the tag is explicitly passed as the sixth argument to openssl_decrypt(). This forces OpenSSL to execute the complete AEAD verification phase and fail-closed if the tag has been modified or omitted.

Because ChaCha20 operates as a stream cipher, it generates a pseudo-random keystream based on the key and nonce, which is then combined with the plaintext using a bitwise XOR operation. Without the integrity guarantees provided by Poly1305, stream ciphers are inherently malleable. An attacker who can manipulate the ciphertext during transit can predict the exact change that will occur in the resulting decrypted plaintext.

An adversary-in-the-middle (AitM) on the network transit path can capture the JWE, isolate the encrypted Content Encryption Key (CEK), and apply bitwise modifications. Specifically, flipping the $i$-th bit of the ciphertext results in an identical bit-flip in the $i$-th bit of the decrypted CEK. Since the server-side decryption routine does not validate a MAC, this altered ciphertext decrypts successfully without throwing an error.

Although the resulting modified CEK will subsequently fail the payload decryption stage (because the payload's own AEAD mechanism, such as AES-GCM, will correctly validate its tag), the server's cryptographic behavior is altered. Attackers can leverage the timing differences, error messages, or side-channel responses resulting from the decrypted-yet-corrupt CEK to conduct advanced cryptographic analysis or construct padding oracle style attacks depending on how downstream components handle key validation failures.

The impact of this cryptographic degradation is significant for applications relying on the integrity of JWE key-wrapping. By allowing arbitrary modification of the wrapped Content Encryption Key, the library fails to uphold the primary security objectives of JSON Web Encryption. A compromised CEK decryption path means that cryptographic boundaries within the application are compromised.

The vulnerability is assessed with a CVSS v4.0 score of 5.9 (Medium), indicating high impact on integrity (VI:H) but requiring high attack complexity (AC:H) and an adjacent network position (AV:A). High complexity stems from the need to intercept the tokens and construct mathematically precise bit-flipping attacks that map to valid target states or yield readable side-channels.

Because this vulnerability resides in an experimental component (Chacha20Poly1305), its exposure in standard production environments is limited. The vulnerability is not cataloged in the CISA Known Exploited Vulnerabilities (KEV) database, and there are no reports of active exploitation in the wild, classifying it as a theoretical and developmental risk.

To fully remediate the vulnerability, developers must upgrade the web-token/jwt-library package to a secure release. The maintainers have provided patches in versions 3.4.10, 4.0.7, and 4.1.7. Run the Composer update command to pull the latest updates.

composer update web-token/jwt-library

If upgrading is not immediately possible due to legacy system constraints, you must disable the experimental Chacha20Poly1305 key-encryption algorithm. Modify your AlgorithmManager initialization code to ensure that the experimental class Jose\Experimental\KeyEncryption\Chacha20Poly1305 is not registered. Replace it with standardized, secure algorithms such as AES Key Wrap (AES-KW) or AES-GCM Key Wrap.

use Jose\Component\Core\AlgorithmManager;
use Jose\Component\Encryption\Algorithm\KeyEncryption\A256GCMKW;
 
// Secure configuration omitting Chacha20Poly1305
$keyEncryptionAlgorithmManager = new AlgorithmManager([
    new A256GCMKW(),
]);

This incident highlights a broader lesson in secure development when interacting with cryptographic wrappers. When implementing AEAD ciphers through native bindings like PHP's OpenSSL extension, developers must ensure that default parameters do not silently downgrade the security of the operation. Always design API boundaries to validate key, tag, and nonce properties before invoking cryptographic operations, ensuring the system fails-closed immediately upon encountering missing or malformed inputs.