CVE-2026-74887 in openssl_encrypt
Summary
by MITRE • 08/17/2026
openssl_encrypt before 1.4.0 imports Python's non-cryptographic 'random' module (Mersenne Twister PRNG) at line 15 of openssl_encrypt/modules/pqc.py. No direct calls to random.* were present in the code, so no cryptographic operation is currently affected; however, the import creates a hazard that future code could inadvertently use random.randint() instead of a cryptographically secure alternative (secrets/os.urandom), producing predictable values since the Mersenne Twister state can be recovered from approximately 624 outputs. Fixed by removing the import in 1.4.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in openssl_encrypt prior to version 1.4.0 stems from an improper implementation of random number generation practices within the Python module pqc.py. Specifically, line fifteen of this file imports Python's standard library random module, which implements the Mersenne Twister pseudo-random number generator. While a static analysis or immediate code review might not reveal direct invocations of functions such as randint() in the existing logic, the mere presence of this import establishes a dangerous precedent and creates a latent security risk. The core issue is that the Mersenne Twister algorithm is designed for simulation and modeling purposes rather than cryptographic applications because its internal state can be reconstructed if an attacker observes approximately 624 consecutive output values. This predictability renders any random numbers generated using this module unsuitable for security-sensitive operations such as key generation, nonce creation, or session token assignment.
From a technical perspective, the flaw represents a failure to adhere to secure coding standards regarding entropy sources. In cryptographic contexts, it is imperative to utilize cryptographically secure pseudo-random number generators that draw from operating system-level entropy pools, typically accessed via modules like secrets in Python 3.6+ or functions such as os.urandom(). These alternatives are designed to be non-deterministic and resistant to state recovery attacks. By importing the standard random module, even if unused at present, the codebase introduces a potential attack vector where future developers might inadvertently rely on this weaker source of randomness. If any part of the application logic were modified to use random.randint() or similar functions for generating cryptographic material, an adversary could potentially predict these values by analyzing sufficient output data, thereby compromising the confidentiality and integrity of encrypted communications or authentication mechanisms.
The operational impact of this vulnerability is primarily related to future risk rather than immediate exploitation in the current codebase version. Since no direct calls to random.* were present, existing deployments are not immediately vulnerable to state recovery attacks via this specific import path. However, the presence of the import lowers the barrier for accidental misuse during subsequent development cycles. If a developer adds functionality that relies on randomness without verifying the source, they may unknowingly introduce a critical weakness into the system. This could lead to scenarios where encryption keys are generated with predictable patterns, allowing attackers to decrypt sensitive data or forge authentication tokens. The severity is mitigated by the fact that no cryptographic operations currently depend on this module, but it remains a significant code quality and security hygiene issue that must be addressed to prevent future regressions.
To mitigate this vulnerability, the import of the random module was removed in version 1.4.0, ensuring that only cryptographically secure alternatives are available for use within the pqc.py module. This fix aligns with industry best practices recommended by standards such as CWE-338, which classifies the use of a pseudo-random number generator not designed for security purposes as a weakness. Furthermore, this remediation supports adherence to ATT&CK techniques related to resource hijacking or defense evasion if an attacker were attempting to manipulate system resources through predictable states, although in this case, it is more accurately categorized under CWE-330: Use of Insufficiently Random Values. Developers should enforce the use of secrets module for all random number generation needs and implement static analysis tools that flag imports of non-cryptographic random modules in security-sensitive code paths to prevent similar issues from arising in future updates.