CWE-143 applies when the product receives input from an upstream component but does not neutralize, or incorrectly neutralizes, special elements that could be read as record delimiters by a downstream component. It sits under CWE-140 and is language-neutral.
How it happens
In many flat files, one line is one record, so a carriage return or line feed marks the boundary. If a user supplied value is written to such a file and contains a line break, the rest of the value becomes a brand new record.
MITRE's observed examples fit this exactly.
- CVE-2004-1982: carriage returns in a subject field allow adding new records to a data file.
- CVE-2001-0527: an attacker inserts carriage returns and pipe field separator characters to add a new user with privileges.
// Vulnerable: subject is written as one line of a data file
file_put_contents("tickets.txt", $subject . "|open\n", FILE_APPEND);
A subject such as hello|open followed by a line break and fake|closed writes two records, and the second one was authored by the attacker.
What an attacker gains
MITRE lists an integrity impact with an unexpected state. Practical results are forged records, new accounts or changed status values, depending on what the file holds.
How to find it
- Identify files and streams where one line equals one record.
- Submit values containing CR, LF and CRLF in every field written to them, then read the file.
- Review log and audit writers too, since forged lines damage investigations.
How to fix it
- Write records through a library that quotes embedded newlines, or use a database.
- Strip or reject CR and LF in fields where multi-line text is not needed.
- Encode line breaks, for example as an escape sequence, if they must be preserved.
- Do not store security decisions, such as roles, in files that user data is appended to.
Quick check
Which characters should you watch for?
Carriage return and line feed, alone or together, in any value written to a line-based file.
