CVE-2026-111157 in SoX
Summary
by MITRE • 10/15/2026
SoX through 14.4.2 contains a heap out-of-bounds write vulnerability in lsx_ms_adpcm_block_expand_i() in src/adpcm.c, triggered by an odd samplesPerBlock value in the WAV fmt chunk. Attackers can supply a crafted MS ADPCM WAV file to sox or any libsox consumer to write a partially controlled 16-bit sample past the heap buffer allocated by wav_ms_adpcm_fmt().
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in SoX, specifically within versions up to and including 14.4.2, represents a critical memory safety issue classified as a Heap Out-of-Bounds Write under the Common Weakness Enumeration (CWE-787). This flaw resides in the source file src/adpcm.c, particularly within the function lsx_ms_adpcm_block_expand_i(), which is responsible for decoding MS ADPCM audio data. The root cause of this vulnerability stems from an insufficient validation mechanism when processing the format chunk of a WAV file. Specifically, the application fails to adequately verify that the samplesPerBlock field aligns with expected boundaries before proceeding with memory allocation and subsequent write operations. This lack of rigorous input sanitization allows attackers to craft malicious MS ADPCM WAV files where the samplesPerBlock value is set to an odd number or otherwise malformed, triggering a logic error during the expansion process.
From a technical perspective, the vulnerability manifests when libsox attempts to allocate memory for decoding audio blocks based on the metadata provided in the file header. The function wav_ms_adpcm_fmt() allocates a heap buffer sized according to the samplesPerBlock value. However, due to the arithmetic miscalculation or lack of boundary checks within lsx_ms_adpcm_block_expand_i(), the subsequent write operation exceeds the allocated buffer size by writing partially controlled 16-bit sample data beyond its limits. This out-of-bounds write corrupts adjacent heap memory structures, which can lead to arbitrary code execution if an attacker carefully crafts the overflow payload to overwrite function pointers or object vtables. The ability to control at least part of the written data significantly increases the exploitability of this flaw compared to purely random corruption scenarios.
The operational impact of this vulnerability is severe for any application that integrates libsox as a library for audio processing, including media players, streaming services, and automated audio analysis tools. An attacker can distribute a specially crafted WAV file via email attachments, web uploads, or network streams. When the victim's software processes this malicious file, it triggers the heap overflow, potentially leading to remote code execution with the privileges of the user running the application. This aligns with MITRE ATT&CK technique T1203, which covers Exploitation for Client Execution, as well as techniques related to memory corruption such as Heap Spraying or Overflows under T1498 and T1564 respectively. The vulnerability affects not just SoX itself but any downstream consumer of libsox that does not implement additional input validation layers.
Mitigation strategies should focus on both immediate patching and long-term defensive coding practices. Users must upgrade to a version of SoX later than 14.4.2, where the developers have presumably implemented stricter checks for samplesPerBlock parity and buffer size calculations. For organizations relying on libsox in custom applications, it is imperative to implement input validation at the point of file ingestion, ensuring that all header fields conform to expected ranges before passing them to decoding functions. Additionally, employing compiler-based protections such as Stack Canaries, Address Space Layout Randomization (ASLR), and Data Execution Prevention (DEP) can mitigate the risk of successful exploitation by making memory corruption attacks more difficult to execute reliably. Regular security audits focusing on C/C++ memory management practices are recommended to prevent similar heap overflow vulnerabilities in audio processing libraries.