CVE-2026-81692 in openssl_encrypt
Summary
by MITRE • 08/27/2026
openssl_encrypt (pip: openssl-encrypt) versions 1.4.8 and earlier fail to validate the 36-bit STREAMINFO total_samples field of FLAC files before using it to size an allocation (np.random.randint(size=(total_samples, channels))). A ~50-byte crafted FLAC file declaring ~100 million samples causes a multi-gigabyte memory allocation, leading to out-of-memory denial of service during 'decrypt --stego-extract'. The issue is fixed in 1.4.9; both the 1.4.x and 1.5.x lines are affected.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability identified in the openssl-encrypt Python package, specifically within versions up to 1.4.8, represents a critical resource exhaustion flaw rooted in improper input validation of metadata fields from FLAC audio files. This issue manifests during the execution of the decrypt command with stego-extraction capabilities, where the application processes embedded data hidden within multimedia containers. The core technical failure lies in the handling of the STREAMINFO block, which is a mandatory header structure in the FLAC format that contains essential information about the audio stream, including sample rate, bit depth, and crucially, the total number of samples expected in the file. The library fails to perform adequate bounds checking on the total_samples field before utilizing this value to determine memory allocation parameters for subsequent processing operations.
From a technical perspective, the flaw allows an attacker to craft a malicious FLAC file with minimal size overhead while declaring an excessively large sample count. In documented instances, a payload of approximately fifty bytes can specify nearly one hundred million samples. When the openssl-encrypt library processes this metadata, it attempts to allocate memory for a NumPy array sized according to these inflated values using np.random.randint(size=(total_samples, channels)). Because the total_samples value is not validated against realistic limits or system constraints, the allocation request translates into several gigabytes of RAM consumption. This disproportionate resource usage occurs without any prior validation step that would typically reject such anomalous metadata as invalid or potentially malicious.
The operational impact of this vulnerability is a severe denial-of-service condition for systems relying on this library to process untrusted FLAC files. The sudden and massive memory allocation can quickly exhaust available system resources, leading to application crashes, server instability, or complete host-level resource starvation depending on the deployment context. Since the vulnerability triggers during decryption operations involving steganographic extraction, it poses a significant risk in environments where encrypted audio data is processed automatically, such as in content management systems, media processing pipelines, or security analysis tools that ingest user-uploaded files without rigorous pre-processing validation.
This issue aligns with CWE-400, which describes uncontrolled resource consumption, and specifically relates to the failure to validate input before allocating resources based on that input. It also reflects weaknesses associated with CWE-20, improper input validation, as the application accepts a value from an external source without verifying its reasonableness or consistency with other file attributes. In terms of attack vectors, this vulnerability can be exploited remotely if the service is accessible over a network and processes uploaded FLAC files, fitting into ATT&CK techniques related to resource hijacking for denial-of-service purposes.
The recommended mitigation involves upgrading the openssl-encrypt package to version 1.4.9 or later, where the developers have implemented proper validation logic for the STREAMINFO total_samples field. Until an upgrade is feasible, administrators should implement input filtering at the network perimeter or application layer to reject FLAC files with metadata indicating sample counts that exceed reasonable thresholds based on file size and duration expectations. Additionally, deploying resource limits such as memory quotas for processes handling multimedia content can help mitigate the impact of successful exploitation attempts by containing the damage within defined boundaries rather than allowing uncontrolled allocation across the entire system host.