CVE-2026-88372

What it actually does

libsndfile 1.2.2 has an integer overflow in mat4_read_header() while parsing MATLAB v4 (MAT4) file headers. Attacker-controlled header fields can wrap size, dimension, or offset arithmetic, producing undersized allocations or invalid copy lengths and resulting in memory corruption. The published CVSS profile (C:N/I:N/A:H) indicates the practical outcome is process crash or instability (denial of service), not disclosed data or reliable integrity compromise.

Why it matters to the business

Any product that automatically parses untrusted audio or scientific files with libsndfile can be knocked offline by a single crafted MAT4 file, interrupting media ingest, transcoding, call-recording, research-data pipelines, and upload APIs. The issue is 13 days old, is not on the CISA KEV list, has no reported ransomware use, and currently has no known public exploit, but unpatched network-facing parsers remain a straightforward availability risk until upgraded or isolated.

How an attack unfolds

An unauthenticated attacker prepares a MATLAB v4 file whose header values cause integer overflow inside mat4_read_header(), then submits it over the application's normal file-ingest path (upload API, mail gateway, object storage, or streamed media). If the service uses libsndfile 1.2.2 and parses the file without extra user action, the overflowed lengths drive invalid memory operations and the worker or host process aborts. The CVSS vector (network, low complexity, no privileges, no user interaction) matches auto-parsing services rather than a click-to-open desktop-only path. Exploit maturity is none; no named threat actors or in-the-wild campaigns are associated with this CVE.

How to fix it

Upgrade libsndfile off 1.2.2 to a vendor-patched release that corrects integer overflow in mat4_read_header(), then rebuild and redeploy all statically linked binaries, containers, and language bindings. No fixed version is published in this record yet, so track upstream libsndfile advisories and apply the first patched build immediately. Until then: reject or quarantine MATLAB v4 / .mat content at the edge; limit accepted formats so the MAT4 parser is not exercised on untrusted input; run parsing in a sandboxed, memory-capped worker so a crash cannot take down the parent service; and inventory every package, image, and third-party tool that vendors libsndfile 1.2.2.

How to confirm the fix worked

Inventory libsndfile via package managers, container SBOMs, ldd/otool, and strings on binaries; treat 1.2.2 (and unknown static copies) as exposed until a patched version is confirmed. After upgrade, parse known-good MATLAB v4 and other supported formats in a non-production environment to confirm functional regression, and verify that malformed MAT4 headers no longer terminate the process. Confirm edge controls still block untrusted .mat/MAT4 ingest where patching is delayed. Do not validate using production parsers or share crash samples on unisolated hosts.

Typical attack path

1. Locate a reachable application or service that uses libsndfile 1.2.2 (dynamic or static) to parse uploaded or fetched audio/scientific files.
2. Create a MATLAB v4 (MAT4) file with header fields that overflow integer arithmetic in mat4_read_header().
3. Deliver the file through a normal ingest channel (HTTP upload, API, email, shared storage, or media pipeline).
4. The service parses the file automatically with libsndfile, without authentication or additional user interaction.
5. Overflowed sizes cause invalid memory operations and the parsing process crashes or restarts (denial of service).
6. Repeat submission if needed to keep the affected worker or service unavailable.

How to detect it

No in-the-wild exploitation, ransomware use, or named threat actors are reported, so hunt for crash-driven denial of service rather than a known implant. Review application, systemd/journald, container, and orchestrator logs for unexpected exits, SIGSEGV/SIGABRT, or restart loops in services that call libsndfile. Inspect core dumps and stack traces for frames in mat4_read_header, mat4.c, or libsndfile during parse of .mat or MAT4 content. Correlate crash timestamps with upload, object-storage, mail-gateway, and WAF logs showing inbound .mat files or scientific/audio uploads to the same endpoint. On hosts, look for recently written core files from media or ingest workers. Detections will be behavioral (crash plus MAT4 ingest) because there are no public exploit signatures.

• mat4_read_header
• mat4.c
• libsndfile 1.2.2
• libsndfile.so
• sf_open
• \.mat
• MATLAB v4
• SIGSEGV
• SIGABRT

What your security team should do

• Inventory every dynamic and static use of libsndfile 1.2.2 (applications, containers, language bindings, and media appliances).
• Patch or rebuild internet-facing ingest, transcode, and upload services first; CVSS 7.5 network DoS with no user interaction warrants high urgency even without KEV.
• Until a fixed release exists, block or quarantine MATLAB v4 / .mat files at WAF, mail, and upload gateways.
• Isolate file parsers in crash-contained, resource-limited workers so a single sample cannot outage the parent service.
• Hunt for recent crashes in processes linked to libsndfile on MAT/audio parse paths (see detection_guidance).
• Watch upstream libsndfile security notes and deploy the first patched version across all copies, including transitive dependencies.