CVE-2026-110757 in Text::CSV_XS
Summary
by MITRE • 10/17/2026
Text::CSV_XS versions before 1.65 for Perl allow record splitting by writing strings used as numbers without quotes in combine.
combine and print do not check whether a field needs quotes when its value has Perl's integer or numeric flag set. Perl sets these flags on a string used in a numeric operation when it parses as a number, which allows leading and trailing whitespace. With binary set, as csv does by default, "12\n" passes a check such as $qty > 0 and is then written unquoted with its newline.
A value validated as a number can end the record early and turn the fields after it into a separate row.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability in Text::CSV_XS prior to version 1.65 represents a critical input validation flaw within the Perl CSV processing library, specifically affecting how data is serialized during output operations. The core issue resides in the combine and print functions, which are responsible for converting internal data structures into formatted CSV strings. These functions fail to adequately verify whether specific fields require quoting based on their content or metadata flags. In Perl, when a string value participates in a numeric operation and parses successfully as a number, the language engine automatically sets an integer or numeric flag on that scalar variable. This behavior is standard for Perl's type juggling but introduces significant security risks when combined with CSV serialization logic that does not account for these internal metadata states.
The technical flaw manifests because Text::CSV_XS checks if binary mode is enabled and whether the value passes basic numeric comparisons, such as greater than zero, without subsequently verifying if the underlying string contains characters that necessitate quoting in a CSV context. For instance, a string like "12\n" will pass a numeric check because Perl interprets it as the number twelve after stripping trailing whitespace during the numeric conversion process. However, when this value is written to the output stream using combine and print, the library does not detect that the original data contains a newline character. Consequently, the field is emitted without surrounding quotes, preserving the embedded newline within the CSV record structure.
This behavior leads directly to CSV injection attacks, specifically known as CSV Injection or Excel Formula Injection when viewed from an end-user perspective, but more accurately classified here as Record Splitting via Unquoted Newlines. By injecting a value that contains both numeric characteristics and control characters like newlines, an attacker can manipulate the structure of the generated CSV file. The unquoted newline effectively terminates the current record prematurely. Any subsequent fields or data intended to be part of the same logical row are instead interpreted by downstream parsers as belonging to a new, separate row. This structural manipulation allows for the creation of malformed records that deviate from the expected schema and layout defined by the application logic.
The operational impact of this vulnerability is severe in environments where CSV files generated by Perl applications are consumed by other systems or users without rigorous validation. Downstream parsers, including spreadsheet software like Microsoft Excel or Google Sheets, may interpret these artificially split rows as distinct data entries. This can lead to data integrity issues, misalignment of columns across different records, and potential logic errors in automated processing pipelines that rely on fixed row structures. Furthermore, if the CSV is used for importing data into a database or another application, this record splitting could result in incorrect data insertion, where values meant for one field are incorrectly mapped to fields in subsequent rows, potentially leading to broader system compromise or data corruption depending on the sensitivity of the information involved.
To mitigate this vulnerability, organizations must upgrade Text::CSV_XS to version 1.65 or later, which addresses these checks by ensuring that fields containing special characters such as newlines are properly quoted regardless of their numeric flags. For systems unable to immediately patch, a defensive coding practice involves explicitly wrapping all field values in quotes during the combine operation before printing, thereby neutralizing any embedded control characters that could alter record boundaries. Additionally, implementing strict input validation on data entering CSV generation processes can help identify and sanitize potentially malicious payloads before they reach the serialization layer.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the software fails to validate or incorrectly validates user-supplied input during the processing of structured data formats. It also relates to CWE-748 Improper Preservation of Vulnerable Default Values if legacy configurations are relied upon without updates. In terms of attack vectors and techniques, this behavior is consistent with ATT&CK technique T1560.002 Archive Collected Data via Compressed Archives or more broadly data manipulation tactics where an attacker alters the structure of stored information to evade detection or cause processing errors. The specific mechanism of record splitting through unquoted delimiters highlights the importance of treating all input as potentially hostile, even when it appears benign due to numeric conversion rules inherent in programming languages like Perl.