CVE-2026-32739

What it actually does

CVE-2026-32739 is a denial-of-service flaw in libheif versions 1.21.2 and earlier. A specially crafted, very small HEIF sequence file can trigger an infinite loop in Box_stts::get_sample_duration() during file parsing. Because parsing occurs when the file is opened, before image rendering or user interaction, any application, thumbnailer, converter, media pipeline, or upload-processing service that uses vulnerable libheif code may become stuck consuming a full CPU core indefinitely. The process does not necessarily crash or emit an error, so crash-only monitoring may not detect the failure.

Why it matters to the business

Successful exploitation can degrade or interrupt services that process HEIF or AVIF files, including image upload workflows, media conversion services, content moderation pipelines, desktop previewers, and document/image management systems. Repeated submissions of crafted files could exhaust CPU capacity, slow queues, increase infrastructure costs, or make image-related functionality unavailable. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low, flat EPSS score, but exploitation is low-complexity wherever untrusted HEIF/AVIF files are parsed by vulnerable software.

How an attack unfolds

An attacker creates or obtains a malformed HEIF sequence file that abuses the sample timing metadata parsed by libheif. The attacker then delivers the file to a vulnerable target, such as by uploading it to an application that accepts images, attaching it to a workflow that generates thumbnails, placing it where an indexer or previewer will scan it, or convincing a user to open it. When the vulnerable application opens the file, libheif parses the container metadata and enters an infinite loop in Box_stts::get_sample_duration(). The affected process remains alive but makes no progress, consuming CPU indefinitely. In service environments, attackers can repeat this with multiple files or requests to tie up workers and reduce availability.

How to fix it

Upgrade libheif to version 1.22.0 or later wherever it is installed directly or bundled into applications, containers, desktop packages, image processing services, or media toolchains. Rebuild or redeploy dependent software that statically links or vendors libheif. Until upgrades are complete, restrict or disable HEIF/AVIF ingestion from untrusted sources, add file-processing timeouts, isolate image parsing in resource-limited worker processes, enforce CPU and wall-clock limits for thumbnailing/conversion jobs, and rate-limit uploads or processing queues. For server workloads, run media parsers in sandboxes or containers with constrained CPU quotas so one malformed file cannot monopolize host resources.

How to confirm the fix worked

Confirm that installed runtime and bundled copies of libheif report version 1.22.0 or later. Validate both system packages and embedded application dependencies because applications may ship their own libheif library. Where feasible, run package-manager inventory, container image scans, software composition analysis, and binary/library searches for libheif. Test affected workflows by processing representative HEIF/AVIF files and verifying jobs complete within expected timeouts. Confirm that media-processing workers have CPU and wall-clock limits, that failed or long-running jobs are terminated, and that monitoring alerts on sustained CPU saturation even when no crash occurs.

Typical attack path

1. Identify an application, service, desktop component, or media pipeline that accepts or scans HEIF/AVIF files and uses libheif 1.21.2 or earlier.
2. Prepare a crafted HEIF sequence file that triggers the infinite loop during metadata parsing.
3. Deliver the file through an upload form, API, email attachment, shared folder, content ingestion queue, or user-assisted open action.
4. Wait for the target application or background processor to open or inspect the file.
5. The vulnerable libheif parser enters an infinite loop, causing the process to consume CPU without crashing.
6. Repeat delivery or trigger concurrent processing to exhaust additional CPU cores or worker capacity.

How to detect it

Look for evidence of exploitation by correlating file-ingestion events with abnormal CPU behavior. Relevant sources include web upload logs, API gateway logs, object storage access logs, email attachment processing logs, EDR process telemetry, container metrics, job queue records, thumbnail/conversion service logs, and host performance monitoring. Suspicious patterns include HEIF/AVIF file opens immediately followed by a process consuming near-100% of one CPU core for an unusually long period, image-processing jobs that never complete, worker processes that remain alive without logging errors, and repeated uploads of small HEIF files shortly before CPU saturation. Since the vulnerability causes an infinite loop rather than a crash, crash dumps and error logs may be absent. For confirmation, capture process stack traces or profiler samples from stuck processes and look for repeated execution in libheif HEIF sequence parsing, especially Box_stts::get_sample_duration(). Preserve the triggering file, request metadata, source IP or account context where applicable, and affected process telemetry for investigation.

• Box_stts::get_sample_duration
• libheif
• heif-info
• heif-convert
• heif-thumbnailer
• image/heif
• image/avif
• .heif
• .heic
• .avif
• ftypheic
• ftypheix
• ftyphevc
• ftypmif1
• ftypmsf1

What your security team should do

• Prioritize upgrade of internet-facing upload services, media conversion workers, thumbnail generators, and any automated pipeline that parses untrusted HEIF or AVIF files.
• Inventory all uses of libheif, including operating system packages, containers, desktop applications, statically linked binaries, and vendor-bundled libraries.
• Upgrade to libheif 1.22.0 or later and redeploy dependent applications that include or link against the vulnerable library.
• Implement defense-in-depth controls for media parsing: sandboxing, CPU quotas, job timeouts, request rate limits, and worker recycling.
• Add monitoring for sustained high CPU in image-processing processes that does not correspond to normal workload volume.
• Temporarily block or quarantine HEIF/AVIF uploads from untrusted users if immediate patching is not possible.
• Preserve suspicious HEIF/AVIF files associated with CPU spikes for forensic analysis and vendor reproduction.
• Because exploitation does not produce a crash, do not rely solely on crash reports; use performance telemetry, process stack sampling, and file-ingestion logs.