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

CVE-2024-55195

CVE-2024-55195 Denial of Service in Openimageio
📅 PUBLISHED: 2025-01-23 00:00 UTC 🔄 UPDATED: 2026-09-24 05:59 UTC
[ PATCH UNDER REVIEW ↓ ] Remains UNDER REVIEW until an independent source confirms the 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.54%
👁️
0.54% probability
13.5× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
VULNERABLE: version not auto-detected — verify your deployed version locally
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
SOON
PENDING NVD
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2024-55195 is a Denial of Service (DoS) vulnerability in OpenImageIO v3.1.0.0dev, specifically within the /imagebuf.cpp component. The flaw is an allocation-size-too-big bug that occurs when the program is requested to allocate an excessively large memory space. This can lead to resource exhaustion, causing the application to crash or become unresponsive. The vulnerability has a CVSS score of 0.0 (likely unassigned or placeholder), and no public exploit or patch is currently available. The EPSS score is 0.0%, indicating a very low probability of exploitation in the wild at this time.

⚡ 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

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is atypical and likely indicates that a full CVSS vector has not been assigned by NVD. Based on the nature of the vulnerability (DoS via memory allocation), a reasonable estimated vector would be:

  • Attack Vector (AV): Local (L) – Requires local access to trigger the allocation.
  • Attack Complexity (AC): Low (L) – Simple to trigger via crafted input.
  • Privileges Required (PR): None (N) – No special privileges needed.
  • User Interaction (UI): Required (R) – User must open a malicious file or trigger the allocation.
  • Scope (S): Unchanged (U) – Affects only the vulnerable component.
  • Confidentiality (C): None (N) – No data breach.
  • Integrity (I): None (N) – No data modification.
  • Availability (A): High (H) – Complete loss of availability.

Estimated CVSS Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

Threat Level: Medium (due to DoS impact but low exploitation probability).

Deep Dive & Mechanics

The vulnerability resides in the imagebuf.cpp file of OpenImageIO v3.1.0.0dev. The bug is an allocation-size-too-big error, which occurs when the software attempts to allocate memory for an image buffer based on user-supplied dimensions or metadata. If an attacker provides a crafted image file with excessively large width, height, or channel count, the allocation size calculation can overflow or exceed available memory, leading to a crash or denial of service.

The root cause is likely a missing or insufficient validation of image dimensions before memory allocation. The ImageBuf class in OpenImageIO is responsible for managing image data in memory. When loading an image, it calculates the required buffer size as width * height * channels * bytes_per_channel. If the product of these values is too large, the allocation fails, and the program may not handle the failure gracefully, resulting in a crash.

Vulnerable vs. Patched Code

Vulnerable Code (hypothetical example from imagebuf.cpp):

// Vulnerable: No size validation before allocation
size_t size = width * height * channels * sizeof(float);
float* data = new float[size]; // May throw std::bad_alloc or crash

Patched Code (hypothetical fix):

// Patched: Validate allocation size before allocation
size_t size = width * height * channels * sizeof(float);
if (size > MAX_ALLOC_SIZE || size == 0) {
    // Handle error gracefully
    return false;
}
float* data = new (std::nothrow) float[size];
if (!data) {
    // Handle allocation failure
    return false;
}

The patch would involve adding bounds checking to ensure the calculated size does not exceed a safe limit (e.g., available memory or a predefined maximum) and using std::nothrow to avoid exceptions.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

  • OpenImageIO v3.1.0.0dev installed on a target system.
  • Ability to deliver a crafted image file to the target (e.g., via email, web download, or file share).

Exploitation Steps:

  1. Craft a malicious image file (e.g., TIFF, PNG, or EXR) with extremely large dimensions (e.g., width=100000, height=100000, channels=4).
  2. Deliver the file to the target user.
  3. When the user opens the file with an application using OpenImageIO (e.g., iinfo, iv, or a custom tool), the vulnerable code attempts to allocate memory for the buffer.
  4. The allocation fails, causing the application to crash or hang, resulting in a Denial of Service.

Example Crafting (using Python):

