NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
.NET
.NET NuGet
Not in CISA KEV
MEDIUM severity

ImageMagick MSL: Stack overflow via infinite recursion in ProcessMSLScriptGHSA-9vj4-wc7r-p844

MEDIUM

GHSA-9vj4-wc7r-p844 is a medium-severity (CVSS 5.5) CWE-835 vulnerability in Magick.NET-Q8-x64. A fix is available for Magick.NET-Q8-x64 — see the affected versions and patch details below.

Also known asCVE-2026-23874
Published
Updated
Affected
18 pkgs
Patched
18 / 18
Exploits
None indexed
Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-9vj4-wc7r-p844.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs8th percentile — riskier than 8% of all scored CVEsHighest risk
0.00%0.23%0.46%0.69%0.0%0.2%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

18 pkgs affected
.NETMagick.NET-Q8-x64.NETMagick.NET-Q8-arm64.NETMagick.NET-Q8-x86.NETMagick.NET-Q8-OpenMP-x64.NETMagick.NET-Q8-OpenMP-arm64.NETMagick.NET-Q16-x64.NETMagick.NET-Q16-arm64.NETMagick.NET-Q16-x86+10 more

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.

Description

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

magick MSL:recursive.msl out.png

Method 2: Using OSS-Fuzz reproduce

python3 infra/helper.py build_fuzzers imagemagick
python3 infra/helper.py reproduce imagemagick msl_fuzzer recursive.msl

Or run the fuzzer directly:

./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:

#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 Packages

18 total 18 fixed
EcosystemPackageVulnerable rangeFix
.NETNuGetMagick.NET-Q8-x64all versions14.10.2dotnet add package Magick.NET-Q8-x64 --version 14.10.2
.NETNuGetMagick.NET-Q8-arm64all versions14.10.2dotnet add package Magick.NET-Q8-arm64 --version 14.10.2
.NETNuGetMagick.NET-Q8-x86all versions14.10.2dotnet add package Magick.NET-Q8-x86 --version 14.10.2
.NETNuGetMagick.NET-Q8-OpenMP-x64all versions14.10.2dotnet add package Magick.NET-Q8-OpenMP-x64 --version 14.10.2
.NETNuGetMagick.NET-Q8-OpenMP-arm64all versions14.10.2dotnet add package Magick.NET-Q8-OpenMP-arm64 --version 14.10.2
.NETNuGetMagick.NET-Q16-x64all versions14.10.2dotnet add package Magick.NET-Q16-x64 --version 14.10.2

Affected Products

1 product · 1 configurations
Application
imagemagickimagemagick
< 7.1.2-13
range

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for Magick.NET-Q8-x64, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update Magick.NET-Q8-x64 to 14.10.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9vj4-wc7r-p844 is resolved across your whole dependency graph.

  3. Workarounds

    Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatModerate

This vulnerability is rated Moderate for Red Hat products. It affects ImageMagick, where a stack overflow can occur due to infinite recursion when processing a specially crafted Magick Scripting Language (MSL) file. Exploitation requires an attacker to provide a malicious MSL file to a user or service that processes…

Workaround published by Red Hat
To mitigate this issue, restrict ImageMagick's ability to process Magick Scripting Language (MSL) files. This can be achieved by adding a policy entry to disable the MSL coder. Create or modify the ImageMagick policy file (e.g., `/etc/ImageMagick-7/policy.xml` or `/etc/ImageMagick/policy.xml`) to include the following line within the `<policymap>` tags: ```xml <policy domain="coder" rights="none" pattern="MSL" /> ``` After modifying the policy file, services or applications that use ImageMagick may need to be restarted for the changes to take effect. This may impact functionality that relies on processing MSL files.
Source: Red Hat security advisory for GHSA-9vj4-wc7r-p844 (CC BY 4.0)

Frequently Asked Questions

## 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.
O3 Security · Impact-Aware SCA

Is GHSA-9vj4-wc7r-p844 in your dependencies?

Find it across NuGet, including transitive dependencies.

ImageMagick MSL: Stack overflow via infinite recursion in…