CVE-2026-66038

Executive Summary

CVE-2026-66038 is an information disclosure vulnerability in the FFmpeg LCL/ZLIB video decoder located in lcldec.c, affecting FFmpeg through version 8.1.2. The vulnerability allows an attacker to craft a malicious video file that supplies a valid zlib stream which inflates to fewer bytes than the expected frame size. When processed, the decoder treats this short decompression as non-fatal and proceeds to the RGB24 conversion path, which copies a full frame's worth of rows from the allocation buffer using the original frame dimensions. This causes uninitialized heap contents, including pointer-derived allocator bytes, to be copied into the attacker-observable AVFrame output. The impact is the exposure of sensitive heap memory data that could potentially defeat ASLR (Address Space Layout Randomization) in long-lived media processing services. The vulnerability has a CVSS score of 6.5 (Medium severity) and requires user interaction to trigger, but can be exploited remotely when a user processes a malicious media file.

Technical Analysis

The vulnerability resides in the LCL/ZLIB video decoder implementation within FFmpeg's lcldec.c source file. The LCL (LossLess Codec Library) format supports zlib-compressed video frames, and the decoder processes incoming compressed data through the zlib_decomp() function.

The core issue lies in the interaction between the zlib decompression routine and the subsequent color conversion logic. When a video frame is compressed using zlib, the decoder allocates a buffer sized according to the expected frame dimensions (width × height). The zlib_decomp() function is then called to inflate the compressed stream into this buffer. However, the vulnerability is triggered when a malicious zlib stream successfully decompresses but produces fewer bytes than the expected frame size.

In a properly hardened implementation, a short decompression result would be treated as a fatal error, causing the decoder to abort frame processing and preventing any output. However, in the vulnerable code path, zlib_decomp() treats this short decompression as non-fatal and returns successfully without error. The decoder continues execution to the RGB24 conversion stage.

At the conversion stage, the code uses the original frame dimensions (the expected width and height from the video stream header) rather than the actual decompressed byte count. This mismatch is the root cause of the vulnerability. The RGB24 conversion routine iterates over each row of the frame, copying data from the allocation buffer for each row. Since the zlib decompression wrote fewer bytes than the full frame size, portions of the allocation buffer were never written by the decompression routine and therefore retain their pre-initialization state.

