CVE-2026-84449

What it actually does

An integer overflow in libheif’s RGB-to-YCbCr conversion (Op_RGB24_32_to_YCbCr::convert_colorspace) wraps an image-plane stride for extremely large RGB images. The conversion loop then computes an invalid pointer and reads past the allocated interleaved plane during heif_context_encode_image(), crashing the encoder. Impact is limited to an out-of-bounds read that terminates the process; confidentiality and integrity are not affected.

Why it matters to the business

Image and video pipelines that encode HEIF/AVIF with libheif can be knocked offline if they accept or generate extremely large RGB frames, interrupting transcoding, thumbnails, or upload workflows. The issue is not listed in CISA KEV, is not associated with ransomware, and has no known exploit in the wild as of 16 days after publication. Combined with a low CVSS (3.7) and high attack complexity, operational urgency is moderate: treat as a stability and availability risk for encoding services rather than an imminent breach scenario.

How an attack unfolds

An unauthenticated attacker who can cause a vulnerable libheif build (before 1.19.6) to encode a crafted, extremely large RGB image—typically via an application or service that calls heif_image_create(), heif_image_add_plane(), and heif_context_encode_image()—triggers a wrapped stride. The encoder’s color-conversion path then reads out of bounds and aborts. No remote code execution or data theft is described; success is a crash of the encoding process (denial of service). High attack complexity (very large dimensions and a specific conversion path) and the absence of public exploit code or named threat-actor use make opportunistic exploitation unlikely in the near term.

How to fix it

Upgrade libheif to 1.19.6 or later, which corrects stride handling in Op_RGB24_32_to_YCbCr::convert_colorspace. Rebuild and redeploy any statically linked binaries, containers, or language bindings (e.g., application bundles, FFmpeg/GStreamer plugins, or language wrappers) that ship their own copy of libheif. If an immediate upgrade is not possible, reject or downscale RGB images whose dimensions could overflow stride calculations before they reach heif_image_create()/heif_image_add_plane(), and isolate encoding workers so a crash does not take down the whole service. Confirm transitive dependencies (package managers, OS images, mobile SDKs) pull 1.19.6 or newer.

How to confirm the fix worked

Inventory hosts and artifacts for libheif older than 1.19.6 (package version, shared-library SONAME, or strings in binaries). After upgrade, confirm the running library reports 1.19.6+ and that encoding of large RGB inputs no longer crashes the worker. Review CI/SBOM and container base images so downstream rebuilds actually pick up the fixed library rather than a cached vulnerable copy.

Typical attack path

1. Identify a network- or locally reachable service that encodes RGB data to HEIF/AVIF using libheif prior to 1.19.6.
2. Cause that service to construct or ingest an extremely large RGB image so that plane strides overflow the integer width used in convert_colorspace.
3. Trigger encoding (heif_context_encode_image) so RGB-to-YCbCr conversion runs on the overflowed stride.
4. The conversion loop reads beyond the interleaved plane and the encoder process crashes, denying encoding capacity until restart.

How to detect it

This flaw crashes the encoder; it does not leave a distinct implant. Hunt for abnormal encoder-process deaths and core dumps around RGB-to-YCbCr conversion rather than a unique malware signature. Review application and systemd/journal logs for libheif or heif_context_encode_image failures coinciding with very large image jobs; inspect crash stacks for rgb2yuv.cc or Op_RGB24_32_to_YCbCr. Check package and container inventories for libheif < 1.19.6 as exposure, not proof of compromise. There are no named threat actors or KEV-linked campaigns to pivot from.

• libheif/color-conversion/rgb2yuv.cc
• Op_RGB24_32_to_YCbCr::convert_colorspace
• heif_context_encode_image
• libheif.so.* versions prior to 1.19.6
• process crash/segfault in libheif during RGB-to-YCbCr encode

What your security team should do

• Patch libheif to 1.19.6 or later everywhere it is linked, including static and vendored copies.
• Prioritize internet-facing or multi-tenant encoding/transcoding services; crash isolation (separate workers, rate limits, image-size caps) reduces residual DoS risk.
• Enforce maximum width/height and memory budgets on heif_image_create / add_plane callers until all binaries are upgraded.
• Track this as an availability issue, not KEV/ransomware; no evidence of in-the-wild exploitation as of 16 days post-publication.
• Update SBOMs and dependency scanners so future rebuilds cannot silently reintroduce pre-1.19.6 libheif.