high · 7.5CVE-2026-53460Jun 25, 2026

CVE-2026-53460: Magick.NET (ImageMagick) AcquireAlignedMemory Policy Bypass DoS

Shubham Kandhare
Security Engagement Manager, SecureLayer7

A missing bounds check in ImageMagick's aligned memory allocator lets a crafted image bypass the operator-configured memory cap and exhaust process memory, crashing any application that processes…

PackageMagick.NET-Q16-AnyCPU
Ecosystemnuget
Affected< 14.14.0
Fixed in14.14.0
CVE-2026-53460: Magick.NET (ImageMagick) AcquireAlignedMemory Policy Bypass DoS

The problem

ImageMagick exposes a security-policy knob, system:max-memory-request, so administrators can cap how much memory a single allocation may consume.

The AcquireAlignedMemory function in MagickCore/memory.c skipped that policy check entirely. Every other allocator (AcquireQuantumMemory, AcquireVirtualMemory) already called GetMaxMemoryRequest() before allocating, but AcquireAlignedMemory did not.

A crafted image that drives a large aligned allocation could therefore blow past the configured limit, trigger an OOM condition, and crash the process. The CVSS score is 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H), reflecting unauthenticated network reachability with full availability impact.

Proof of concept

A working proof-of-concept for CVE-2026-53460 in Magick.NET-Q16-AnyCPU, with the exact payload below.

bash
# Trigger via any image format that routes through AcquireAlignedMemory
# with a size exceeding the policy cap (e.g. policy sets 256 MiB).
# A TIFF/BMP/etc. with crafted dimensions forces the oversized aligned alloc.

magick convert crafted_large.tiff /dev/null
# or via Magick.NET:
# using var image = new MagickImage("crafted_large.tiff");

# Relevant pre-patch code path in MagickCore/memory.c:
#
# BEFORE (vulnerable):
#   void *AcquireAlignedMemory(const size_t count, const size_t quantum)
#   {
#     size_t size = count * quantum;   // no max-memory-request check
#     return posix_memalign(..., size); // allocates whatever size is asked
#   }
#
# AFTER (patched, mirroring AcquireQuantumMemory / AcquireVirtualMemory):
#   void *AcquireAlignedMemory(const size_t count, const size_t quantum)
#   {
#     size_t size = count * quantum;
#     if (size > GetMaxMemoryRequest())  // <-- added policy gate
#       return NULL;                     // caller gets NULL, throws exception
#     return posix_memalign(..., size);
#   }

The root cause is CWE-770: the function allocated whatever size was requested without consulting the operator-configured system:max-memory-request policy. Sibling allocators AcquireQuantumMemory and AcquireVirtualMemory already called GetMaxMemoryRequest() and rejected oversized requests, but AcquireAlignedMemory had no equivalent gate.

The patch adds that same GetMaxMemoryRequest() check at the top of AcquireAlignedMemory, returning NULL (and letting the caller throw a ResourceLimitError) instead of forwarding an unbounded size to posix_memalign. No public standalone PoC binary has been released; the payload above is derived directly from reading the patch diff and the surrounding allocator code.

The fix

Update Magick.NET-Q16-AnyCPU to 14.14.0 or later, which bundles ImageMagick 7.1.2-25 (or 6.9.13-50 for the 6.x line). Also ensure your policy.xml contains an explicit system:max-memory-request cap (e.g., <policy domain="system" name="max-memory-request" value="256MiB"/>) so the new guard has a meaningful limit to enforce.

Reported by Aisle Research (Ze Sheng, Dmitrijs Trizna, Luigino Camastra, Guido Vranken).

References: [1][2][3][4]

Related research