CVE-2026-3950

What it actually does

CVE-2026-3950 is an out-of-bounds read in strukturag libheif up to version 1.21.2, specifically in Track::load in libheif/sequences/track.cc while handling stsz/stts sample size and timing data. A crafted HEIF/HEIC sequence file with malformed track metadata can cause the library to read outside expected memory bounds during parsing. The most likely impact is a crash or abnormal termination of the application using libheif, resulting in limited availability impact; the provided CVSS vector does not indicate confidentiality or integrity impact.

Why it matters to the business

Applications, desktop tools, backend media processors, thumbnailers, document pipelines, and security scanners that rely on vulnerable libheif builds may be crashed by specially crafted local media files. This can interrupt image-processing workflows, batch jobs, user-facing upload processing, or endpoint applications. The current exploitation likelihood appears low based on EPSS of 0.00117 with no 30-day upward trend, and it is not listed in CISA KEV or associated with ransomware campaigns; however, public exploit information may lower the effort needed for targeted denial-of-service testing.

How an attack unfolds

An attacker first needs a way to execute or submit a crafted HEIF/HEIC sequence file to software that uses vulnerable libheif versions up to 1.21.2. The attacker constructs a file with inconsistent or malformed stsz/stts track metadata so that, when Track::load parses sample size or timing tables, the code reads past the intended memory boundary. Once the vulnerable parser processes the file, the hosting application may crash, terminate the media-processing task, or generate a core dump. In practical terms, exploitation is most relevant where untrusted local files are automatically indexed, thumbnailed, converted, scanned, or otherwise parsed by libheif-linked software.

How to fix it

Upgrade libheif to an official vendor, distribution, or upstream release that contains an approved fix once available. Because the available patch is described as unofficial and not yet approved, prefer trusted distribution backports or official upstream releases over ad hoc patching in production. If an immediate official fix is unavailable, mitigate by restricting processing of untrusted HEIF/HEIC sequence files, disabling HEIF sequence handling where feasible, sandboxing media parsers, running thumbnailers/converters with least privilege, enforcing resource limits, and isolating media-processing workers. Rebuild or redeploy all statically linked applications and containers that bundle libheif, because upgrading the system package alone may not remediate embedded copies.

How to confirm the fix worked

Inventory libheif installations and embedded copies across hosts, containers, application bundles, and build artifacts. Confirm versions with package managers, software composition analysis, `pkg-config --modversion libheif`, application dependency manifests, or tool version output such as `heif-info --version` where available. Treat libheif versions up to and including 1.21.2 as affected unless a trusted distribution backport explicitly documents the fix. After remediation, run regression tests against representative HEIF/HEIC files and, where available, a safe proof-of-concept or vendor test case to confirm the parser no longer crashes. Verify that applications dynamically linked to libheif load the patched library at runtime and that statically linked applications were rebuilt.

Typical attack path

1. Identify an application, service, or local workflow that uses strukturag libheif version 1.21.2 or earlier.
2. Create or obtain a malformed HEIF/HEIC sequence file targeting stsz/stts parsing in Track::load.
3. Place, open, upload, or otherwise cause the crafted file to be processed by the vulnerable application in a local context.
4. The application invokes libheif to parse the media sequence metadata.
5. libheif performs an out-of-bounds read while loading track sample size or timing data.
6. The affected process crashes or the media-processing operation fails, causing a denial-of-service condition for that process or workflow.

How to detect it

To determine whether this was already exploited, focus on evidence of abnormal crashes in applications that parse HEIF/HEIC files. Review system logs, application logs, crash reporters, endpoint detection telemetry, core dump metadata, and media-processing job failures for crashes involving libheif, Track::load, sequence track parsing, or stsz/stts metadata. On Linux, examine syslog, journald, coredumpctl, kernel Oops/segfault messages, and application supervisor logs for SIGSEGV, SIGABRT, or similar faults in processes linked to libheif. On Windows or macOS, review application crash reports and endpoint telemetry for faulting modules or stack traces referencing libheif. Correlate crashes with recently processed HEIF/HEIC files and preserve suspicious samples for offline analysis. Indicators are primarily behavioral because this vulnerability does not create a durable persistence artifact and is expected to manifest as denial of service rather than system compromise.

• Track::load
• libheif/sequences/track.cc
• stsz
• stts
• libheif
• heif-info
• heif-convert
• heif-thumbnailer
• SIGSEGV
• SIGABRT
• segmentation fault
• AddressSanitizer: heap-buffer-overflow
• AddressSanitizer: global-buffer-overflow
• AddressSanitizer: SEGV
• out-of-bounds read
• .heif
• .heic

What your security team should do

• Prioritize inventory of systems and applications that parse HEIF/HEIC media, including image converters, thumbnail generators, content ingestion services, desktop viewers, and security scanning pipelines.
• Patch libheif through trusted vendor or distribution channels as soon as an official fixed build is available; track backported fixes carefully because fixed package versions may differ by distribution.
• Until patched, restrict or sandbox processing of untrusted HEIF/HEIC sequence files and consider temporarily blocking these files in high-risk automated ingestion paths.
• Search crash telemetry, system logs, and core dumps for libheif-related failures involving Track::load, stsz, or stts parsing.
• Rebuild containers and statically linked binaries that include libheif rather than relying only on base operating system package updates.
• Add monitoring for repeated media-parser crashes, especially when correlated with newly introduced HEIF/HEIC files from untrusted sources.