CVE-2026-110759 in Text::CSV_XS
Summary
by MITRE • 10/17/2026
Text::CSV_XS versions before 1.65 for Perl return a 0xFF byte that is not in the input for an empty last field followed by a lone CR in parse.
When the input to parse ends in a separator and a lone CR, the parser treats the end of the input as the next character and stores the end-of-file marker in the field as the byte 0xFF. With binary set, parse("a,\r") returns the fields "a" and "\xFF". On UTF-8 flagged input the last field is a UTF-8 flagged string holding that lone byte, which is malformed UTF-8. The same input with a non-empty last field is rejected as an error.
A CRLF file read line by line and chomped ends this way when its last column is empty, so the application receives a byte that is not in its input.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability identified in Text::CSV_XS prior to version 1.65 represents a critical data integrity flaw within one of Perl’s most widely used CSV parsing libraries. This module serves as a foundational component for numerous enterprise applications, financial systems, and data processing pipelines that rely on accurate ingestion of comma-separated values. The core issue stems from an incorrect handling of line terminators when the input stream concludes with a specific sequence: a field separator followed immediately by a carriage return character without a subsequent newline or end-of-file marker in the expected manner. In standard CSV parsing logic, particularly under RFC 4180 and common industry practices, a trailing comma often indicates an empty final field. However, when this scenario is combined with a lone carriage return (CR) at the very end of the input buffer, the parser fails to recognize this as a valid line termination or error condition. Instead, it proceeds to treat the logical end-of-input as if there were another character present, specifically inserting an internal end-of-file marker byte represented by 0xFF into the final field array.
From a technical perspective, this behavior introduces two distinct layers of risk: data corruption and potential security implications through malformed string handling. When binary mode is enabled, which is common for processing raw bytes or non-textual data, the parser explicitly returns the byte sequence 0xFF as part of the parsed fields. For example, parsing the input "a,\r" results in two fields where the second field contains this unexpected 0xFF byte rather than being empty or triggering a parse error. This deviation from expected behavior means that downstream applications receive data that was not present in the original source file. The severity increases significantly when dealing with UTF-8 encoded inputs. In such cases, the lone 0xFF byte is flagged as part of a UTF-8 string but constitutes malformed UTF-8 because 0xFF is an invalid start or continuation byte for valid Unicode sequences. This can lead to runtime warnings, data truncation, or silent corruption in applications that assume well-formed text encoding, potentially causing crashes or incorrect logic execution in systems performing character set conversions or database insertions based on this parsed data.
The operational impact of this vulnerability is substantial due to the ubiquity of Text::CSV_XS in Perl ecosystems. Many legacy and modern scripts process log files, financial reports, and configuration dumps line by line using chomp operations that may strip newlines but leave carriage returns depending on platform-specific behaviors or manual implementation details. If a CSV file ends with an empty last column followed by a CR, which is not uncommon in data exports from certain spreadsheet applications or automated systems running on Windows-derived environments, the application will ingest corrupted data without raising an error. This silent failure makes debugging extremely difficult as the source code appears correct and no exceptions are thrown. The inconsistency where non-empty final fields trigger errors while empty ones result in this phantom byte insertion further complicates validation logic, allowing malformed records to slip through integrity checks that might otherwise reject them based on field count or content expectations.
This vulnerability aligns with CWE-20 Improper Input Validation and CWE-749 Exposed Dangerous Method or Function, as the parser fails to properly validate the structure of the input stream before processing it into data structures. It also relates to CWE-134 Use of Externally-Controlled Format String if the 0xFF byte is later interpreted in contexts sensitive to control characters, although its primary impact here is data integrity rather than code execution. From an ATT&CK perspective, this falls under Taint Analysis failures and potentially Data Injection if the corrupted field values are subsequently used in SQL queries or command line arguments without further sanitization, as the unexpected byte could alter query logic or string matching operations. The lack of error reporting for what should be a malformed record allows attackers to exploit these inconsistencies in complex parsing chains where downstream components trust the output of Text::CSV_XS implicitly.
Mitigation requires an immediate upgrade to version 1.65 or later, which corrects the parser’s state machine logic regarding end-of-file conditions and lone carriage returns. Developers relying on older versions must implement manual pre-processing steps to ensure that input streams are normalized before parsing, such as replacing trailing CR characters with CRLF sequences or explicitly handling empty final fields by checking for their presence after parse operations. Additionally, implementing strict validation of field counts and content types post-parsing can help detect anomalies caused by this bug in legacy systems where upgrading is not immediately feasible. Security teams should audit Perl-based applications that ingest external CSV data to identify potential exposure points where the 0xFF byte could influence critical business logic or security controls.