Log injection is a flaw where attacker-controlled input is written into logs without proper sanitisation. The result can be forged log entries, misleading audit trails, and corrupted incident evidence. In practice, it weakens detection and response because analysts can no longer trust what the log stream is showing.
Expanded Definition
Log injection is not just a logging bug; it is an integrity problem in the record layer that turns attacker-controlled text into something operators may mistake for trusted telemetry. The core issue is that log output is being treated as a safe sink for untrusted input, so delimiters, line breaks, escape sequences, or structured-field values can alter how the record is parsed or displayed. That can produce forged entries, split one event into many, or hide the real sequence of actions.
In practice, the boundary that matters is between recording an event and preserving its meaning. A system may still “log” the event, but if the record can be reshaped by user input, the audit trail is no longer reliable evidence. Guidance across secure logging practice is consistent on this point: log data must be treated as untrusted content, even when it comes from internal applications.
The most common misunderstanding is that log injection only matters when an attacker can directly view the logs. The real risk is broader: once the log stream is compromised, correlation, triage, compliance review, and later forensic reconstruction all become less trustworthy.
Examples and Use Cases
Log injection appears wherever applications serialize user-controlled data into access logs, application logs, security logs, or event pipelines.
- A web form accepts a username containing line breaks, and the resulting log entry is split into multiple records that look like separate actions.
- An API request places crafted text into a header or parameter that later appears in JSON logs, changing the structure of the event payload.
- A support portal records free-text fields without escaping, allowing an attacker to insert content that resembles an administrator action or a system error.
- A centralized logging pipeline ingests records from multiple services, and one malformed event breaks parsing for downstream analytics or alerting.
- A machine-generated audit trail includes external input such as job names, agent prompts, or resource labels, and the untrusted value corrupts the trace of what actually happened.
The tradeoff is usually between readability and safety. Human-friendly log formats are easier to scan, but they are also easier to distort if escaping, canonicalisation, or strict serialization is weak. Structured logging reduces that risk only when the schema is enforced consistently from source to sink.
Security Implications
When log injection succeeds, the immediate failure is loss of log integrity. Analysts may chase a false sequence of events, miss the real source of an action, or trust a record that was partially fabricated by the attacker. That can delay incident response, distort alert investigation, and weaken evidence quality for compliance or legal review.
Operationally, the damage often shows up as confusion rather than an obvious outage. A record may appear to show an internal admin action, a clean session termination, or an error that never really occurred. In security operations, that can break correlation across SIEM rules, case management, and timeline reconstruction because the evidence stream itself has been contaminated.
Forensic value drops further when logs are used as the primary source for proving what happened. If integrity cannot be trusted, the organisation may need to rely on weaker secondary sources such as application traces, database records, or network telemetry. The practitioner observation is simple: a logging flaw is not “just output formatting” when it changes what investigators believe occurred.
Domain and Governance Relevance
Log injection matters in cybersecurity because logs are part of the control plane for detection, response, and accountability. A tampered audit trail does not merely affect readability; it undermines the organisation’s ability to validate events, investigate incidents, and demonstrate that controls worked as intended. That is why secure logging is a governance issue as well as a technical one.
Where the term intersects with identity and privileged activity, the consequence becomes sharper. If logs capture authentication events, admin actions, or non-human workflows, injected content can obscure which principal acted, which request was legitimate, and whether a machine or service account was abused. In that context, trustworthy logging supports both access governance and post-incident attribution.
For systems built around automation or delegated execution, record integrity is part of operational assurance. If logs cannot be trusted, then abnormal agent behaviour, credential misuse, and failed control enforcement may be much harder to distinguish from normal activity. In short, the term sits at the point where observability becomes evidence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 8 — Audit Log Management | Log injection weakens the integrity and usefulness of audit records. |
| 13 — Network Monitoring and Defense | Corrupted logs can undermine monitoring pipelines and alert fidelity. | |
| Recommendation — Apply Control 8 to protect log integrity with validated input handling and tamper-resistant storage. Use Control 13 to validate that monitoring inputs remain parseable and trustworthy across the pipeline. | ||
| NIST CSF 2.0 | DE.AE-3 — Anomalies and Events Are Analyzed | Injected logs distort event analysis and can mislead detection workflows. |
| PR.PT-1 — Audit/Log Records Are Determined, Documented, Implemented, and Reviewed | The term directly concerns trustworthy logging and record handling. | |
| Recommendation — Use DE.AE-3 to ensure suspicious log patterns are normalized and investigated before analysis. Apply PR.PT-1 to define, protect, and review log-record handling so untrusted input cannot reshape evidence. | ||
| MITRE ATT&CK | T1070.001 — Clear Windows Event Logs | Log injection supports defense evasion by corrupting or obscuring event records. |
| T1562.002 — Impair Defenses: Disable Windows Event Logging | Injected log content can degrade detection and obscure defensive visibility. | |
| Recommendation — Map suspicious log corruption activity to T1070.001 and hunt for evidence of audit-trail tampering. Treat degraded logging visibility as defense impairment and verify whether records were intentionally manipulated. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
