Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
94 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Magick fails to check for multi-layer nested mvg conversions to svg, leading to DoS.
Recommended action: Upgrade to 14.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 14.10.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 Method 2: Using OSS-Fuzz reproduce Or run the fuzzer directly: Expected Behavior ImageMagick should handle the malformed MSL gracefully and return an error message. Actual Behavior Root Cause Analysis In coders/msl.c:7091, MSLEndElement() calls DeleteImageProperty() on mslinfo-image[n] when handling the </comment end tag without checking if the image is NULL: When <comment appears before any <read operation, mslinfo-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…
Recommended action: Upgrade to 14.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 (platformname, vendorname, 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 devicebenchmark structure is freed,…
Recommended action: Upgrade to 14.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 Method 2: Using OSS-Fuzz reproduce Or run the fuzzer directly: Expected Behavior ImageMagick should handle recursive MSL references gracefully by detecting the loop and returning an error. Actual Behavior Stack overflow causes process crash: 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: Impact - DoS: Guaranteed crash via stack exhaustion - Affected: Any application using…
Recommended action: Upgrade to 14.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 14.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Magick fails to check for circular references between two MVGs, leading to a stack overflow. Details After reading mvg1 using Magick, the following is displayed: Impact This is a DoS vulnerability, and any situation that allows reading the mvg file will be affected.
Recommended action: Upgrade to 14.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Using Magick to read a malicious SVG file resulted in a DoS attack. Details bt obtained using gdb: This is related to the SVGStartElement and ResizeQuantumMemory functions. PoC 1. Generate an SVG file 2. Read this file using Magick: 3. Causes a DoS Attack My server has a large amount of memory, causing a stack overflow to take a long time. I'll use the Windows release version as an example: The error code -1073741571 indicates a crash due to a stack overflow. Impact This is a DoS vulnerability and all applications using Magick to parse SVG files are affected.
Recommended action: Upgrade to 14.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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() permits advancing the stream offset beyond the current end without increasing capacity. The subsequent WriteBlob() 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…
Recommended action: Upgrade to 14.8.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 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 Inside FormatLocaleString, the variable argument list is initialized through vastart, 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 Processing a malicious filename containing format string specifiers such as %d%n results in corruption of the…
Recommended action: Upgrade to 14.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 Steps Observed result PoC No external file required; the…
Recommended action: Upgrade to 14.8.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
- 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…
Recommended action: Upgrade to 14.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. If we look at the calculation for magnifiedwidth, we can see that we are storing the results in a pnguint32. The operations at \[0\] and \[1\] are safe, since mnginfo-magnml and mnginfo-magnmx are both 16-bit unsigned integers, but both the multiplication at \[2\] and the addition of the result of that multiplication to magnifiedwidth can overflow, leading to a value of magnifiedwidth 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,…
Recommended action: Upgrade to 14.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. jngcolortype = 12), we will load the alpha pixels in this loop: Note that at \[1\] we update image-alphatrait, 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-numchannels has increased to include the new alpha channel, and now length and the previously…
Recommended action: Upgrade to 14.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
While Processing a crafted TIFF file, imagemagick crashes. Details Following is the imagemagick version: PoC issue can be replicated with following command with provided POC file(sent over email): Impact This can lead to application crash. Credits Please give credits to Hardik shah of Vehere (Dawn Treaders team)
Recommended action: Upgrade to 13.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: x8664 - Compiler: gcc with AddressSanitizer (gcc version: 11.4.0) Reproduction Steps Output Commits Fixed in https://github.com/ImageMagick/ImageMagick/commit/fc3ab0812edef903bbb2473c0ee652ddfd04fe5c and https://github.com/ImageMagick/ImageMagick6/commit/d49460522669232159c2269fa64f73ed30555c1b
Recommended action: Upgrade to 14.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 PREEMPTDYNAMIC Thu, 10 Apr 2025 18:43:59 +0000 x8664 GNU/Linux (GNU libc) 2.41) - Architecture: x8664 - Compiler: gcc (GCC) 15.1.1 20250425 Reproduction Build Instructions Minimum Trigger Crash Analysis AddressSanitizer Output Root Cause Analysis The first command line argument is interpreted as MagickImageCommand: https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/utilities/magick.c#L83 It is invoked here: https://github.com/ImageMagick/ImageMagick/blob/8fff9b4f44d2e8b5cae2bd6db70930a144d15f12/MagickWand/magick-cli.c#L220 The execution then follows this path: -…
Recommended action: Upgrade to 14.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 onegadget in libc, provided that options and filenames can be controlled. Details - Vulnerability Type: CWE-124: Buffer Underwrite - Affected Component:…
Recommended action: Upgrade to 14.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Infinite lines occur when writing during a specific XMP file conversion command Details 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 : Imho e-mail : [wndnjs4698@naver.com] Kyusang Han Github : T1deSEC e-mail : [hksjoe0081@gmail.com] JaeHun…
Recommended action: Upgrade to 14.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.