# Craft a minimal TIFF with huge dimensions
import struct

def create_malicious_tiff(filename):
    # TIFF header (little-endian)
    header = b'II' + struct.pack('<H', 42)  # Magic number
    # IFD (Image File Directory) with large width/height
    # Simplified: set ImageWidth=100000, ImageLength=100000
    # This is a basic example; real exploit would need valid TIFF structure
    with open(filename, 'wb') as f:
        f.write(header)
        # ... (complex TIFF structure omitted for brevity)
    print(f"Created {filename}")

create_malicious_tiff('exploit.tif')

Blue Team (Defense)

Detection:

  • Monitor for unusually large memory allocation requests by OpenImageIO processes.
  • Use file scanning to detect images with unrealistic dimensions (e.g., width > 65535 or height > 65535).
  • Implement resource limits (e.g., ulimit on Linux) to prevent excessive memory usage.

Mitigation:

  • Apply patches from OpenImageIO when available.
  • Use a Web Application Firewall (WAF) or file upload scanner to reject files with suspicious metadata.
  • Educate users not to open untrusted image files.

Indicators of Compromise (IOCs)

  • File Hashes: (No known samples; hypothetical)
    • malicious.tif: SHA256 a1b2c3d4e5f6...
  • Process Behavior:
    • OpenImageIO process (iinfo, iv, etc.) crashes with std::bad_alloc or SIGABRT.
    • System logs showing out-of-memory (OOM) killer terminating the process.
  • Network Traffic: None (local exploitation).
  • File Artifacts:
    • Image files with dimensions exceeding 65535 pixels in width or height.
    • Image files with calculated buffer size > 2GB (on 32-bit systems) or > available RAM.

Detection Engineering

YARA Rule

rule CVE_2024_55195_OpenImageIO_DoS {
    meta:
        description = "Detects malicious image files targeting CVE-2024-55195"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-55195"
    strings:
        $tiff_magic = { 49 49 2A 00 }  // Little-endian TIFF
        $exr_magic = { 76 2F 31 01 }  // OpenEXR magic
        $png_magic = { 89 50 4E 47 }  // PNG magic
    condition:
        ($tiff_magic or $exr_magic or $png_magic) and
        // Check for unrealistic dimensions (simplified)
        filesize < 10MB and
        // Additional heuristic: look for large width/height in metadata
        for any of ($tiff_magic, $exr_magic, $png_magic) : (
            // Placeholder for actual dimension extraction
            false
        )
}

Sigma Rule

title: OpenImageIO DoS via Excessive Memory Allocation
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects crashes or excessive memory allocation by OpenImageIO processes
author: Valters IT
date: 2025-04-10
references:
    - CVE-2024-55195
logsource:
    category: process_creation
    product: linux
detection:
    selection:
        Image|endswith:
            - '/iinfo'
            - '/iv'
            - '/oiiotool'
        CommandLine|contains:
            - '*.tif'
            - '*.exr'
            - '*.png'
    condition: selection
falsepositives:
    - Legitimate large image processing
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-55195 OpenImageIO DoS Attempt"; flow:to_server,established; content:"Content-Type|3a| image/"; nocase; pcre:"/\.(tif|exr|png)$/i"; classtype:attempted-dos; sid:1000001; rev:1;)

Remediation & Mitigation

  1. Immediate Actions:

    • Disable or restrict use of OpenImageIO v3.1.0.0dev in production environments.
    • Implement resource limits (e.g., ulimit -v 1048576 to limit virtual memory to 1GB).
    • Use file validation tools to reject images with unrealistic dimensions.
  2. Long-term Fix:

    • Apply official patches from OpenImageIO when released.
    • Upgrade to a patched version (e.g., v3.1.0.1 or later).
    • If no patch is available, consider forking the code and applying the fix described in the "Vulnerable vs. Patched Code" section.
  3. Monitoring:

    • Enable logging for memory allocation failures.
    • Monitor for crashes of OpenImageIO-related processes.
  4. User Education:

    • Train users to avoid opening image files from untrusted sources.

Valters IT

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2024-55195/ · 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.