ImageMagick PerlMagick EUVD-2026-109418

Exploitation requires an application or script that uses the PerlMagick (Perl) binding of ImageMagick and that reads image properties - the leak lives specifically in five PerlMagick property-reading code locations, not in the core C library or other language bindings, so deployments that do not use PerlMagick are not exposed through this path. The attacker must be able to cause those property reads to happen repeatedly (a single read leaks only a trivial amount); a one-off read is harmless. Limiting factors: the vendor marks the vector local (AV:L) with passive user interaction (UI:P), impact is confined to availability with no data exposure, and affected versions are strictly before 7.1.2-33 - upgrading to 7.1.2-33 removes the exposure.

This is a genuinely low-priority issue despite a moderate 4.8 CVSS 4.0 score, and the available signals are internally consistent. The vendor vector (CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L) describes a local attack vector with no confidentiality or integrity impact and only LOW availability impact - a slow resource-exhaustion condition, not code execution. The CWE-401 memory leak must be triggered repeatedly before memory is exhausted, so impact accrues over time rather than instantly. No EPSS score was supplied, no CISA KEV listing is present, and no proof-of-concept or exploit reference is in the input - only the GHSA and VulnCheck advisories, which document the flaw rather than provide working exploit code. The vuln.today decision label is 'this_month' (not act_now or emergency), matching the picture of a real but non-urgent defect. The one point worth verifying: the vector marks AV:L (local) and UI:P (passive user interaction), yet exploitation realistically happens when an application built on PerlMagick processes attacker-supplied images and reads their properties in a loop - whether that counts as 'local' depends on how the hosting application exposes PerlMagick, so confirm the deployment context with the vendor advisory.

An application or script built on PerlMagick repeatedly reads image properties from attacker-influenced input (for example in a long-running image-processing worker). Because five PerlMagick code paths never free the values they return, each property read leaks a small amount of memory; over many iterations the process exhausts available memory and crashes or degrades, producing a denial of service. No public exploit code is identified in the provided sources, and the local vector plus low complexity mean the main prerequisite is simply driving enough property reads.