Perl DBI EUVD-2026-59744

Two concrete prerequisites must both hold: (1) the target must be a 32-bit perl build where STRLEN is 32 bits wide - 64-bit builds are categorically not vulnerable; and (2) the attacker must be able to deliver an untrusted statement of at least 613,566,757 bytes (~585 MB) into DBI's preparse() function, since smaller inputs do not trigger the wraparound. Limiting factors: the enormous payload size, the requirement that the application actually feed untrusted data through preparse (not merely execute ordinary queries), and the disappearing prevalence of 32-bit perl in production all sharply constrain realistic exploitation despite the PR:N/UI:N vector. The placeholder-count limit (99,999) does NOT limit this path, which is reached by ordinary non-placeholder content.

The published CVSS 3.1 base score is 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H), but that raw score overstates real-world risk. Exploitation is gated on two significant conditions the vector does not capture: the target must be a 32-bit perl build (increasingly uncommon in modern server deployments), and an attacker must be able to route a ~585 MB untrusted statement into the specific preparse() code path, which is not a commonly exposed interface. These conditions justify treating attack complexity as high rather than low. Corroborating signals point to low urgency: EPSS is 0.20% (10th percentile), the CVE is not on CISA KEV, and no public exploit code has been identified. SSVC-style reasoning would rate exploitation as 'none' observed, automatable as unlikely (huge payload, narrow trigger), with high technical impact if achieved. Net assessment: a legitimate memory-safety bug worth patching, but a lower operational priority than its 9.8 headline suggests, especially for the majority of environments running 64-bit perl, which are not vulnerable at all.

An application running on 32-bit perl accepts a large text field that it later passes to DBI's preparse() (for example, to normalize placeholder syntax). An attacker submits a ~585 MB payload; the buffer-size math wraps to allocate only 19 bytes, and the parser writes the full payload past the allocation, corrupting the heap to cause a crash or potentially achieve code execution. No public proof-of-concept has been identified, and the multi-hundred-megabyte payload plus 32-bit-only requirement make opportunistic exploitation impractical.