Log injection happens when an application writes untrusted input into a log without neutralizing special characters, so an attacker can forge entries, break parsers or hide activity. Prevent it by encoding values for the output format, validating input, and using structured logging instead of string concatenation.
What it looks like
Suppose a login handler writes this line:
2026-10-19T10:02:11Z INFO login failed for user: USERNAME
If an attacker submits a username that contains a line break followed by text shaped like another log line, the log now contains a forged entry that looks real, such as a successful login for an administrator. Anyone reading the file, or any script parsing it line by line, sees an event that never happened.
MITRE's CWE-117 describes this class as improper output neutralization for logs. Consequences it lists: fake entries that hide activity, skew statistics or make it appear another party acted, logs that automated tools cannot use, and injected content that exploits weaknesses in log processing software.
Where it bites
- Line oriented files. One event per line is easy to forge with a newline.
- Delimited formats. Commas, pipes and tabs inside a value shift every later column.
- Web based log viewers. Unescaped values can be rendered as markup in an admin console.
- Downstream tools. Parsers and enrichment scripts may behave unexpectedly on crafted values. Treat logs as untrusted input in every consumer, including AI assistants that summarize them, as in logs are untrusted input in SOC assistants.
How to prevent it
The OWASP Logging Cheat Sheet says to sanitize all event data, including carriage return, line feed and delimiter characters, to encode data correctly for the output format, and to validate untrusted event data before logging. It adds two practical points: replace malformed fields rather than discarding the whole event, and make sure logging failures do not crash the application or leak information.
CWE-117 recommends accepting only known good input, decoding and canonicalizing before validating without decoding twice, and specifying an output encoding such as UTF-8 so mismatches do not let special characters slip through.
In code, the habits are:
- Use structured logging. A JSON logger escapes quotes and newlines inside values for you. Never build the line with string concatenation.
- Pass values as fields, not inside the message template.
- Bound the length of user-controlled fields.
- Neutralize control characters in any plain text sinks you cannot avoid.
- Encode at display time in any web viewer.
Test for it
Add a test that logs a value containing a newline and a fake log prefix, then asserts the output is still a single event. Run it against every logging path, including error handlers, which are often written last.
Related risk: logging attacker controlled data in the first place
Some libraries have interpreted log message content as instructions. That is a different failure from forged lines, and a good reason to keep logging libraries current. Our dependency inventory demo shows how to see which libraries you actually ship.
Quick check
Is escaping only newlines enough?
No. Delimiters, quotes and encoding mismatches also matter. Encode for the specific output format rather than blocking a short list of characters.
Does JSON logging remove the problem?
It removes most line forging, since the encoder escapes control characters. You still need to protect viewers and downstream tools.
Sources
Last reviewed: 19 October 2026.
