CVE-2025-62594 is a medium-severity (CVSS 4.7) Buffer Overflow vulnerability in Magick.NET-Q16-x64. No vendor fix is recorded yet; mitigation options are listed below.
ImageMagick CLAHE : Unsigned underflow and division-by-zero lead to OOB pointer arithmetic and process crash (DoS)
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 CVE-2025-62594.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2025-62594 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,333 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
Magick.NET-Q16-x64.NETMagick.NET-Q8-x64.NETMagick.NET-Q16-HDRI-x64.NETMagick.NET-Q8-OpenMP-x64.NETMagick.NET-Q16-HDRI-OpenMP-x64.NETMagick.NET-Q16-OpenMP-x64.NETMagick.NET-Q8-arm64.NETMagick.NET-Q16-arm64+4 moreReal-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
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.
- Unsigned integer underflow → out-of-bounds pointer arithmetic (OOB): when
tile_info.height == 0, the expressiontile_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). - Division/modulus by zero: where code performs
... / tile_info.widthor... % tile_info.heightwithout re-checking for zero, causing immediate division-by-zero crashes under sanitizers orabortat 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).
Details
Unsigned underflow(can lea to OOB)
-
Location:
MagickCore/enhance.c, around line 609 -
Version tested: 7.1.2-8 (local ASan(undefined). /UBSan build)
-
Vulnerable code
enhance.c: 609
p += (ptrdiff_t) clahe_info->width * (tile.height - 1); -
Root Cause
- If
tile.height == 0, then(tile.height - 1)underflows toUINT_MAX. - Multiplication with
clahe_info->widthyields a huge value close toSIZE_MAX. - Adding this to
pcauses pointer arithmetic underflow.
- If
Division-by-zero
-
File / Location:
MagickCore/enhance.c, around line 669 -
Version tested: 7.1.2-8 (local ASan(undefined). /UBSan build)
-
vulnerable code
enhance.c: 669-673
if ((image->columns % tile_info.width) != 0) tile_info.x=(ssize_t) (tile_info.width-(image->columns % tile_info.width)); tile_info.y=0; if ((image->rows % tile_info.height) != 0) tile_info.y=(ssize_t) (tile_info.height-(image->rows % tile_info.height)); -
Root cause
Missing input validation / bounds checks after computing default tile dimensions:
If either
tile_info.widthortile_info.heightis 0, this triggers a division by zero. Zeros can reach this point through:- Exact tiles: CLI
clahe 0x0!(the!forces zero to be used verbatim). - Auto tiles on tiny images: When a requested tile is
0(no!), the code derives a default from the image size (e.g.,dim >> 3). For images withdim < 8, this result is 0 unless clamped.
- Exact tiles: CLI
Reproduction
Unsigned underflow
Environment
Built with AddressSanitizer and UndefinedBehaviorSanitizer enabled.
export UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1
export ASAN_OPTIONS=abort_on_error=1:allocator_may_return_null=1:detect_leaks=0
Command
./magick xc:black -clahe 0x0 null:
Output
MagickCore/enhance.c:609:6: runtime error: addition of unsigned offset overflowed
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior MagickCore/enhance.c:609:6 in CLAHEImage
./magick -size 10x10 xc:black -clahe 0x0 null:
memory region corruption.
./magick -size 2000x2000 xc:black -clahe 0x0 null:
→ Significant memory consumption and evidence of memory region corruption.
./magick -size 4000x4000 xc:black -clahe 0x0 null:
→ Much larger memory usage; process appears to be aggressively consuming cache and address space.
./magick -size 8000x8000 xc:black -clahe 0x0 null:
→ Memory usage escalates further and begins exhausting available cache. If left running, the process is likely to crash (DoS) after sustained allocation attempts.
Division-by-zero
Environment: ASan/UBSan-enabled build.
export UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1
export ASAN_OPTIONS=abort_on_error=1:allocator_may_return_null=1:detect_leaks=0
Command
./magick -size 16x2 gradient: -type TrueColor -depth 8 -clahe 0x0! null:
Output
<img width="1915" height="818" alt="image" src="https://github.com/user-attachments/assets/cfe44432-b429-49e4-8673-2ed55ba9a961" />Notes: Without sanitizers, the process may terminate with just Aborted (still DoS).
Impact
- Primary: Denial-of-Service — crash or sustained resource exhaustion (memory/cache thrash) when processing crafted parameters or small images via CLI or API. Attackers can trivially trigger via
clahe 0x0!or by uploading very small images to services using ImageMagick. - Secondary (theoretical): OOB memory accesses and memory corruption could potentially be combined with other vulnerabilities to achieve more severe outcomes; however, no reliable code execution was demonstrated from these PoCs alone.
Suggested concrete patch snippets
Apply in CLAHEImage() after tile_info is computed but before any division/modulus/pointer arithmetic:
if (exact_tiles_requested && (tile_info.width == 0 || tile_info.height == 0)) {
ThrowMagickException(exception, GetMagickModule(), OptionError,
"CLAHEInvalidTile", "%lux%lu",
(unsigned long) tile_info.width,
(unsigned long) tile_info.height);
return (Image *) NULL;
}
if (!exact_tiles_requested) {
tile_info.width = (tile_info.width == 0) ? MagickMax((size_t)1, image->columns >> 3) : tile_info.width;
tile_info.height = (tile_info.height == 0) ? MagickMax((size_t)1, image->rows >> 3) : tile_info.height;
}
if (tile_info.width == 0 || tile_info.height == 0) {
ThrowMagickException(exception, GetMagickModule(), OptionError,
"CLAHEInvalidTile", "%lux%lu",
(unsigned long) tile_info.width,
(unsigned long) tile_info.height);
return (Image *) NULL;
}
ssize_t tile_h_minus1 = (ssize_t)tile_info.height - 1;
if (tile_h_minus1 < 0) {
ThrowMagickException(exception, GetMagickModule(), OptionError,
"CLAHEInvalidTile", "%lux%lu",
(unsigned long) tile_info.width,
(unsigned long) tile_info.height);
return (Image *) NULL;
}
p += (ptrdiff_t) clahe_info->width * tile_h_minus1;
Notes about exact_tiles_requested: if the CLI/Wand parser already exposes whether ! was present, use it. If not, add a parse-time flag so CLAHEImage can know whether 0 is literal or auto.
Credit
Team Whys
Bug Hunting Master Program, HSpace/Findthegap
Youngmin Kim [email protected]
Woojin Park
Youngin Won
@amethyst0225 [email protected]
Siyeon Han
Shinyoung Won
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| .NETNuGet | Magick.NET-Q16-x64 | all versions | No fix |
| .NETNuGet | Magick.NET-Q8-x64 | all versions | No fix |
| .NETNuGet | Magick.NET-Q16-HDRI-x64 | all versions | No fix |
| .NETNuGet | Magick.NET-Q8-OpenMP-x64 | all versions | No fix |
| .NETNuGet | Magick.NET-Q16-HDRI-OpenMP-x64 | all versions | No fix |
| .NETNuGet | Magick.NET-Q16-OpenMP-x64 | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for Magick.NET-Q16-x64, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of Magick.NET-Q16-x64 has shipped for CVE-2025-62594 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2025-62594 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2025-62594. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2025-62594 in your dependencies?
O3 Security finds CVE-2025-62594 across NuGet dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.