Hi,
The following vulnerabilities were published for libtext-csv-xs-perl.
CVE-2026-110753[0]:
| Text::CSV_XS versions from 1.46 before 1.65 for Perl have a use-
| after-free of bind_columns variables when skip_empty_rows skips an
| empty line in getline. With bind_columns, the parser writes each
| field into the caller's own scalar without taking a reference to it.
| When skip_empty_rows skips an empty last line, the parser frees the
| current field scalar without checking whether it is bound, dropping
| one reference from the application's variable. The "eof" mode does
| the same on any empty line. The variable is then freed while the
| application still references it, so later code uses freed memory and
| can crash the process.
CVE-2026-110752[1]:
| Text::CSV_XS versions before 1.65 for Perl allow memory exhaustion
| by allocating one entry per index of an RFC 7111 selector in
| fragment. fragment expands a row= or col= selector into an array
| with one element per selected index before it reads any data, and it
| does not clamp an explicit end column in a cell= selector to the
| row. Only the syntax and order of the ranges are checked, so
| row=1-400000000 on a two-line file allocates 400 million elements.
| An application that passes a request-supplied fragment to fragment
| or csv can be made to exhaust memory, which ends the process with an
| Out of memory error that eval cannot catch.
CVE-2026-110754[2]:
| 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.
CVE-2026-110755[3]:
| 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.
CVE-2026-110756[4]:
| 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.
CVE-2026-110757[5]:
| 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.
CVE-2026-110758[6]:
| Text::CSV_XS versions before 1.65 for Perl read before the start of
| an all-blank field under allow_whitespace in strip_trail_whitespace.
| Under allow_whitespace, strip_trail_whitespace removes trailing
| spaces and tabs from each unquoted field without stopping at the
| start of the field. For a field of only blanks it reads the byte
| before the field's heap buffer. If that byte is also a space or tab,
| it may be zeroed and the walk continue backwards, depending on what
| the allocator placed there. Leading blanks are normally skipped
| before a field is stored, but an all-blank field still arrives after
| a leading escape_char that differs from quote_char, or as a quoted
| field in getline when its line ends in two CRs.
CVE-2026-110759[7]:
| 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.
All fixes are included in 1.65 upstream. In the security-tracker we
link to the individual advisories and fixing commits for potential
backporting.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2026-110753
https://www.cve.org/CVERecord?id=CVE-2026-110753
[1] https://security-tracker.debian.org/tracker/CVE-2026-110752
https://www.cve.org/CVERecord?id=CVE-2026-110752
[2] https://security-tracker.debian.org/tracker/CVE-2026-110754
https://www.cve.org/CVERecord?id=CVE-2026-110754
[3] https://security-tracker.debian.org/tracker/CVE-2026-110755
https://www.cve.org/CVERecord?id=CVE-2026-110755
[4] https://security-tracker.debian.org/tracker/CVE-2026-110756
https://www.cve.org/CVERecord?id=CVE-2026-110756
[5] https://security-tracker.debian.org/tracker/CVE-2026-110757
https://www.cve.org/CVERecord?id=CVE-2026-110757
[6] https://security-tracker.debian.org/tracker/CVE-2026-110758
https://www.cve.org/CVERecord?id=CVE-2026-110758
[7] https://security-tracker.debian.org/tracker/CVE-2026-110759
https://www.cve.org/CVERecord?id=CVE-2026-110759
Regards,
Salvatore