CVE-2026-74890 in openssl_encrypt
Summary
by MITRE • 08/17/2026
openssl_encrypt versions before 1.4.0 contain an authentication bypass vulnerability in CamelliaCipher that disables HMAC tag generation and verification when the PYTEST_CURRENT_TEST environment variable is set. Attackers with code execution can set this environment variable to produce unauthenticated ciphertext and bypass integrity protection on encrypted data.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The openssl_encrypt library, specifically versions prior to 1.4.0, contains a critical authentication bypass vulnerability within its CamelliaCipher implementation that fundamentally compromises the integrity of encrypted data under specific environmental conditions. This flaw arises from an improper check or conditional logic error where the presence of the PYTEST_CURRENT_TEST environment variable triggers a code path that disables the generation and verification of HMAC tags. In standard cryptographic operations, authenticated encryption modes such as those utilizing Camellia with HMAC are designed to provide both confidentiality and integrity assurance. The absence of these authentication mechanisms means that while data may remain encrypted and unreadable without the key, it can be modified by an attacker without detection, effectively reducing the security model from authenticated encryption to simple symmetric encryption.
The technical root cause lies in how the library handles test environments versus production execution contexts. By detecting the PYTEST_CURRENT_TEST variable, which is typically used during unit testing phases of software development, the cipher implementation erroneously skips the cryptographic steps required for message authentication code generation and validation. This behavior suggests a debugging or performance optimization feature that was inadvertently left enabled in released versions without adequate safeguards to prevent its activation outside controlled test environments. Consequently, any application relying on this library for secure data transmission or storage becomes vulnerable if an attacker can influence environment variables during the encryption process.
The operational impact of this vulnerability is severe for applications where code execution privileges are attainable by unauthorized actors. If an adversary gains the ability to execute arbitrary code within the context of a service using openssl_encrypt, they can inject the PYTEST_CURRENT_TEST variable into the runtime environment. This action causes subsequent calls to encrypt data to produce ciphertext that lacks integrity protection. An attacker could then intercept this unauthenticated ciphertext, modify it in transit or at rest, and submit it back for decryption. Because the HMAC verification is disabled during encryption due to the environment variable, the system will also likely fail to properly validate the authenticity of incoming encrypted payloads if the same condition persists during decryption, allowing tampered data to be processed as valid.
This vulnerability aligns with CWE-347 Improper Verification of Cryptographic Signature and CWE-16 Configuration, indicating a failure in both cryptographic implementation and secure configuration management. From an ATT&CK perspective, this relates to techniques involving environment variable manipulation for defense evasion or privilege escalation within the application layer. The ability to bypass integrity checks is particularly dangerous as it undermines trust in data sources, potentially leading to further exploits such as SQL injection if decrypted values are used directly in queries without additional sanitization, or logic flaws in business processes that rely on unmodified encrypted tokens.
Mitigation strategies must prioritize immediate upgrading of the openssl_encrypt library to version 1.4.0 or later where this conditional bypass has been removed and proper authentication is enforced regardless of environment variables. For systems unable to upgrade immediately, administrators should implement strict controls over environment variable injection by sanitizing inputs that could affect runtime configurations and ensuring that test-specific flags are never propagated into production environments. Additionally, implementing defense-in-depth measures such as application-level integrity checks for critical data fields can provide a secondary layer of protection against tampering until the underlying library vulnerability is fully remediated.