☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]

CVE-2025-68431

CVE-2025-68431 Information Disclosure in Libheif
📅 PUBLISHED: 2025-12-29 19:09 UTC 🔄 UPDATED: 2026-09-23 20:26 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: CONFIRMED — 3+ independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.33%
👁️
0.33% probability
8.3× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
6.5
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2025-68431 is a heap buffer over-read vulnerability in the libheif library, affecting versions prior to 1.21.0. The flaw resides in the HeifPixelImage::overlay() function, which is invoked when processing crafted HEIF/AVIF images containing overlay image items (iovl boxes). An attacker can trigger a negative row length calculation due to unclipped overlay rectangle coordinates or invalid offsets. This negative value, when cast to size_t, underflows to a very large positive number, causing memcpy to read far beyond the bounds of the source plane, leading to a crash and potential information disclosure. The CVSS score is 6.5 (Medium), with a local attack vector and user interaction required. No public exploit code or proof-of-concept is currently available, and the EPSS score is 0.0%, indicating low exploitation likelihood at this time. The vendor has released a patch in version 1.21.0.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

This vulnerability affects the libheif library, which is a critical dependency for many image processing applications and libraries (e.g., ImageMagick, GIMP, FFmpeg, and various web browsers). Users and organizations should audit their software supply chain for any packages or applications that bundle or depend on libheif versions prior to 1.21.0. Immediate action should be taken to update to the patched version or apply the recommended workaround.

CVSS Breakdown & Threat Level

  • CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:H
  • Base Score: 6.5 (Medium)
  • Attack Vector (AV): Local (L) – The attacker must provide a malicious file to the victim.
  • Attack Complexity (AC): Low (L) – No special conditions required beyond opening the file.
  • Privileges Required (PR): None (N) – No authentication needed.
  • User Interaction (UI): Required (R) – The victim must open the crafted file.
  • Scope (S): Unchanged (U) – The vulnerability does not affect other components.
  • Confidentiality (C): High (H) – Potential for reading sensitive memory contents.
  • Integrity (I): None (N) – No data modification possible.
  • Availability (A): High (H) – Likely leads to a crash (denial of service).

Threat Level: Medium. While the impact on confidentiality and availability is high, the requirement for user interaction and local access reduces the overall risk. The lack of public exploits further lowers the immediate threat.

Deep Dive & Mechanics

The vulnerability is located in the HeifPixelImage::overlay() method within libheif. This function is responsible for compositing multiple image planes (e.g., from an overlay box) into a single output image. The overlay box (iovl) defines a list of image references and their respective offsets and sizes.

The root cause is a failure to properly validate and clamp the overlay rectangle coordinates. When a crafted HEIF file specifies an overlay rectangle with a negative width or height, or with offsets that cause the rectangle to extend beyond the source image boundaries, the function computes a row length that becomes negative. This negative value is then implicitly cast to size_t (an unsigned type), resulting in a very large positive integer. This integer is subsequently passed to memcpy as the number of bytes to copy, causing a heap buffer over-read from the source plane.

The vulnerable code path can be summarized as:

  1. Parse overlay box, extracting source image, offset (x, y), and size (width, height).
  2. Calculate row length: row_length = width * bytes_per_pixel.
  3. If width is negative or the offset causes the rectangle to extend beyond the source, row_length becomes negative.
  4. Cast row_length to size_t for memcpy, causing underflow to a huge value.
  5. memcpy reads far beyond the source plane buffer, leading to a crash or memory disclosure.

Vulnerable vs. Patched Code

Vulnerable Code (prior to 1.21.0):

// In HeifPixelImage::overlay()
int row_length = overlay_width * bytes_per_pixel;
// No validation of overlay_width or overlay coordinates
memcpy(target_row, source_row + offset, row_length); // row_length may be negative

Patched Code (1.21.0):

// In HeifPixelImage::overlay()
int row_length = overlay_width * bytes_per_pixel;
// Clamp overlay rectangle to source image bounds
if (overlay_x < 0) {
    overlay_width += overlay_x;
    overlay_x = 0;
}
if (overlay_y < 0) {
    // similar clamping for y
}
if (overlay_x + overlay_width > source_width) {
    overlay_width = source_width - overlay_x;
}
// Ensure row_length is non-negative
if (row_length < 0) {
    row_length = 0;
}
memcpy(target_row, source_row + offset, row_length);

The patch adds clamping logic to ensure the overlay rectangle stays within the source image boundaries and explicitly checks for negative row lengths, setting them to zero to prevent the underflow.

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

  • A vulnerable version of libheif (e.g., 1.18.0).
  • A tool to craft HEIF/AVIF files (e.g., heif-enc, exiftool, or a hex editor).
  • A target application that uses libheif to decode images (e.g., heif-convert, gimp, ffmpeg).

