Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-17T11:16:41.560Z",
  "pubdate": "2026-08-17T11:16:41.560Z",
  "executiveSummary": "An arbitrary code execution vulnerability exists in openssl_encrypt versions prior to 1.4.0 within the Whirlpool hash implementation.\nThe vulnerability arises from the insecure loading of shared object (.so) modules using overly broad glob patterns without cryptographic integrity verification.\nImpacted systems include any deployments utilizing affected versions of openssl_encrypt where untrusted file placement is possible within site-packages directories.\nAn attacker capable of placing a maliciously crafted shared object file matching the specified glob pattern into a target directory can achieve native code execution upon module load.\nThis introduces severe risk implications, including potential complete system compromise, privilege escalation, and unauthorized execution of native code within the context of the running process.\nSuccessful exploitation requires local file system write access to plant the malicious module, allowing unauthorized actors to execute arbitrary code when the application initiates the vulnerable Whirlpool hash component.",
  "technicalDetails": "The root cause of the vulnerability resides in the Whirlpool hash implementation component of openssl_encrypt versions prior to 1.4.0, which dynamically loads native shared object modules utilizing unconstrained glob patterns.\nSpecifically, the loading mechanism searches for and loads compiled binaries matching the pattern whirlpool*py313*.so within Python site-packages directories.\nThe implementation fails to perform integrity checks, cryptographic validation, or secure path resolution on the dynamically loaded modules before execution.\nThe attack flow proceeds as follows: First, an attacker leverages local file system access or an independent vector (such as an insecure file upload or dependency confusion scenario) to place a malicious .so file into a monitored site-packages directory.\nThe filename of the malicious payload is crafted to match the wildcard pattern whirlpool*py313*.so expected by the vulnerable loading routine.\nSecond, when the application or user invokes the vulnerable openssl_encrypt module and triggers the initialization of the Whirlpool hash implementation, the application executes its dynamic loading logic.\nThird, the glob pattern matches the attacker-supplied malicious shared object file, causing the runtime environment to load the untrusted binary into memory.\nFinally, the operating system executes the entry point or initialization routines contained within the malicious .so file, granting the attacker native code execution privileges within the security context of the host process.\nThe vulnerable component is the Whirlpool hash module loading logic in openssl_encrypt versions < 1.4.0.\nNo authentication or specific network exposure is inherently required for the exploitation mechanism itself, as the vulnerability is triggered locally upon module initialization, contingent on the prior placement of the malicious payload by an adversary with local write capabilities."
}