Crypt::DSA EUVD-2026-30668

Exploitation requires three conditions to be simultaneously true: the target application uses Crypt::DSA version 1.19 or earlier; the application accepts user-supplied or externally influenced input as a filename argument passed to Crypt::DSA key functions in lib/Crypt/DSA/Key.pm; and that filename is not sanitized to strip Perl open() metacharacters before use. The CVSS vector AV:N/AC:L/PR:N/UI:N applies when a network-accessible interface satisfies these conditions - for example, an API endpoint or web form that designates a DSA key file path. Exploitation is blocked when filenames are hardcoded, sourced from trusted server-side configuration, or sanitized prior to library use. The impact is limited to partial confidentiality (C:L) and partial integrity (I:L) - full system compromise is not indicated by available data.

CVSS 3.1 scores this 6.5 (Medium) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. The network attack vector and absence of required privileges or user interaction suggest unauthenticated remote exploitation in qualifying deployments. However, this rating is context-dependent: exploitation is contingent on a consuming application exposing a code path where an attacker-controlled string reaches Crypt::DSA key-handling functions without sanitization - the library itself does not listen on a network. EPSS is 0.01% (0th percentile), consistent with the narrow exploitation window and absence of known mass exploitation. This CVE is not in CISA KEV, and no public exploit code has been identified at time of analysis. The real-world priority is low for applications using Crypt::DSA with hardcoded or server-controlled key paths, but rises meaningfully for internet-facing Perl applications accepting user-supplied key filenames. No conflict between CVSS signals and description was identified; the network vector is plausible if the library is used in a web context.

An attacker targets a web application that accepts a user-supplied key file path and passes it to Crypt::DSA for key loading. The attacker submits a filename prefixed with '>' - such as '>/var/www/html/shell.pl' - causing Perl's 2-argument open() to open that path in write mode rather than reading a key file, with attacker-influenced content written to the target. No public exploit code exists, but the technique is well-documented in Perl security literature and requires only knowledge of the application's key-loading interface.