CVE-2026-61720 in FluidSynth
Summary
by MITRE • 09/18/2026
FluidSynth is a software synthesizer based on the SoundFont 2 specifications. From 2.5.0 until 2.5.6, the SF2 parser computes the DMOD modulator count as chunk.size / SF_MOD_SIZE - 1 without rejecting chunks smaller than one record. A crafted SF2 file containing a zero-sized DMOD chunk makes the unsigned subtraction wrap to UINT_MAX, and the parser then attempts billions of SFMod allocations. This exhausts process memory and causes denial of service. No workaround is available. This issue is fixed in version 2.5.6.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified within FluidSynth versions ranging from 2.5.0 to 2.5.6 stems from a critical arithmetic error during the parsing of SoundFont 2 files, specifically concerning the handling of DMOD chunks which define modulation envelopes. The core technical flaw lies in the calculation used to determine the number of modulators present within a chunk. The software computes this count by dividing the total chunk size by the standard size of an SFMod record and then subtracting one from the result. This logic assumes that any valid chunk must contain at least one complete modulation record, thereby ensuring the divisor operation yields a value greater than zero before subtraction occurs. However, the parser fails to validate whether the incoming chunk data meets this minimum structural requirement prior to performing the arithmetic operation.
When an attacker crafts a malicious SF2 file containing a DMOD chunk with a size of zero or insufficient bytes to constitute even a single modulation record, the division operation yields either zero or a negligible integer depending on implementation specifics, but the subsequent subtraction of one from this result triggers an unsigned integer underflow. In C and similar low-level languages, subtracting one from zero results in wrap-around behavior, producing UINT_MAX, which is approximately four billion for 32-bit systems. This massive value represents the number of SFMod structures that the parser subsequently attempts to allocate dynamically in memory. The allocation loop proceeds without bounds checking against realistic limits or available system resources, leading to an immediate and severe exhaustion of process memory as the application tries to reserve space for billions of objects.
The operational impact of this vulnerability is a straightforward denial of service condition affecting both local users and potentially remote services if FluidSynth is integrated into network-facing audio processing pipelines such as MIDI servers or web-based synthesizers. The rapid consumption of available RAM causes the process to crash, terminate unexpectedly, or become unresponsive due to memory allocation failures. This disrupts any ongoing audio synthesis tasks and can destabilize host systems depending on their resource management policies. Because this is a heap exhaustion scenario triggered by malformed input data rather than code execution, it does not typically lead to arbitrary code execution but remains a significant availability risk for applications relying on FluidSynth for real-time audio generation.
From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound and CWE-400 Uncontrolled Resource Consumption within the Common Weakness Enumeration framework. In terms of adversary tactics, it corresponds to ATT&CK technique T1496 Resource Hijacking where resources are consumed to degrade service availability rather than for cryptomining or other malicious payloads. The root cause is a lack of input validation regarding chunk sizes before arithmetic operations that depend on those values being within expected bounds. Mitigation strategies primarily involve upgrading FluidSynth to version 2.5.6 or later, where the developers have implemented proper checks to reject chunks smaller than one record size before performing the modulator count calculation. Until such an update is applied in environments using vulnerable versions, input sanitization at a higher-level application wrapper may provide limited protection by filtering out malformed SF2 files with suspiciously small chunk sizes prior to parsing.