GHSA-wpp4-vqfq-v4hp
MEDIUMImageMagick CLAHE : Unsigned underflow and division-by-zero lead to OOB pointer arithmetic and process crash (DoS)
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.
Blast Radius
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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of Magick.NET-Q16-x64 has shipped for GHSA-wpp4-vqfq-v4hp 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 pinpoints whether GHSA-wpp4-vqfq-v4hp is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-wpp4-vqfq-v4hp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-wpp4-vqfq-v4hp in your dependencies?
O3 detects GHSA-wpp4-vqfq-v4hp across NuGet dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.