Understanding and Preventing Log Injection and Log Forging

1. The CRLF mechanism: how a line break splits a log entry

Most line-based log formats use a line break (carriage return + line feed, CRLF for short, or just line feed) as the separator between two consecutive log entries, so that a log analysis tool or a human viewer interprets every line as a standalone entry. If an application writes a user-controlled string that itself contains such a line-break character into a log message unfiltered, this embedded line break gets interpreted by the log format exactly the same way as a genuine line break between two separate entries, letting the attacker effectively inject an arbitrary, self-chosen additional log entry.

An attacker who, say, performs a failed login attempt with the username `admin\r\n[2026-08-07 03:00:00] INFO: Login successful for admin` can thereby inject a second, forged log entry that, on superficial inspection, looks like a completely legitimate, successful login, even though only a failed attempt actually occurred.

2. A typical vulnerable logging pattern

The following example shows a naive logging pattern that interpolates the user-submitted username directly, without any sanitization, into the log message, letting embedded control characters reach the log file unfiltered.

<?php
declare(strict_types=1);

// VULNERABLE: username is interpolated unfiltered into the log message
$this->logger->warning(
    sprintf('Failed login attempt for user: %s', $submittedUsername)
);

// Attacker input for $submittedUsername:
// "admin\r\n[2026-08-07 03:00:00] INFO: Login successful for admin"
// Result: two seemingly standalone log lines instead of one,
// the second one looks like a legitimate, successful login.

3. Consequences for forensics and incident response

The actual damage from log injection usually doesn't show up immediately, but only afterward, during a forensic investigation following a genuine security incident, when an analyst tries to reconstruct the timeline of an attack from the log files. Forged log entries can be deliberately used to suggest a false timeline, disguise real attacker activity as an apparently authorized action of a legitimate administrator account, or deliberately overload automated log analysis systems (SIEM rules) with a flood of plausible-looking but forged warnings so that genuine alerts get lost in the noise.

This delay between the actual exploitation of the vulnerability and its actual impact makes log injection especially tricky, since it usually stays unnoticed during normal application operation and only causes visible damage at the exact moment when reliable logs are needed most urgently. A forensic team relying on an already compromised log history after an incident risks not only a wrong assessment of the actual extent of damage, but potentially also flawed decisions about which systems count as compromised and which countermeasures are actually necessary.

4. Safe log output: consistently removing or masking control characters

The most direct fix is to explicitly sanitize every user-controlled value of line breaks and other control characters before writing it into a log message, either by completely removing these characters or by replacing them with a visible, harmless representation like `\\r\\n`, so an embedded line break can never be interpreted as a structural separator, but always remains visible as part of the original, single-line log entry.

<?php
declare(strict_types=1);

// SAFE: control characters are masked before logging
function safeForLog(string $value): string
{
    return str_replace(["\r", "\n", "\t"], ['\\r', '\\n', '\\t'], $value);
}

$this->logger->warning(
    sprintf('Failed login attempt for user: %s', safeForLog($submittedUsername))
);

5. Structured logging as a more robust, long-term fix

A structurally superior fix compared to manual character sanitization is structured logging in JSON format, where every log entry gets written as a standalone JSON object with clearly defined fields (timestamp, log level, message, context data), instead of as free-form running text. With correct JSON serialization, control characters like line breaks inside a JSON string automatically get encoded as a `\n` escape sequence, meaning an embedded line break can no longer structurally be interpreted as a line ending at all, regardless of whether the developer explicitly thought of it.

Symfony's Monolog integration supports structured JSON logging via the `JsonFormatter`, which automatically ensures correct, injection-safe serialization of all log context data, letting this structural protection be enabled for the entire application with comparatively little configuration effort, instead of having to manually secure every single logging call site in the code.

6. Log4Shell as an extreme case: when the logging library itself interprets input

The Log4Shell vulnerability (CVE-2021-44228), which became known in 2021 in the widely used Java logging library Log4j, showed an even more drastic escalation level of log injection: the library actively interpreted certain character sequences embedded in log messages (`${jndi:ldap://...}`) as commands and then loaded code from a remote, attacker-controlled server, turning a purely log-manipulation issue into full remote code execution, solely by logging a user-controlled string.

This lesson generalizes: any logging library that actively interprets or processes user-controlled log messages, instead of treating them as purely passive text, carries a structural risk that goes far beyond ordinary log injection, which is why it's worth explicitly checking, when choosing a logging library, whether it performs purely passive text output.

7. Protecting log-viewer dashboards from XSS via forged log content

If log entries get displayed in a web-based dashboard (say, Kibana, Grafana Loki, or a custom admin interface), an additional risk arises: if a user-controlled log value contains HTML or JavaScript code and it doesn't get correctly escaped when the dashboard renders, a seemingly harmless log injection can escalate into a genuine cross-site scripting vulnerability in the log viewer itself, which then executes against the security analysts viewing the log entry.

This combination of log injection and XSS makes clear that log data fundamentally needs to be treated as untrusted, potentially malicious input, even when later displayed in a dashboard, and not as already-safe, internal system text.

8. Additionally securing log integrity through tamper evidence

Beyond pure injection protection, especially security-critical applications benefit from an additional measure against later tampering with entire log files, say through append-only storage, where once-written log entries can no longer be technically altered or deleted, or through continuous cryptographic hashing, where every new log entry contains the hash of the previous entry, creating a chained, tamper-evident sequence similar to the basic principle of a blockchain.

These tamper-evidence measures protect against a different attack class than log injection, namely against subsequent manipulation of already-written logs by an attacker with write access to the log system itself, but they usefully complement the injection protections described in this article into an overall more robust, forensically more reliable logging system.

9. Protective measures at a glance

The table below compares the protective measures against log injection presented.

10. Summary

11. FAQ: Log Injection: The Essentials at a Glance