Log injection happens when untrusted input is written into a log without neutralizing special characters, so an attacker can add fake lines or break parsing. Prevent it by logging in a structured format that encodes values, and by sanitizing carriage returns, line feeds and delimiters.
How it works
CWE-117, Improper Output Neutralization for Logs, describes a product that builds log messages from external input without handling special elements. The input then alters the log when it is written. An attacker who controls logged data may add fake entries or change how existing entries are parsed.
The classic example: a login page logs "failed login for user" followed by whatever the user typed. If the user types a name, a newline and a convincing line such as a successful admin login, the log now contains a line the application never wrote. The CWE page uses a similar case, where encoded newline characters produce a fabricated "User logged out" entry.
Why it matters
The CWE entry lists the consequences:
- forged entries that implicate others or skew statistics, and that can cover an attacker's tracks
- corrupted formatting that makes automatic processing unreliable
- in some cases, content that exploits vulnerabilities in log processing tools
Logs are evidence. A line you cannot trust is worse than a missing line, since it can mislead an investigation.
Defenses
- Use structured logging. When each event is a JSON object written by a library, a newline inside a value is escaped and cannot start a new event.
- Encode for the output format. CWE advises choosing an encoding that downstream log readers handle, so characters are not interpreted differently than intended.
- Sanitize carriage return, line feed and delimiter characters in event data, as the OWASP logging guidance directs.
- Validate input with an accept-known-good approach where you can. CWE says denylists are useful mainly for detecting attacks.
- Canonicalize first. Decode and normalize input before validating it, and avoid decoding the same input twice.
When a field is malformed
OWASP suggests that if a field is malformed, replace or omit that field and record the validation failure, instead of throwing away the whole event. That way you keep the evidence that someone tried something odd.
Do not forget the readers
Log viewers, terminals and spreadsheets are readers too. Control characters can move a terminal cursor, and values starting with certain characters can be treated as formulas when exported to a spreadsheet. Treat any log export for human use as a place to sanitize again.
A quick test
Send a request whose user agent, username and query string contain an encoded newline followed by a fake log line. Search your logs for the fake line. If it appears as its own event, you have the problem.
Quick check
Does JSON logging fully solve this?
It removes the newline trick for the log file itself. You still need to treat values as untrusted when they are displayed, exported or fed into other tools.
Should I log the raw payload of a suspicious request?
Often a rule ID or category is enough, and it avoids storing attacker content. OWASP's vocabulary takes that approach for some events.
Sources
- CWE-117: Improper Output Neutralization for Logs
- OWASP Logging Cheat Sheet
- OWASP Logging Vocabulary Cheat Sheet
Last reviewed: 19 October 2026.
