CVE-2025-27795: GraphicsMagick DOS Vulnerability

CVE-2025-27795 Overview

CVE-2025-27795 affects GraphicsMagick versions before 1.3.46. The ReadJXLImage function in the JPEG XL (JXL) decoder lacks resource limits on image dimensions. Attackers can supply a crafted JXL image that declares excessively large dimensions, causing the decoder to allocate memory and CPU resources without bound. The flaw maps to CWE-770: Allocation of Resources Without Limits or Throttling and results in denial of service against any service that uses GraphicsMagick to process untrusted images.

Critical Impact
A single malicious JXL file can exhaust memory or CPU on a server processing untrusted images, taking the service offline without authentication or user interaction.

Affected Products

GraphicsMagick versions prior to 1.3.46
Applications and web services that link against vulnerable GraphicsMagick builds for JXL decoding
Container images and Linux distributions shipping GraphicsMagick before 1.3.46

Discovery Timeline

2025-03-07 - CVE-2025-27795 published to NVD
2026-01-29 - Last updated in NVD database

Technical Details for CVE-2025-27795

Vulnerability Analysis

GraphicsMagick decodes JPEG XL images through the ReadJXLImage coder. Before version 1.3.46, this code path read width and height fields from the JXL container without comparing them against the resource limits GraphicsMagick enforces for other formats. An attacker who supplies a JXL file declaring multi-gigapixel dimensions causes the decoder to request very large pixel buffers. The process then either exhausts available memory or spends significant CPU time, blocking other requests. The vulnerability requires no authentication and is reachable across the network on any endpoint that accepts user-supplied images and routes them through GraphicsMagick.

Root Cause

The root cause is missing input validation in ReadJXLImage. The function did not call into GraphicsMagick's standard resource limit checks (MagickResourceLimit) for width, height, or pixel area before allocating decode buffers. The upstream fix in commit 9bbae7314e3c3b19b830591010ed90bb136b9c42 adds those limit checks so oversized images are rejected before allocation occurs.

Attack Vector

Exploitation requires only that the target process a JXL file controlled by the attacker. Common attack surfaces include image upload endpoints, thumbnailers, document conversion pipelines, content management systems, and email gateways that invoke GraphicsMagick. The attacker uploads or links to a small JXL file whose header advertises extreme dimensions. Parsing the header is enough to trigger the allocation, so the file itself does not need to be large.

No verified public exploit code is available for this issue. Technical analysis is documented in the libjxl issue tracker and the related OSS-Fuzz report.

Detection Methods for CVE-2025-27795

Indicators of Compromise

GraphicsMagick or gm convert processes terminating with out-of-memory errors after JXL input
Sudden spikes in resident memory or CPU on workers processing user-supplied images
Image upload requests containing JXL files (.jxl, MIME image/jxl) followed by service unavailability
Repeated requests from a single source delivering small JXL payloads to image endpoints

Detection Strategies

Inventory all hosts running GraphicsMagick and confirm the installed version against 1.3.46
Inspect image-processing logs for ReadJXLImage errors, allocation failures, or OOM-killer events
Correlate web access logs for JXL uploads with downstream worker crashes or restarts
Apply CWE-770 detection logic to flag resource-exhaustion patterns in image converters

Monitoring Recommendations

Alert on cgroup memory.max or container OOM kills affecting image-processing services
Track HTTP 5xx rates on upload and thumbnail endpoints and correlate with payload content type
Monitor process-level CPU and RSS for gm, convert, and worker pools handling user content
Log and review GraphicsMagick policy violations through syslog or container stdout collectors

How to Mitigate CVE-2025-27795

Immediate Actions Required

Upgrade GraphicsMagick to version 1.3.46 or later on every affected host and container image
Reject JXL uploads at the application or web application firewall layer until patched builds are deployed
Run image-processing workers under strict cgroup memory and CPU limits to contain the blast radius
Validate image dimensions in the calling application before invoking GraphicsMagick

Patch Information

The fix is delivered in GraphicsMagick 1.3.46. Review the upstream patch in the Heptapod commit 9bbae731 and the release notes on the GraphicsMagick News page. Rebuild any statically linked downstream applications after upgrading.

Workarounds

Disable the JXL coder in GraphicsMagick policy if JXL support is not required
Set explicit width, height, area, and memory limits in the GraphicsMagick policy file
Pre-screen uploads with a lightweight parser that reads JXL header dimensions and rejects oversized files
Isolate image conversion in short-lived sandboxes or containers with enforced resource ceilings

bash

# Example GraphicsMagick policy.xml limits to constrain decoder resource usage
<policymap>
  <policy domain="resource" name="width"  value="16KP"/>
  <policy domain="resource" name="height" value="16KP"/>
  <policy domain="resource" name="area"   value="128MP"/>
  <policy domain="resource" name="memory" value="256MiB"/>
  <policy domain="resource" name="map"    value="512MiB"/>
  <policy domain="coder"    rights="none" pattern="JXL"/>
</policymap>