CVE-2026-5078 in morgan
Summary
by MITRE • 06/03/2026
Impact: The morgan logging middleware's :remote-user token extracts the Basic auth username from the Authorization request header and writes it to the log stream without neutralizing control characters. An unauthenticated attacker can send a crafted Authorization Basic header containing CR or LF bytes to inject forged log lines, breaking the one-request-per-line structure of access logs and enabling log forgery against downstream log consumers. The built-in combined, common, default, and short formats are affected, as well as any custom format that references :remote-user. Affected versions: morgan 1.2.0 through 1.10.1. Patches: upgrade to morgan 1.11.0, which neutralizes control characters in the :remote-user token output. Workarounds: use a custom format string that does not include :remote-user.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 06/03/2026
The vulnerability in morgan logging middleware represents a critical log injection flaw that undermines the integrity of application logging systems. This issue stems from the improper handling of control characters within the Basic authentication username extracted from the Authorization header. The :remote-user token implementation fails to sanitize input containing carriage return and line feed characters, creating a pathway for malicious actors to manipulate log output structures. The vulnerability affects all versions from 1.2.0 through 1.10.1, making it a widespread concern across numerous applications that rely on this popular logging middleware component.
The technical exploitation of this vulnerability occurs when an unauthenticated attacker crafts a malicious Authorization header containing control characters such as carriage return CR (0x0d) or line feed LF (0x0a). When the morgan middleware processes this header, it directly writes these unescaped characters to the log stream, allowing attackers to inject arbitrary log entries. This control character injection breaks the fundamental one-request-per-line structure that logging systems depend upon, enabling attackers to forge log entries that appear legitimate to downstream log consumers. The impact extends beyond simple log corruption to potentially enable advanced attack techniques such as log poisoning, which can interfere with security monitoring systems and forensic analysis.
The operational impact of this vulnerability is significant for organizations relying on morgan for application logging. Attackers can exploit this weakness to create false log entries that may obscure legitimate activities or inject malicious content into log streams. This log forgery capability can undermine security operations by making it difficult to distinguish between authentic and forged log entries, potentially allowing malicious activities to go undetected. The vulnerability affects built-in log formats including combined, common, default, and short formats, as well as any custom formats that reference the :remote-user token, meaning the attack surface is extensive across typical application deployments. This flaw directly relates to CWE-117, which addresses improper output neutralization for logs, and aligns with ATT&CK technique T1070.002 for clearing logs, as the manipulation can effectively obscure attack traces.
Organizations can mitigate this vulnerability through several approaches beginning with upgrading to morgan version 1.11.0, which implements proper neutralization of control characters in the :remote-user token output. This patch addresses the root cause by sanitizing input before log generation, preventing the injection of malicious control sequences. Alternative workarounds include implementing custom log formats that exclude the :remote-user token reference, effectively removing the attack vector while maintaining other logging functionality. Security teams should also consider implementing additional log monitoring and validation mechanisms to detect anomalous log patterns that might indicate exploitation attempts. The vulnerability demonstrates the importance of proper input sanitization in logging components and highlights the need for comprehensive security testing of middleware components that handle user-provided data in logging contexts.