CVE-2026-110755 in Text::CSV_XS
Summary
by MITRE • 10/17/2026
Text::CSV_XS versions before 1.65 for Perl allow quadratic CPU use by copying the unparsed remainder per record of CR-only input in getline.
With eol unset, the default, getline reads with Perl's default line separator, so input with CR-only line endings arrives as one chunk. After each record the parser copies the whole unparsed remainder into a new buffer, which the next call parses and copies again, so the work grows with the square of the input size.
A reader with default options that is sent CSV with classic Mac line endings spends seconds of CPU time on a megabyte of input.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability identified in Text::CSV_XS prior to version 1.65 represents a significant performance degradation issue rooted in the library's handling of specific character encoding and line ending conventions within Perl environments. This flaw is classified as an algorithmic complexity vulnerability, specifically aligning with CWE-400: Uncontrolled Resource Consumption. The core technical deficiency lies in how the getline function processes input streams that utilize classic Macintosh-style carriage return (CR) characters as line delimiters without explicitly setting the end-of-line configuration option. Under default operational settings, Perl utilizes its standard line separator logic, which causes CR-only delimited data to be ingested as a single, massive chunk rather than being segmented into discrete records during initial parsing.
When the parser encounters this unsegmented input block containing multiple logical CSV records separated by carriage returns, it must manually identify record boundaries based on internal state and delimiter definitions. The critical flaw occurs in the memory management strategy employed after each successful extraction of a single record from this large buffer. Instead of advancing pointers or utilizing efficient substring operations that share underlying data structures where possible, the implementation copies the entire remaining unparsed portion of the input string into a new buffer for subsequent processing cycles. This means that if an input file contains N records, the first iteration processes nearly all bytes, the second iterates over slightly fewer but still substantial bytes, and so on, resulting in a cumulative computational workload proportional to the square of the number of records or total byte count.
This quadratic time complexity behavior has severe operational impacts for applications relying on Text::CSV_XS for data ingestion tasks involving large datasets with non-standard line endings. A system processing a one-megabyte CSV file using classic Mac line endings can experience excessive CPU utilization, potentially leading to service unavailability through resource exhaustion or denial of service conditions in web-facing APIs that accept user-uploaded files. The prolonged execution time not only degrades application responsiveness but also increases the attack surface for timing-based side-channel attacks and consumes disproportionate server resources during peak loads. From a threat modeling perspective, this aligns with ATT&CK technique T1496: Resource Hijacking, where an attacker or malformed input can cause the target system to consume excessive computational resources.
Mitigation strategies primarily involve upgrading to Text::CSV_XS version 1.65 or later, which addresses this inefficiency by optimizing buffer handling and avoiding redundant data copying during record extraction. For environments unable to immediately upgrade, administrators should enforce strict validation of input formats at the ingestion layer, ensuring that CSV files are normalized to use standard Unix-style line endings (LF) before processing. Additionally, configuring the parser with explicit end-of-line settings can sometimes alter parsing behavior depending on specific implementation details, though upgrading remains the definitive remediation path to eliminate the quadratic complexity flaw entirely and restore expected linear performance characteristics for large-scale data processing operations.