CVE-2026-74872 in openssl_encrypt
Summary
by MITRE • 08/17/2026
openssl_encrypt versions before 1.4.0 contain an arbitrary code execution vulnerability in the Whirlpool hash implementation that uses broad glob patterns to load .so modules without integrity verification. Attackers can place malicious .so files matching the whirlpool*py313*.so pattern in site-packages directories to achieve native code execution when the module is loaded.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in openssl_encrypt versions prior to 1.4.0 represents a critical security flaw rooted in insecure dynamic library loading mechanisms within its Whirlpool hash implementation. This issue stems from the use of broad glob patterns, specifically targeting files matching the pattern whirlpoolpy313.so, to locate and load shared object modules during runtime. The fundamental technical failure lies in the absence of integrity verification for these dynamically loaded libraries. When the application initializes or invokes functions related to Whirlpool hashing, it scans designated directories such as site-packages for any file that satisfies the glob pattern. Because there is no cryptographic signature validation, checksumming, or strict path canonicalization performed before loading, the system blindly trusts and executes code contained within any matching .so file found in those locations. This design choice creates a significant attack surface where an attacker with write access to the site-packages directory can inject malicious native code that will be executed by the vulnerable application upon invocation of the affected functionality.
From a technical perspective, this vulnerability is classified under CWE-94 as Improper Control of Generation of Code or Command, specifically involving injection via dynamic library loading. The lack of integrity checks means that the confidentiality and integrity guarantees typically provided by cryptographic libraries are undermined at the infrastructure level before any actual encryption or hashing takes place. By placing a malicious .so file in the site-packages directory, an attacker can achieve arbitrary code execution with the privileges of the user running the openssl_encrypt process. This is particularly dangerous because shared object files contain compiled native machine code, allowing for full control over the application's memory space and system state. The specific targeting of py313 suggests a dependency on Python 3.13 environments, indicating that this vulnerability affects systems utilizing this specific version of the Python interpreter alongside the vulnerable openssl_encrypt package.
The operational impact of this flaw is severe, as it allows for remote or local code execution depending on how the application is deployed and who has access to the file system. If the service runs with elevated privileges, such as root or a high-privilege user account, an attacker could gain complete control over the underlying operating system. This can lead to data exfiltration, installation of backdoors, lateral movement within a network, or denial of service through resource exhaustion or memory corruption techniques embedded in the malicious library. The vulnerability is particularly insidious because it does not require direct exploitation of cryptographic algorithms but rather exploits the build and deployment environment's trust assumptions regarding third-party modules. Attackers could potentially exploit this during CI/CD pipeline stages if they have access to artifact repositories, or post-compromise by modifying installed packages on a compromised server where site-packages are writable.
To mitigate this vulnerability, organizations must immediately upgrade openssl_encrypt to version 1.4.0 or later, which presumably implements strict integrity verification for loaded modules. In the interim, administrators should enforce restrictive file permissions on site-packages directories to prevent unauthorized users from writing .so files that match the vulnerable glob pattern. Additionally, implementing application-level controls such as disabling dynamic loading of unverified libraries where possible can reduce risk. Security teams should also audit their deployment pipelines and production environments for any instances of broad glob-based library loading without subsequent integrity checks, aligning with ATT&CK technique T1059 which covers command and script interpretation through native APIs. Regular monitoring of file system changes in critical directories like site-packages using intrusion detection systems can provide early warning indicators of such exploitation attempts.