The EPSS score of 0.00243 significantly understates the actual risk from this vulnerability because it doesn't account for the architectural assumption this code breaks: Data::MuForm::Localizer treats .po files as trusted translator artifacts rather than attacker-controlled input.
The vulnerability stems from eval() being called on the Plural-Forms header parsed from .po files. When an attacker controls the language parameter and can place a malicious .po file at a readable path, they achieve arbitrary Perl command execution through system(). The path traversal component (the .po suffix requirement) means exploitation requires finding a writable directory or misconfigured permission—but that's a lower bar than compromising a translator workflow.
What makes this more dangerous than the EPSS score suggests: the surrounding code actively misleads security reviewers. The expand_named method and _mangle_value are safe—there's no injection there—which trains developers and automated tools to classify this module as low-risk. That classification keeps the language attribute exposed to user input without hesitation.
The module sits at version 0.05 with no active maintainer. There's no security release coming. The remediation path requires either a community fork or wholesale replacement—both introduce integration debt. Even patching your application code doesn't close the attack surface if deployment still permits loading .po files from attacker-reachable paths.
Check whether your framework exposes the language parameter to user input, audit what .po files exist in readable directories, and assume any .po file in a world-readable location is potentially attacker-controlled. The trust model this code assumes—translator-managed files in version control—no longer matches how modern deployments handle localization.