Modern heap allocators (such as glibc's ptmalloc2) often leave residual data in freed or newly allocated memory blocks. This residual data frequently includes pointer-derived bytes — fragments of heap metadata, link-list pointers, and other allocator bookkeeping structures. When FFmpeg allocates the frame buffer, these uninitialized bytes remain in the allocation. The vulnerable conversion path then copies these bytes into the output AVFrame.

The attacker-observable AVFrame is subsequently accessible to the caller of the FFmpeg decoding API. In a media processing service that decodes untrusted input, an attacker can craft a video file, submit it to the service, and receive the decoded output frames. By analyzing the pixel data in the output frame — particularly the areas corresponding to the uninitialized portion of the buffer — the attacker can recover heap memory contents.

The security impact escalates when this vulnerability is used against long-lived media processing services. In such services, the heap contains pointers to various service structures, and the recovery of heap metadata bytes can allow an attacker to derive heap layout information. This information can defeat ASLR, which relies on the secrecy of memory addresses. With ASLR bypassed, subsequent exploitation attempts targeting other vulnerabilities (such as memory corruption flaws) become significantly more reliable.

The vulnerability is classified as CWE-908 (Use of Uninitialized Resource). The attack vector is network-based (an attacker delivers a malicious file), but user interaction is required (the victim must process the file). The confidentiality impact is high (heap data is exposed), while integrity and availability are unaffected.

Exploitation Scenarios

Scenario: Targeting a Video Processing Service

1. Reconnaissance and Target Identification: An attacker identifies a target service that processes untrusted video input using FFmpeg — for example, a video transcoding platform, an antivirus product that scans video files, a content management system with video upload capabilities, or a chatbot that analyzes screenshots/video frames. The attacker confirms FFmpeg usage by observing response headers, product documentation, or by uploading test video files and observing processing behavior.

2. Crafting the Malicious Video File: The attacker creates a video file using the LCL codec with a zlib-compressed video track. The file is structured with the following properties:

   • Frame dimensions: Set to a large resolution (e.g., 1920×1080) so the expected frame size is substantial (1920 × 1080 × 3 bytes for RGB24 = 6,220,800 bytes).
   • Compressed frame data: The attacker constructs a valid DEFLATE zlib stream that inflates to significantly fewer bytes than the expected frame size — for example, inflating to only 100 bytes rather than 6.2 MB. The zlib stream must be valid enough to pass zlib's integrity checks but short of the expected output size.
   • Codec header: Includes the LCL codec identifier and the frame dimensions.

3. Triggering the Vulnerability: The attacker delivers the crafted video file to the target service via any supported upload mechanism (HTTP upload, email attachment that gets scanned, API submission, etc.). The target service invokes FFmpeg to decode the file for processing. When FFmpeg reaches the video frame processing stage within the LCL decoder:

   • The zlib_decomp() function inflates the zlib stream, producing only 100 bytes instead of the expected 6.2 MB.
   • Because the short decompression is treated as non-fatal, the decoder does not abort.
   • The RGB24 conversion path executes, iterating through 1080 rows and copying 1920×3 bytes per row from the allocation buffer.
   • The first 100 bytes contain the decompressed data; the remaining ~6,220,700 bytes are uninitialized heap memory that gets copied into the output AVFrame.

4. Payload Execution and Data Recovery: The attacker obtains the decoded output frame from the service (through a transcoded output, an API response returning frame data, an image thumbnail, etc.). The attacker analyzes the pixel values in the output frame. Specifically:

   • Bytes at offsets beyond the 100-byte decompressed region contain uninitialized heap contents.
   • These bytes are interpreted as RGB pixel data, so the attacker extracts the raw byte values from the RGB triplets.
   • Among these bytes, the attacker looks for pointer-derived patterns — 8-byte sequences on 64-bit systems that appear as valid heap addresses (e.g., values in the range 0x7fXXXXXXXXXX or 0x55XXXXXXXXXX).
   • By correlating multiple frames or multiple decode attempts, the attacker identifies the heap base address and the layout of heap chunks.

5. Post-Exploitation Impact: With heap layout knowledge, the attacker achieves ASLR bypass for the target process. If the target service has other memory corruption vulnerabilities (such as a buffer overflow in another codec or parser), the attacker can chain this information disclosure with a separate exploit to achieve remote code execution with the privileges of the media processing service, bypassing the mitigation that would otherwise make reliable exploitation much more difficult.

Secondary Scenario: Supply-Chain Targeting: An attacker crafts a malicious media file and distributes it through legitimate channels (email attachments, torrent sites, media-sharing platforms). Users on media consumers or editing software running FFmpeg process the file. While this single-user scenario has lower impact, any user processing such a file exposes portions of their process heap, which may contain keys, tokens, or other sensitive data.

Impact Assessment

CVSS Analysis: The vulnerability has a CVSS 3.1 base score of 6.5 (Medium severity) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N. This reflects: a network attack vector (AV:N), low attack complexity (AC:L) since the attacker only needs to craft a valid zlib stream, no privileges required (PR:N), but mandatory user interaction (UI:R — the victim must process the file). The scope is unchanged (S:U), with a high confidentiality impact (C:H) due to heap memory disclosure, and no integrity (I:N) or availability (A:N) impact.

Business Impact: The primary business risk is the confidentiality breach of heap memory contents in media processing infrastructure. For enterprises running FFmpeg-based transcoding pipelines, content processing services, or security scanners, the exposure of heap memory can lead to:

• ASLR defeat: Memory addresses recovered can be used to bypass ASLR in the same process, escalating the severity of any co-located memory corruption vulnerabilities.
• Sensitive data exposure: Heap memory may contain session tokens, encryption keys, database credentials, or user data processed by the service.
• Regulatory concerns: If heap data contains regulated personal information, a successful exploit could constitute a data breach under GDPR, HIPAA, or PCI-DSS.

Affected Systems and Blast Radius: Any deployment of FFmpeg through version 8.1.2 that decodes untrusted LCL-encoded video is affected. This includes:

• Video transcoding and streaming platforms
• Server-side media processing APIs
• Antivirus and content-filtering products that parse video
• Digital rights management (DRM) systems
• Chat applications with inline video preview
• Email systems with video attachment preview
• Research and media archival systems

The EPSS score of 0.00256 (17.2% percentile) indicates low immediate threat of exploitation in the wild as of the score assessment, but the vulnerability's simplicity (valid zlib stream with short decompression) and the prevalence of FFmpeg mean the risk should not be dismissed.

Detection Guidance

Sigma Rule

title: Exploitation Attempt via FFmpeg LCL/ZLIB Decoder Heap Disclosure
id: c9f7d2a1-88c3-4b2c-9d6e-ff8a1e0b5d33
status: experimental
description: Detects potential exploitation of CVE-2026-66038 by monitoring FFmpeg process behavior anomalies consistent with the LCL/ZLIB decoder information disclosure vulnerability.
author: Valtersit Threat Intelligence
date: 2026/01/01
logsource:
    category: process_creation
    product: windows
detection:
    selection_ffmpeg:
        Image|endswith: '\ffmpeg.exe'
    selection_lcl_indicators:
        CommandLine|contains:
            - '-c:v'
            - 'lcl'
    selection_unusual_exit:
        ExitCode:
            - '0'
            - '1'
    condition: selection_ffmpeg and selection_lcl_indicators and selection_unusual_exit
level: medium
falsepositives:
    - Legitimate FFmpeg usage with LCL codec for valid short video clips
    - Media files that intentionally have truncated frames (corrupted but valid files)
fields:
    - ParentImage
    - CommandLine
    - User
tags:
    - cve-2026-66038
    - attack.t1204
    - attack.collection

YARA Rule

rule CVE_2026_66038_LCL_ZLIB_HEAP_DISCLOSURE
{
    meta:
        author = "Valtersit Threat Intelligence"
        date = "2026-01-01"
        description = "Detects video files crafted to exploit FFmpeg LCL/ZLIB decoder uninitialized heap disclosure (CVE-2026-66038)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-66038"
        cve = "CVE-2026-66038"
        score = 80
    strings:
        $lcl_fourcc_1 = "LCL" ascii wide
        $lcl_fourcc_2 = "ZLIB" ascii wide
        $lcl_fourcc_3 = "0x1E" // LCL video codec fourcc
        $avi_debug = "hdrl" ascii
        $avi_movi = "movi" ascii
        $zlib_header = { 78 01 } // zlib with low compression level (typical for crafted small streams)
        $zlib_header2 = { 78 9C } // zlib default compression
        $zlib_header3 = { 78 DA } // zlib best compression
    condition:
        uint32(0) == 0x46464952 and // "RIFF" (AVI container)
        (
            (1 of ($lcl_fourcc_*) and 1 of ($zlib_header*)) or
            (1 of ($lcl_fourcc_*) and filesize < 4MB and 1 of ($zlib_header*))
        )
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-66038 - Potential FFmpeg LCL/ZLIB Heap Disclosure via Uploaded Video"; flow:to_server,established; content:"POST"; http_method; content:"multipart/form-data"; http_header_content_type; pcre:"/filename=\"[^\"]+\.(avi|mkv|mov)\"/i"; content:"RIFF"; within:64; fast_pattern; content:"LCL"; within:1024; content:"ZLIB"; pcre:"/\\x78\\x01|\\x78\\x9C|\\x78\\xDA/"; classtype:attempted-information-leak; reference:cve,CVE-2026-66038; sid:2026066038; rev:1;)

Elastic Detection

// Detect FFmpeg processes processing LCL video content with abnormal heap growth patterns
any where process.name == "ffmpeg.exe" or process.name == "ffmpeg"
    and (
        // Look for increased memory usage patterns during decode operations
        (event.category == "process" and process.name == "ffmpeg"
            and process.memory_usage > 100MB
            and process.command_line contains "lcl")
        or
        // Detect file access to video files with LCL characteristics
        (event.category == "file" and event.action == "open"
            and file.name like "*"
            and file.extension in ("avi", "mkv", "mov")
            and file.size > 100KB
            and file.size < 10MB
            // Heuristic: file smaller than expected for its declared resolution
            and file.size < 1024 * 1024)
    )

Splunk SPL Query

index=windows OR index=linux
| search "ffmpeg" OR "avconv"
| where match(CommandLine, "(?i)lcl") OR match(CommandLine, "(?i)zlib")
| eval frame_resolution = if(match(CommandLine, "(?i)1920x1080|(3840x2160)" ), "high", 
                       if(match(CommandLine, "(?i)1280x720"), "medium", "low"))
| eval file_size = if(len(_raw) > 0, 0, 0) // placeholder for size check via other sourcetypes
| join type=inner max=0 span=1h 
    [search sourcetype="filesystem" 
    | stats sum(bytes) as total_bytes by file_path]
| where total_bytes < 1000000 AND frame_resolution == "high"
| stats count by host, CommandLine, frame_resolution
| where count > 1
| table _time, host, CommandLine, frame_resolution, count
| sort - count

Wazuh OSSEC Rule

<group name="cve-2026-66038,">
  <!-- Rule to detect FFmpeg LCL/ZLIB decoding behavior consistent with CVE-2026-66038 exploitation -->
  <rule id="100262" level="8">
    <decoded_as>syslog</decoded_as>
    <field name="program_name">ffmpeg</field>
    <regex>lcl|LCL|zlib|ZLIB</regex>
    <regex>error|failed|invalid</regex>
    <description>FFmpeg LCL/ZLIB decoder activity - potential CVE-2026-66038 exploitation attempt</description>
    <group>vulnerability,</group>
    <mitre>
      <id>T1204</id>
    </mitre>
    <options>no_full_log</options>
  </rule>

  <!-- Rule to detect process spawning from unexpected parent with FFmpeg LCL flags -->
  <rule id="100263" level="10">
    <decoded_as>syslog</decoded_as>
    <field name="program_name">auditd</field>
    <regex>execve</regex>
    <regex>ffmpeg|avconv</regex>
    <regex>lcl</regex>
    <description>FFmpeg spawned with LCL codec - unusual process behavior</description>
    <group>vulnerability,attack,</group>
    <mitre>
      <id>T1204</id>
    </mitre>
    <options>no_full_log</options>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 2/4 (CLAIMED — single source claims patch, not independently confirmed)

The NVD description states the vulnerability is "fixed in commit 8670835". While this patch reference comes only from the NVD and has not been independently verified against the FFmpeg release repository or official advisory, the existence of a fix commit is explicitly stated.

Immediate Mitigations (Before Patching):

1. Restrict LCL Codec Support: If LCL (LossLess Codec Library) video decoding is not a business requirement, the most effective immediate mitigation is to disable support for this codec. This can be achieved by:

   • Using FFmpeg's build configuration flags (e.g., --disable-decoder=lcl when compiling from source).
   • Configuring input sanitization layers that reject files declaring the LCL fourcc.
   • Implementing a codec allowlist/blocklist in applications that use FFmpeg's libavcodec API (checking AVCodecDescriptor for the LCL codec ID within the codec_id field and rejecting it).

2. Input Validation: For media processing services, implement pre-processing checks to validate video files before sending them to FFmpeg:

   • Reject files that declare large frame resolutions but have unusually small compressed frame data for the majority of frames.
   • Sanitize uploaded media in isolated sandboxes with memory limits.

3. Sandboxing: Run FFmpeg decode operations in restricted sandboxes (containers with minimal privileges, seccomp profiles, or dedicated VM instances) to limit the impact of any information disclosure.

Patch/Upgrade Steps:

1. Verify Patch Availability: Confirm the latest FFmpeg release contains commit 8670835 or a subsequent fix. Check the official FFmpeg repository (https://git.ffmpeg.org/ffmpeg.git) and the FFmpeg release announcements.
2. Upgrade FFmpeg: Upgrade to FFmpeg version 8.1.3 or later if a patched release is available. If the fix commit is not yet in a stable release branch, apply the patch manually:
   • Clone the FFmpeg source repository.
   • Checkout the release branch in use (e.g., release/8.1).
   • Apply commit 8670835 via git cherry-pick 8670835.
   • Rebuild and redeploy FFmpeg or link against the updated libraries.
3. Application Rebuilding: After updating FFmpeg libraries, recompile and redeploy applications that statically link against FFmpeg to ensure they use the patched code.

Long-Term Hardening:

1. Regular Update Cadence: Establish a process for regular FFmpeg updates, subscribing to the FFmpeg security mailing list and monitoring NVD announcements.
2. Codec Risk Assessment: Periodically review codec support enabled in media processing infrastructure. Disable rarely used codecs to reduce attack surface.
3. Memory Hardening: Enable additional memory protections at the OS level (e.g., ASLR, heap hardening options such as MALLOC_PERTURB_ for glibc to catch use-of-uninitialized-memory issues in testing).
4. Security Testing: Integrate fuzzing of the FFmpeg decoders (using AFL, libFuzzer, or similar tools) into the CI/CD pipeline to detect similar issues before they reach production.
5. Monitoring: Maintain the detection rules provided above to alert security teams of potential exploitation attempts.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-66038 — Official NVD vulnerability data, including the CNA title, description, CVSS vector, and CWE classification.

2. FFmpeg Official Repository: https://git.ffmpeg.org/ffmpeg.git — Source repository containing commit 8670835 that fixes the vulnerability. Security announcements are typically posted at https://ffmpeg.org/security.html.

3. CWE-908 — Use of Uninitialized Resource: https://cwe.mitre.org/data/definitions/908.html — MITRE Common Weakness Enumeration entry for the vulnerability class.

4. FIRST CVSS Specification: https://www.first.org/cvss/specification-document — Reference for interpreting the CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N used in this assessment.

5. EPSS (Exploit Prediction Scoring System): https://www.first.org/epss/ — Source for the EPSS score of 0.00256 (17.2% percentile) referenced in this report, indicating the predicted likelihood of exploitation.

Known Threat Actor Campaigns and Exploit-in-the-Wild Evidence: As of the writing of this report, there are no publicly known threat actor campaigns exploiting CVE-2026-66038, and no exploit-in-the-wild evidence has been reported. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score of 0.00256 places this CVE in the 17.2nd percentile of exploited vulnerabilities, indicating low immediate exploitation activity. However, the vulnerability's low exploitation complexity (valid zlib stream with short decompression) and the widespread deployment of FFmpeg make it a candidate for future inclusion in exploit toolkits, particularly for targeted attacks against media processing services.