Skip to main content
Vulnerability Database/CVE-2026-61720

CVE-2026-61720: FluidSynth SF2 Parser DoS Vulnerability

CVE-2026-61720 is a denial of service vulnerability in FluidSynth software synthesizer caused by improper SF2 file parsing. Crafted files can exhaust process memory leading to DoS. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2026-61720 Overview

FluidSynth is a software synthesizer that implements the SoundFont 2 (SF2) specification. Versions from 2.5.0 through 2.5.5 contain an integer underflow [CWE-191] in the SF2 file parser. The parser computes the DMOD modulator count as chunk.size / SF_MOD_SIZE - 1 without validating that the chunk contains at least one record. A crafted SF2 file with a zero-sized DMOD chunk causes the unsigned subtraction to wrap to UINT_MAX. FluidSynth then attempts billions of SFMod allocations, exhausting process memory and causing denial of service. The issue is fixed in FluidSynth 2.5.6.

Critical Impact

A local attacker who convinces a user or service to load a malicious SF2 SoundFont file can exhaust process memory and terminate the FluidSynth-based application.

Affected Products

  • FluidSynth 2.5.0 through 2.5.5
  • Applications and services that embed the FluidSynth SF2 loader
  • Linux distributions and audio toolchains packaging vulnerable FluidSynth builds

Discovery Timeline

  • 2026-09-18 - CVE-2026-61720 published to NVD
  • 2026-09-24 - Last updated in NVD database
  • FluidSynth 2.5.6 - Upstream patch released via commit 096e1ff0d09ddcac83d94923440706f76f94bc44 and advisory GHSA-rmc4-c8hw-455w

Technical Details for CVE-2026-61720

Vulnerability Analysis

The defect resides in the SF2 loader at src/sfloader/fluid_sffile.c. When parsing the DMOD (default modulators) chunk, the loader validates that chunk.size is a multiple of SF_MOD_SIZE but does not reject a chunk size of zero. It then computes count = chunk.size / SF_MOD_SIZE - 1 to account for the terminal record. Because count is an unsigned int, subtracting one from zero produces UINT_MAX (4,294,967,295). The loader treats this value as a legitimate modulator count and enters an allocation loop that requests billions of SFMod structures. Memory pressure escalates until the allocator fails or the operating system terminates the process.

Root Cause

The root cause is missing lower-bound validation on an untrusted length field combined with unsigned arithmetic. The check chunk.size % SF_MOD_SIZE != 0 filters non-aligned sizes but permits zero. The subsequent subtraction underflows silently rather than producing a signed negative value that could be detected.

Attack Vector

Exploitation requires local delivery of a crafted SF2 file to a FluidSynth-based process. Typical vectors include opening a malicious SoundFont in a MIDI editor, loading an untrusted SF2 in a game or audio engine, or feeding a crafted file to a server-side rendering pipeline. No authentication or user interaction beyond file selection is required for the parser to reach the vulnerable code path.

c
              */
             SFMod *dmod;
             unsigned int count;
-            if (chunk.size % SF_MOD_SIZE != 0 || size == 0)
+            if (chunk.size < SF_MOD_SIZE || chunk.size % SF_MOD_SIZE != 0 || size == 0)
             {
                 FLUID_LOG(FLUID_ERR, "DMOD chunk has invalid size (%d bytes)", chunk.size);
                 return FALSE;
             }

-
             // read the modulators sequentially
             count = chunk.size / SF_MOD_SIZE - 1; // minus the terminal record
             FLUID_LOG(FLUID_DBG, "Detected the DMOD chunk with %d modulators", count);

Source: FluidSynth commit 096e1ff. The patch adds a chunk.size < SF_MOD_SIZE guard that rejects DMOD chunks too small to hold even one record, preventing the underflow.

Detection Methods for CVE-2026-61720

Indicators of Compromise

  • SF2 files whose DMOD chunk header reports a size of 0 or any value smaller than SF_MOD_SIZE (10 bytes).
  • FluidSynth or host process crashes accompanied by out-of-memory (OOM) killer events in kernel logs.
  • Rapid, unbounded resident set size (RSS) growth in a fluidsynth process shortly after loading a SoundFont.

Detection Strategies

  • Statically scan SF2 files in content pipelines and reject chunks with a DMOD size less than SF_MOD_SIZE or not aligned to SF_MOD_SIZE.
  • Monitor process telemetry for FluidSynth binaries exhibiting abnormal memory allocation patterns immediately after file open events.
  • Correlate audio-application crashes with dmesg entries containing Out of memory: Killed process targeting fluidsynth or embedding applications.

Monitoring Recommendations

  • Track installed FluidSynth versions across endpoints and flag hosts running any release from 2.5.0 through 2.5.5.
  • Alert on Linux oom_reaper and oom-kill audit events involving audio subsystem processes.
  • Log SoundFont file loads in DAWs, MIDI renderers, and game engines that link against FluidSynth for later review.

How to Mitigate CVE-2026-61720

Immediate Actions Required

  • Upgrade FluidSynth to version 2.5.6 or later on all affected systems.
  • Rebuild and redistribute any application that statically links FluidSynth against the patched source tree.
  • Restrict SF2 SoundFont loading to files from trusted sources until patched binaries are deployed.

Patch Information

The fix is available in FluidSynth release v2.5.6 and is described in GitHub Security Advisory GHSA-rmc4-c8hw-455w. The upstream commit 096e1ff0d09ddcac83d94923440706f76f94bc44 adds a minimum-size check to the DMOD chunk validator in src/sfloader/fluid_sffile.c.

Workarounds

  • No vendor-supplied workaround exists; upgrading to 2.5.6 is the only supported remediation.
  • Where immediate patching is not possible, pre-validate SF2 files with an out-of-process scanner that rejects zero-sized DMOD chunks before passing them to FluidSynth.
  • Run FluidSynth-based services under strict memory cgroup limits so an underflow-triggered allocation storm terminates only the sandboxed process.
bash
# Verify the installed FluidSynth version and update via distribution package manager
fluidsynth --version

# Debian/Ubuntu
sudo apt update && sudo apt install --only-upgrade fluidsynth libfluidsynth3

# Fedora/RHEL
sudo dnf upgrade fluidsynth fluidsynth-libs

# Apply a memory cap to a FluidSynth systemd service as a defense-in-depth measure
sudo systemctl set-property fluidsynth.service MemoryMax=512M

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.