CVE-2026-110754 in Text::CSV_XS
Summary
by MITRE • 10/17/2026
Text::CSV_XS versions before 1.65 for Perl leak the parsed fields of a record that fails to parse in getline.
getline collects the fields of a record into a new array and returns a reference to it only when the parse succeeds. When the record has a syntax error, getline returns undef and never frees the array or the fields parsed before the error.
A long-running process parsing untrusted CSV retains every malformed record it is sent, so repeated malformed input exhausts its memory.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/17/2026
The vulnerability identified in Text::CSV_XS versions prior to 1.65 represents a critical resource management flaw within a widely used Perl module for processing Comma-Separated Values data. This library serves as the de facto standard for high-performance CSV parsing in many enterprise and legacy systems, making its reliability paramount for applications handling large-scale data ingestion. The core issue resides in the getline method, which is responsible for reading and dissecting individual records from a stream of input data. Under normal operational conditions, this function allocates memory to store the parsed fields of a record into an array reference, returning it only upon successful parsing. However, when the input contains syntax errors or malformed structures that prevent complete parsing, the internal logic fails to release the previously allocated memory for the partially processed fields. This oversight results in a classic memory leak where resources are consumed but never returned to the system pool.
From a technical perspective, this flaw is categorized under CWE-401, which describes Memory Leak due to missing or improper free calls. The vulnerability manifests specifically when getline encounters an invalid record structure. Instead of discarding the partially parsed data and resetting its internal state cleanly, the module retains references to the allocated array elements. In a typical usage scenario where applications process untrusted user input or external data feeds, this behavior becomes particularly dangerous. Since long-running processes often operate continuously without restarts, they accumulate these leaked memory blocks over time. Each malformed record contributes additional unreleased memory allocations, creating a cumulative effect that steadily depletes the available system resources.
The operational impact of this vulnerability is severe, primarily leading to Denial of Service through resource exhaustion. An attacker or even accidental user input containing repeated malformed CSV records can trigger this leak repeatedly. As the process continues to parse these invalid inputs, its memory footprint grows linearly with each error until it exceeds available physical RAM and swap space. This eventually causes the application to crash due to out-of-memory conditions or forces the operating system kernel to invoke the Out-Of-Memory killer to terminate the process. In cloud-native environments or containerized deployments, this can lead to pod restarts, service interruptions, and potential cascading failures in dependent systems that rely on stable data ingestion pipelines.
This vulnerability aligns with ATT&CK technique T1496, Resource Hijacking, specifically under the sub-technique of resource consumption for denial of service. By exploiting the inefficient memory handling during error states, an adversary can effectively degrade system performance or cause complete unavailability without needing to execute arbitrary code or gain elevated privileges. The attack vector is straightforward and does not require complex exploitation chains; it relies solely on providing syntactically incorrect CSV data at a sufficient rate to overwhelm the target process's memory allocation limits before garbage collection mechanisms might otherwise intervene, although in this specific Perl module context, the references prevent such cleanup entirely for those specific objects.
Mitigation strategies must focus primarily on upgrading the underlying library infrastructure. Organizations utilizing Text::CSV_XS should immediately patch their environments to version 1.65 or later, where the developers have addressed this memory management defect by ensuring that allocated resources are properly freed even when parsing errors occur. For systems unable to update immediately due to dependency constraints, defensive programming practices can offer temporary relief. Implementing strict input validation and sanitization layers before data reaches the CSV parser can reduce the volume of malformed records processed. Additionally, monitoring application memory usage metrics for anomalous growth patterns correlated with error logs can help detect active exploitation attempts early. Restarting affected services periodically may serve as a stopgap measure to reclaim leaked memory until permanent remediation is applied.