CVE-2026-61721 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 native DLS loader assigns file-controlled wsmp.loop_start and wsmp.loop_length values to samples without calling fluid_sample_validate() or fluid_sample_sanitize_loop(). A crafted DLS file can place sample loop points beyond the sample buffer, causing out-of-bounds reads during audio rendering, undefined behavior, possible memory disclosure, and denial of service. Builds compiled with the CMake option enable-native-dls set to OFF do not expose the affected parser. This issue is fixed in version 2.5.6.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
FluidSynth serves as a prominent software synthesizer implementation adhering to SoundFont 2 specifications, widely utilized for generating high-quality audio from digital sound fonts. The vulnerability identified within versions ranging from 2.5.0 through 2.5.6 resides specifically in the native Digital Synthesis Library or DLS loader component. This module is responsible for parsing and loading instrument definitions that include sample data and loop parameters essential for continuous audio playback. During normal operation, the synthesizer relies on these samples to produce sustained tones by looping specific segments of audio data when a note is held down. The core technical flaw stems from an insufficient validation mechanism within this loader, which fails to rigorously check the integrity of loop point coordinates before they are applied to sample structures.
The specific deficiency involves the handling of wsmp.loop_start and wsmp.loop_length values extracted directly from file-controlled metadata in DLS files. In a secure implementation, these values must be validated against the actual size of the associated audio buffer to ensure that any requested loops remain entirely within the bounds of allocated memory. However, in the affected versions, the loader assigns these file-provided coordinates without invoking critical validation functions such as fluid_sample_validate or fluid_sample_sanitize_loop. This omission allows a maliciously crafted DLS file to specify loop start points and lengths that extend beyond the physical end of the sample buffer. Consequently, when the audio engine attempts to render sound using these corrupted parameters, it triggers out-of-bounds reads during the playback process.
The operational impact of this memory safety violation is severe and multifaceted. The immediate technical consequence is undefined behavior within the synthesizer's rendering pipeline, which typically manifests as a denial of service due to application crashes or segmentation faults when accessing invalid memory addresses. Beyond stability issues, out-of-bounds reads pose significant security risks related to information disclosure. Depending on the underlying operating system and memory layout, reading beyond the buffer boundary may expose adjacent memory contents that could contain sensitive data from other processes or internal state variables of the synthesizer itself. This aligns with CWE-125, Out-of-bounds Read, as well as CWE-787, Out-of-bounds Write if subsequent processing leads to corruption, though the primary vector here is read-based exploitation leading to potential memory leakage and service disruption.
From a threat modeling perspective utilizing the MITRE ATT&CK framework, this vulnerability facilitates reconnaissance or initial access scenarios where an attacker could leverage crafted audio files to crash target systems running FluidSynth for denial of service purposes, or potentially extract sensitive information through side-channel effects if combined with other vulnerabilities. The risk is further contextualized by CWE-20, Improper Input Validation, as the root cause lies in the failure to sanitize and validate external input data before use. It is important to note that this vulnerability is specific to builds compiled with the CMake option enable-native-dls set to OFF being safe from exposure; only configurations enabling native DLS support are susceptible to this flaw because they include the vulnerable parser logic.
To mitigate these risks, organizations and developers utilizing FluidSynth must ensure an immediate upgrade to version 2.5.6 or later, where the validation functions have been properly integrated into the loading process to enforce boundary checks on loop parameters. For environments that cannot immediately update due to dependency constraints, disabling native DLS support during compilation provides a viable workaround by removing the affected code path entirely. Additionally, input sanitization strategies should be applied at any layer preceding FluidSynth if it is used in public-facing applications accepting user-uploaded sound fonts, ensuring that only well-formed and validated audio assets are processed by the synthesizer engine to prevent exploitation of this memory safety issue.