Exploitation Steps:

  1. Craft a Malicious HEIF File:

    • Create a valid HEIF file with an iovl (overlay) box.
    • Set the overlay rectangle coordinates to cause a negative width or height. For example, set overlay_width to -1 or use an offset that pushes the rectangle beyond the source image.
    • Ensure the source image plane is small enough that the over-read will access adjacent memory.
  2. Deliver the File:

    • Host the file on a website or send it via email.
    • Convince the victim to open the file with a vulnerable application.
  3. Trigger the Vulnerability:

    • When the victim opens the file, the overlay() function is called.
    • The negative row length underflows to a huge size_t, causing memcpy to read a large chunk of heap memory.
    • This may crash the application or leak sensitive data (e.g., encryption keys, passwords) from the heap.

Example Crafting (Conceptual):

# Python script to craft a malicious HEIF file (simplified)
import struct

def create_malicious_heif():
    # Build a minimal HEIF file with an overlay box
    # This is a simplified example; actual HEIF structure is more complex
    ftyp = b'ftypheic'  # File Type Box
    meta = b'meta'       # Metadata Box
    iovl = b'iovl'       # Overlay Box
    # Set overlay width to -1 (0xFFFFFFFF as signed int)
    overlay_data = struct.pack('>I', 0xFFFFFFFF)  # width = -1
    # ... rest of the box structure
    with open('malicious.heic', 'wb') as f:
        f.write(ftyp + meta + iovl + overlay_data)

create_malicious_heif()

Blue Team (Defensive)

Detection:

  • Monitor for crashes in applications that use libheif (e.g., heif-convert, gimp).
  • Use memory analysis tools (e.g., Valgrind, AddressSanitizer) to detect heap over-reads.
  • Implement file scanning for HEIF files with suspicious overlay box parameters.

Mitigation:

  • Update libheif to version 1.21.0 or later.
  • If immediate update is not possible, avoid decoding images that use iovl overlay boxes.
  • Use a Web Application Firewall (WAF) or content filter to block HEIF files from untrusted sources.
  • Educate users about the risks of opening images from unknown sources.

Indicators of Compromise (IOCs)

  • File Hashes (SHA256): (None available publicly, but can be generated from crafted files)
  • Network Signatures: HEIF files with unusual overlay box parameters (e.g., negative width/height).
  • Behavioral IOCs:
    • Application crashes with segmentation faults when processing HEIF images.
    • Memory dumps showing large, unexpected reads from heap.
    • Logs containing errors related to HeifPixelImage::overlay().
  • YARA Rule (see Detection Engineering): Detects HEIF files with suspicious overlay box data.

Detection Engineering

YARA Rule

rule CVE_2025_68431_Heif_Overlay_Overread {
    meta:
        description = "Detects HEIF files with potentially malicious overlay box parameters (CVE-2025-68431)"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-68431"
        hash = "unknown"
    strings:
        $iovl = "iovl"  // Overlay box identifier
        $negative_width = { FF FF FF FF }  // 4-byte signed -1 for width
        $negative_height = { FF FF FF FF } // 4-byte signed -1 for height
    condition:
        $iovl and ($negative_width or $negative_height)
}

Sigma Rule

title: CVE-2025-68431 - Heap Buffer Over-read in libheif Overlay
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects crashes or errors related to heap buffer over-read in libheif's overlay function.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-68431
author: Valters IT
date: 2025/04/10
logsource:
    category: application
    product: libheif
detection:
    selection:
        EventID: 1000  # Application Error (Windows)
        Application: "heif-convert.exe"  # or other libheif-based apps
        ExceptionCode: 0xc0000005  # Access Violation
        FaultingModule: "libheif.dll"
    condition: selection
falsepositives:
    - Legitimate HEIF files with unusual but valid overlay parameters (rare)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-68431 - Potential HEIF Overlay Exploit"; flow:to_server; content:"|69 6f 76 6c|"; distance:0; within:4; content:"|ff ff ff ff|"; distance:0; within:4; classtype:attempted-user; sid:1000001; rev:1;)

Remediation & Mitigation

  1. Immediate Update: Upgrade libheif to version 1.21.0 or later. This is the only complete fix.
  2. Workaround: If update is not possible, avoid decoding images that use iovl overlay boxes. This can be done by configuring the application to reject such files or by using a different image decoder.
  3. Compensating Controls:
    • Use a sandbox or container to isolate applications that process untrusted HEIF files.
    • Implement file validation at the perimeter to block HEIF files with suspicious overlay parameters.
    • Monitor for crashes and anomalous memory access patterns.
  4. Long-term:
    • Conduct a code audit of libheif for similar issues in other image processing functions.
    • Integrate fuzzing into the development pipeline to catch such vulnerabilities early.

Valters IT

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2025-68431/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.