Log poisoning is the act of writing attacker-controlled content into logs so it later becomes dangerous when viewed, parsed, or included in another context. It can lead to script execution, command injection, or log tampering if log data is reused unsafely. Sanitize logged input and keep logs separate from executable contexts.
How Log Poisoning Works
Log poisoning happens when untrusted input is written into logs in a way that preserves the attacker’s payload rather than neutralizing it. The risk appears later, when a person, parser, dashboard, SIEM rule, export job, or downstream application treats that log entry as active content instead of inert text.
This is a context-confusion problem more than a logging problem. A message that is harmless while stored as plain text can become dangerous if it is rendered into HTML, passed into a shell, interpolated into a template, or copied into another system that performs its own parsing.
The term is often associated with web application attacks, because application logs commonly collect request headers, parameters, user agents, referrers, and error details. NHIMG’s Web Application Attacks Guide covers the broader injection patterns that make this class of issue easier to recognise.
Why It Is Dangerous
The danger is not the presence of attacker-controlled text by itself, but the moment that text crosses into a second context. If a log viewer renders HTML without escaping, a stored payload can trigger script execution. If an export pipeline feeds logs into a command or report generator, the same content can become command injection or content manipulation.
Log poisoning is also a trust issue. Logs are often treated as evidence, telemetry, or a source of truth for incident response. Once attacker-controlled content is mixed with genuine security events, analysts may misread what happened, automated detections may be confused, and later investigations may rely on tampered records.
In practice, the blast radius depends on where the log data goes after collection. Simple append-only storage is much safer than systems that transform logs into HTML dashboards, searchable reports, ticket comments, or alert payloads.
Common Failure Patterns
Most failures come from unsafe reuse rather than from logging itself. The same raw entry may be safe in a flat text file but unsafe once copied into a browser, terminal, email template, JSON document, or administrative console.
Another common failure is inconsistent encoding. Input may be sanitised for one sink but not for another, or escaped on write but decoded on read. That creates a gap where the payload survives in storage and becomes active only after later processing.
Logs are especially exposed when they are built from rich input such as stack traces, request metadata, exception messages, and proxy headers. Those fields can carry delimiters, markup, or control characters that alter how the downstream tool interprets the record.
Defensive Design Principles
Safe handling starts with treating logs as data, not as executable or display-ready content. Capture only the minimum necessary detail, keep the original record separate from any formatted presentation, and apply output encoding at the point where the log is rendered or reused.
It also helps to isolate the logging pipeline from other execution paths. Log storage, search, reporting, and alerting should not share assumptions about parsing, templating, or command execution. That separation reduces the chance that one unsafe consumer turns a harmless record into an exploit.
For defenders, the most useful mindset is to assume that anything written into a log can be attacker-influenced. The control goal is not merely to record events, but to preserve their meaning without letting the contents change the behaviour of the systems that read them.
Risk and Threat Considerations
Log poisoning becomes material when logs are reused in dashboards, support workflows, incident response, or automation that trusts their contents. The threat is strongest where a log entry can move from passive record to active input without a fresh validation step.
Failure mechanism: An attacker injects payloads that survive logging, then waits for a later consumer to render, parse, index, or execute the entry in a more dangerous context.
Impact: The result can be cross-site scripting, command injection, log tampering, analyst deception, or corrupted evidence that weakens detection and response.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Log poisoning affects how audit records are stored, reviewed, and protected from tampering. |
| Recommendation — Protect audit logs from alteration and validate that log consumers do not execute or misparse log content. | ||
| OWASP ASVS | V16 — Security Logging and Error Handling | This term concerns unsafe logging, log integrity, and the handling of attacker-controlled log content. |
| V1 — Encoding and Sanitization | Safe handling of attacker-controlled log content depends on correct encoding before display or reuse. | |
| Recommendation — Escape log content at presentation time and keep logging output separate from executable contexts. Apply context-appropriate output encoding wherever log entries are rendered or transformed. | ||
| NIST SP 800-53 Rev 5 | AU-9 — Protection of Audit Information | Log poisoning can undermine the confidentiality, integrity, and trustworthiness of audit information. |
| SI-10 — Information Input Validation | The attack starts with untrusted input entering logging and then being reused unsafely. | |
| Recommendation — Preserve audit information integrity and restrict log consumers so attacker-controlled entries cannot alter meaning. Validate and sanitise untrusted input before it is logged or repurposed by downstream systems. | ||
Practitioner Guidance
What to watch for: Review every place where logs are displayed, exported, or repurposed. If a log can appear in HTML, shell output, alert text, or a report generator, it needs context-appropriate escaping at that sink rather than trust in the original write path.
Governance implication: Teams should own both the log producer and the log consumer paths. A log format is only safe if every downstream use treats it as untrusted input, including security tooling.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org