CVE-2026-110759: 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

Published Oct 16, 2026
·
Updated

Text::CSVXS 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.

Affected Software

1 affected component
cpan/Text-CSV_XS<1.65

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Text::CSV_XS to a version that resolves this vulnerability.

    Fixed in 1.65

Event History

Oct 16, 2026
CVE Published
via MITRE·10:08 PM
Data Sourced
via MITRE·10:08 PM
RemedyDescriptionWeakness

Frequently Asked Questions

1

What input and parser settings are required to trigger the incorrect field value?

The input must end with a separator followed by a lone carriage return, such as parse("a,\r"). With binary enabled, the empty final field is returned as a byte 0xFF even though that byte was not present in the input.

2

Could normal line-by-line processing of CSV files encounter this condition?

Yes. A CRLF file read one line at a time and then chomped can leave a lone CR when the final column is empty, causing the parser to return the unexpected byte in that column.

3

How does UTF-8 input change the impact?

For UTF-8-flagged input, the final field is returned as a UTF-8-flagged string containing the lone 0xFF byte. This produces malformed UTF-8.

4

Is the behavior the same when the final field is not empty?

No. With the same trailing lone CR condition but a non-empty final field, parsing is rejected as an error rather than returning the injected 0xFF byte.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203