Log forging is the manipulation of application or system log entries so they contain misleading, altered or attacker-controlled content. It usually works by injecting newline characters, control characters or crafted fields into logged input, which can hide activity, corrupt audit trails or mislead incident responders.
What log forging means in practice
Log forging is an input-handling problem that turns a log stream into a manipulable record. The attacker is not trying to break logging outright, but to make entries look different from what the application actually observed.
The risk comes from how many downstream decisions depend on logs, including investigations, alert triage, audit review and incident reconstruction. Once the record is polluted, defenders may be reading a story the attacker helped write.
How log forging works
The usual technique is simple: place newline characters, carriage returns, delimiters or other control bytes into a field that later gets written to a log. If the logging layer does not escape or normalise that content, one request can become several apparent events.
Some implementations are vulnerable because they treat log output as plain text rather than structured data. That makes it possible for attacker-controlled fields to break the intended format, introduce fake severity labels, or make one action appear as many separate entries.
Why forged logs are dangerous
Log forging can hide malicious activity by burying the real event among decoy lines, overwriting context, or making an investigation search miss the right record. It can also create false confidence by making normal activity appear suspicious, which wastes analyst time and can trigger the wrong response.
In regulated or high-assurance environments, corrupted logs can undermine auditability and non-repudiation. If logs are used as evidence of access, change, or transaction history, forged entries can weaken trust in the entire control environment.
Where to look and how to prevent it
The most effective defences are to treat all log-bound input as untrusted, preserve structured fields, and escape or encode control characters before writing records. Logging pipelines should also keep a clear separation between user-supplied data and metadata such as timestamps, severity and source identifiers.
Detection is still important because prevention is rarely perfect. Review log parsers, SIEM ingestion rules and alerting logic for format confusion, unexpected line breaks and suspiciously duplicated or truncated events. When investigating, compare application traces, reverse proxy logs and host telemetry so a forged application log does not become the only version of events.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V16 — Security Logging and Error Handling | Log forging directly affects how applications record and protect security logs. |
| Recommendation — Validate log output handling so attacker-controlled fields cannot corrupt records or error traces. | ||
| NIST SP 800-53 Rev 5 | AU-3 — Content of Audit Records | Audit records must capture reliable, complete content that is not attacker-shaped. |
| AU-9 — Protection of Audit Information | Forged entries weaken audit information integrity and its evidentiary value. | |
| SI-11 — Error Handling | Input-driven log corruption often arises from unsafe handling of control characters and error text. | |
| Recommendation — Define audit record fields so logs preserve trustworthy event content and provenance. Protect audit logs against tampering so stored records remain trustworthy for review and investigation. Sanitise error and input handling so unsafe characters do not alter downstream log structure. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Log forging is a direct audit-log integrity issue covered by operational logging safeguards. |
| Recommendation — Harden log collection and retention so attacker-controlled content cannot distort audit trails. | ||
| MITRE ATT&CK | T1565 — Data Manipulation | Log forging is a form of manipulating data to alter the integrity of recorded information. |
| Recommendation — Map log-forging behavior to data-manipulation detections and investigate integrity anomalies. | ||
Practitioner Guidance
Why practitioners should care: Log forging is often missed because it looks like a logging-quality issue, but it is really a trust issue. If an attacker can shape the record, they can degrade detection, distort forensics and complicate legal or compliance review.
What to watch for: Any place where raw request data, usernames, headers or error text is written directly into text logs deserves scrutiny. The highest-risk cases are systems that parse logs downstream, because a single malformed field can affect both storage and analysis.
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 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org