CVE-2026-32741: libheif has a heap buffer overflow in decode_mask_image()
libheif is a HEIF and AVIF file format decoder and encoder. Versions 1.21.2 and below contain a heap buffer overflow in MaskImageCodec::decode_mask_image(). When decoding a HEIF file containing a mask image (mski), the function copies the full iloc extent data into a pixel buffer using memcpy(dst, data.data(), data.size()). The copy length data.size() is determined by the iloc extent in the file (attacker-controlled), while the destination buffer is sized based on the declared image dimensions. Because no upper-bound check exists on the data length, a crafted file whose iloc extent exceeds the pixel buffer allocation overflows the heap. The vulnerable single-memcpy branch is reached when the mskC property specifies bits_per_pixel = 8 and the ispe property declares an even width ≥ 64 (so that stride == width), with no changes to default security limits or external codec plugins required. This issue has been fixed in version 1.22.0.
Security readout for executives and security teams
Plain-English summary
CVE-2026-32741 is a high-severity memory corruption flaw in libheif, a library used to read HEIF and AVIF images. A malicious image can overflow heap memory during mask image decoding. Exploitation requires a user or service to process the file, but could affect availability and possibly corrupt output or process state.
Executive priority
Treat this as a near-term patching item for any environment that handles user-supplied images. It is not currently documented as actively exploited in the provided sources, but the affected library is common in media workflows and the bug can be triggered by crafted image content.
Technical view
libheif versions before 1.22.0 overflow a heap buffer in MaskImageCodec::decode_mask_image(). The copy size comes from attacker-controlled iloc extent data, while the destination buffer is sized from declared image dimensions. The vulnerable path involves HEIF mask images using mskC bits_per_pixel=8 and specific ispe width conditions.
Likely exposure
Systems are exposed if they process untrusted HEIF or AVIF files with libheif below 1.22.0, including upload pipelines, thumbnailers, converters, media indexing, and applications bundling the library. Exposure may also come through operating-system packages or container images that include vulnerable libheif builds.
Exploitation context
The source bundle does not show CISA KEV listing or confirmed active exploitation. The CVSS vector indicates network-deliverable content with required user interaction. Practical risk is highest where automated services accept or transform user-supplied images.
Researcher notes
The root issue is an unchecked memcpy from iloc extent data into a pixel buffer sized from image dimensions. Sources identify CWE-120 and CWE-122, CVSS 7.1, affected versions below 1.22.0, and a fixed upstream release. Avoid assuming downstream package status without vendor confirmation.
Mitigation direction
Upgrade libheif to version 1.22.0 or a vendor-fixed package.
Inventory applications, containers, and image pipelines that include libheif.
Prioritize systems processing untrusted HEIF or AVIF files.
Temporarily restrict HEIF/AVIF processing where patching is delayed.
Check operating-system vendor advisories for backported fixes.
Validation and detection
Confirm deployed libheif versions are 1.22.0 or vendor-patched.
Review SBOMs and container images for vulnerable libheif packages.
Trace upload, thumbnailing, indexing, and conversion paths for HEIF/AVIF handling.
Verify package status against Red Hat or relevant vendor advisories.
Confirm mitigations cover both bundled and system-provided libheif copies.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-120: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-120 · source CWE mapping
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Heap-based Buffer Overflow represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.