CVE-2026-110756 in Text::CSV_XS
Summary
by MITRE • 10/17/2026
Text::CSV_XS versions before 1.65 for Perl drop the end of a record and its line ending when a UTF-8 flagged field precedes invalid UTF-8 bytes in print.
When a record contains a UTF-8 flagged field, print holds back trailing bytes that are not valid UTF-8 at each buffer flush, so that a character split across two flushes can be completed. Nothing writes the held-back bytes after the record's final flush. A record whose last field ends in such a byte loses it, any closing quote and the line ending, while print still returns true. combine is not affected.
The next record is written onto the same line, or, when the last field was quoted, the missing closing quote makes a reader take every following record as part of that field.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/17/2026
Text::CSV_XS versions prior to 1.65 contain a critical data integrity vulnerability related to UTF-8 encoding handling during CSV output operations. This flaw specifically affects the print function when processing records where a UTF-8 flagged field is immediately followed by invalid or malformed UTF-8 bytes. The underlying technical mechanism involves an attempt to preserve character continuity across buffer flushes, which inadvertently leads to the silent truncation of data at record boundaries. When the library encounters this specific sequence, it holds back trailing bytes that are not valid UTF-8 during each buffer flush operation. This behavior is designed to ensure that a multi-byte character split across two separate flush operations can be correctly reconstructed and written as a single entity. However, the implementation fails to account for the end-of-record scenario, resulting in these held-back bytes never being flushed or written after the final flush of the record completes.
The operational impact of this vulnerability is severe data corruption that compromises both the integrity and readability of generated CSV files. Specifically, any record whose last field ends with such invalid UTF-8 bytes will suffer from partial output loss. The affected record loses its trailing byte, any closing quote character if present, and the standard line ending delimiter. Despite these significant omissions in the physical file content, the print function continues to return a true value, misleading application logic into believing that the data was successfully written without error. This discrepancy between reported success and actual output creates a silent failure mode where downstream systems receive incomplete or malformed records without raising immediate exceptions.
Furthermore, this truncation triggers cascading parsing errors in any consumer of the CSV file. Because the line ending is omitted, the next record begins writing on the same physical line as the previous one. If the last field was quoted, the absence of the closing quote causes subsequent parsers to interpret every following record as a continuation of that single malformed field. This effectively merges multiple distinct records into one massive, unparseable string, rendering large portions or all of the downstream data unusable until manual intervention occurs. The vulnerability is isolated to the print function and does not affect the combine method, highlighting an asymmetry in how input validation versus output encoding are handled within the library's architecture.
From a security perspective, this issue aligns with CWE-20 Improper Input Validation as it relates to the handling of encoded data streams, specifically failing to correctly process boundary conditions for character encodings. It also reflects weaknesses associated with CWE-175: Improper Handling of Multiple Types in One String, where mixed valid and invalid encoding states are not managed robustly at structural boundaries like record delimiters. In terms of MITRE ATT&CK mapping, this vulnerability falls under Tactic TA0043: Impact, specifically relating to Data Manipulation or Denial of Service through data corruption if the malformed CSV is fed into automated pipelines that assume valid structure.
To mitigate this risk, organizations relying on Text::CSV_XS for generating critical reports or data exports must upgrade immediately to version 1.65 or later, where the logic for handling trailing invalid bytes at record boundaries has been corrected. For environments unable to patch instantly, developers should implement pre-processing steps that validate and sanitize UTF-8 sequences before passing them to the print function, ensuring no malformed characters exist at field endings. Additionally, implementing rigorous post-generation validation checks on output files can help detect truncation issues early in the data pipeline. Monitoring for unexpected record lengths or missing delimiters in log outputs may also serve as an indirect detection mechanism for this specific encoding flaw until a permanent fix is deployed.