Text::CSV_XS CVE-2026-110759

Triggers specifically when Text::CSV_XS->parse() (the in-memory string interface, NOT the useIO/getline streaming path, which the fix leaves untouched via 'unless (csv->useIO)') is given input that ends in a field separator immediately followed by a lone CR (0x0D) that is not part of a CRLF, AND the last field is empty - e.g. parse("a,\r"). The classic real-world trigger is a CRLF file read line-by-line and chomped (stripping the LF, leaving the bare CR) whose final column is empty. Non-empty last fields already error correctly and are unaffected. Limiting factors: the condition is narrow (empty trailing field + bare trailing CR), requires the string parse() API rather than getline, and the consequence is a corrupted byte/malformed UTF-8 rather than any control-flow or disclosure impact; versions 1.65 and later reject this input with error 2032.

The input CVSS 3.1 score of 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H) is severely inflated relative to the actual defect. The described behavior is a parser correctness/data-integrity bug (CWE-1286): when parse() receives input ending in a separator plus a lone CR with an empty last field, Text::CSV_XS stores the EOF marker as a spurious 0xFF byte rather than reporting error 2032. This yields no code execution, no memory disclosure, and no inherent service outage - so the claimed C:H/I:H/A:H impact is not supported by the description. The other signals corroborate low real-world risk: EPSS is 0.19% (8th percentile), the CVE is NOT in CISA KEV, and the only 'proof' is the vendor's own regression test (t/97_parse_eof.t) in the patch, not a weaponized exploit. These signals conflict sharply with the 9.8 rating. No SSVC decision data was provided. Net: this is a high-CVSS-but-low-real-risk issue - a data-corruption edge case worth patching for integrity-sensitive pipelines, not an urgent RCE-class emergency. The spurious 0xFF can also produce malformed UTF-8 on upgraded strings, which could secondarily break downstream consumers, but that is a derived effect, not direct attacker-controlled impact.

An application parses CSV with Text::CSV_XS->parse() on CRLF data that was read line-by-line and chomped, leaving a trailing lone CR; when the final column of the last record is empty, the parser returns a 0xFF byte that was never in the input, silently corrupting the field and producing malformed UTF-8 on UTF-8-flagged strings. The vendor's patch includes a regression test demonstrating the behavior (t/97_parse_eof.t), but no public weaponized exploit exists; realistic impact is data corruption in the consuming application rather than system compromise.