ImageMagick

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month, rather than for the report. ImageMagick qualifies at Tier 2 through its OSS-Fuzz integration, so the ceiling is $5,000 and the $15,000 Tier 1 headline is not reachable. Patches the maintainers decline earn nothing, patches must be one to twelve months old, it is rate-limited to three submissions a month, one-liner fixes for non-exploitable crashes and resource-exhaustion DoS are excluded, and sanctions and territory exclusions apply. CVE history 149 Last 12 months 800 Lifetime Memory safety 50 % Parsing/validation 25 % Denial of service 15 % Code execution 8 % Latest advisories Loading the feed Overview ImageMagick is the default server-side image-processing engine of the internet, sitting behind PHP's Imagick extension, Ruby's MiniMagick, WordPress, MediaWiki, GitLab avatar handling and a long tail of upload pipelines. Its position is structurally dangerous: it is almost always reached by untrusted user-uploaded files, usually runs as the web application's own user, and frequently runs on hosts years behind on updates. ImageTragick (CVE-2016-3714) is still one of the most exploited server-side bugs of the last decade. The numbers follow: 800 CVEs lifetime and 149 in the last twelve months, half of them memory safety across a coders/ directory holding more than a hundred format readers. The project pays nothing for a report, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The project takes reports privately through GitHub private vulnerability reporting on ImageMagick/ImageMagick, and the boundary it draws is the delegate line: defects in third-party binaries such as Ghostscript or libtiff belong to those projects. What follows is ImageMagick's own tree The whole coders/ directory: more than a hundred format readers, each one parsing a different attacker-supplied format MagickCore in full, including pixel-cache and memory management, the source of a long run of heap overflows The policy.xml and magick.xml security-policy engine itself, where a bypass re-enables every coder an administrator believed they had turned off Delegate command construction in delegates.xml , the ImageTragick class of shell-injection bug Integer arithmetic on image dimensions, geometry strings and resample kernels, where a wrapped value feeds a later allocation or copy Out of scope One-liner fixes for non-exploitable crashes and resource-exhaustion denial of service, which rules out a large share of raw fuzzer output against this codebase Bugs in delegated third-party binaries such as Ghostscript or libtiff rather than in ImageMagick itself Patches the maintainers decline, and patches older than twelve months or younger than one month at submission More than three patch submissions per person per month on the Google pathway The Tier 1 ceiling, which ImageMagick cannot reach: it qualifies at Tier 2 through OSS-Fuzz, not as a named Tier 1 project Most-valued findings Heap corruption in a coders/ reader reachable from an ordinary user-uploaded file, the highest-value class here because memory safety is 50 percent of the record and the code runs as the web application's own user with no interaction at all. The MVG, MSL, SVG, PDF, EPHEMERAL and TEXT readers have historically enabled remote code execution and are where to start A policy.xml bypass, which is worth more than any single coder bug: it re-enables every format an administrator disabled after ImageTragick and reopens the whole class in one step Command injection through delegate construction, the ImageTragick shape, which turns an image upload directly into shell access Integer overflow in dimension, geometry or kernel arithmetic that produces an undersized allocation and a controlled write, rather than a crash A structural fix that removes a whole class from the coder or pixel-cache layer instead of one instance of it, since the top Patch Rewards band pays for changes that almost certainly prevent major vulnerabilities in the affected code and single-crash one-liners are excluded Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report privately through GitHub private vulnerability reporting on ImageMagick/ImageMagick, with the exact input file and command line that reproduces it Show the bug in ImageMagick itself; defects in delegated third-party binaries such as Ghostscript or libtiff belong with those projects, which have their own scope lines State the policy.xml configuration you tested under. A finding that only reproduces with the default policy relaxed is a different claim from one that survives it One-liner fixes for non-exploitable crashes and for resource-exhaustion denial of service are not rewarded, which matters more here than anywhere else in this niche because a large share of ImageMagick's CVE volume is exactly that shape If you also want the Google patch money, land the fix upstream yourself and keep it merged without reverts for one month. That pathway is capped at $5,000, limited to three submissions per person per month, and the patch must be between one and twelve months old Google cannot pay anyone on a sanctions list, in a sanctioned territory, or located in Russia or Belarus Disclosure Coordinated with the maintainers through GitHub private vulnerability reporting; ImageMagick patches quickly and publishes the outcome as a GitHub Security Advisory against a fixed release. Patch Rewards adds no embargo term of its own, so hold the detail until the advisory is out. Expect the practical exposure to outlast it, since the hosts running ImageMagick behind an upload form are typically far behind upstream. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability