Image::WebP CVE-2026-58586

Requires the target Perl application to actually invoke Image::WebP (≤0.2) to decode a WebP image that the attacker can supply - the crafted image is the trigger, so exploitation is mediated by an application that accepts and decodes untrusted WebP input. Limiting factors: the victim application must choose to decode the malicious file (user interaction / attacker-controlled image delivery), the module must be the specific ZAPAD Image::WebP distribution with the bundled libwebp 0.3.0, and no system-libwebp upgrade mitigates it. There is no authentication bypass or network-service angle inherent to the module itself; reachability depends entirely on how the calling application exposes image decoding.

The raw CVSS 9.8 (AV:N/AC:L/PR:N/UI:N) reflects the worst-case memory-corruption-to-RCE potential of the embedded libwebp bug, but multiple independent signals temper the real-world urgency for this particular CVE: EPSS is only 0.17% (7th percentile), CISA SSVC marks Exploitation as 'none', and no public exploit targeting the Image::WebP module itself has surfaced, even though SSVC rates Automatable=yes and Technical Impact=total. The score also arguably overstates access requirements - exploitation is not truly zero-interaction because a malicious WebP must be delivered to and decoded by a calling application, so a UI:R framing (as NVD applied to the parent CVE-2023-4863) is more realistic. That said, because the parent libwebp flaw was severe and the fix is trivial, any operator running this module against untrusted image input should patch promptly rather than rely on the low EPSS. Note the CVSS network vector versus the library/UI-mediated delivery path is a genuine tension worth verifying against the actual deployment.

An attacker uploads or serves a specially crafted WebP image to a Perl web service that uses Image::WebP to process user-submitted images; when the module decodes it, the malformed VP8L Huffman data triggers the bundled libwebp 0.3.0 heap overflow, corrupting memory in the worker process. Given AC:L and the total technical impact, this can escalate from a crash to arbitrary code execution in the context of the decoding process; no public exploit tailored to this module is known, though exploitation of the underlying libwebp flaw has been demonstrated historically.