CVE-2026-5078

What it actually does

CVE-2026-5078 is an improper input neutralization flaw in the morgan Node.js HTTP request logging middleware. When a logging format includes the :remote-user token, morgan extracts the username from an HTTP Basic Authorization header and writes it to the access log without neutralizing carriage return or line feed characters. An unauthenticated remote attacker can send a crafted Authorization: Basic header whose decoded username contains CR or LF bytes, causing morgan to emit attacker-controlled extra log lines. This does not directly allow code execution or data disclosure, but it compromises log integrity, can break one-request-per-line parsing assumptions, and may mislead downstream SIEM, observability, audit, or incident-response workflows. The built-in combined, common, default, and short formats are affected, along with any custom morgan format that references :remote-user. Affected versions are morgan 1.2.0 through 1.10.1; version 1.11.0 neutralizes the control characters.

Why it matters to the business

Organizations using affected morgan versions may have web access logs that can be forged by unauthenticated internet traffic. This can reduce confidence in audit trails, obscure malicious activity, create false positives or false attribution in monitoring tools, and disrupt log pipelines that assume each request maps to one log line. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV or associated with ransomware campaigns, but the vulnerability is easy to trigger remotely and should be fixed wherever morgan logs are used for security monitoring, compliance evidence, abuse investigations, or operational analytics.

How an attack unfolds

An attacker identifies an application using morgan access logging with a format that includes :remote-user, such as the common, combined, default, or short format. The attacker sends an HTTP request containing an Authorization: Basic header where the Base64-decoded username includes carriage return or line feed characters followed by attacker-chosen text. Morgan decodes the Basic auth username and writes it directly into the log entry through the :remote-user token. Because the control characters are not neutralized in affected versions, the resulting access log can contain additional forged lines or malformed records. Downstream systems that ingest the logs may treat those forged lines as real events, potentially hiding attacker activity, polluting dashboards, triggering misleading alerts, or undermining forensic timelines.

How to fix it

Upgrade morgan to version 1.11.0 or later. Affected versions are 1.2.0 through 1.10.1. If immediate upgrade is not possible, change the morgan format string so it does not include :remote-user; this includes avoiding the built-in combined, common, default, and short formats until patched. After upgrading, rebuild and redeploy applications so the fixed dependency is actually present in runtime artifacts, including containers, serverless bundles, and packaged Node.js deployments. If dependency lockfiles are used, update and commit the lockfile so morgan resolves to 1.11.0 or later.

How to confirm the fix worked

Confirm exposure by inspecting package manifests and lockfiles for morgan versions from 1.2.0 through 1.10.1 and by reviewing application logging configuration for :remote-user or built-in morgan formats such as combined, common, default, or short. Confirm remediation by verifying that the deployed runtime resolves morgan to 1.11.0 or later, not only that package.json permits it. As a functional validation, send a controlled test request with a Basic auth username containing encoded CR/LF characters in a non-production environment and verify that the resulting access log does not create additional log lines or malformed records. Also verify that log ingestion pipelines preserve a one-request-per-line structure after the patched deployment.

Typical attack path

1. Find a Node.js application that uses morgan for HTTP access logging.
2. Determine or assume that the application uses a built-in morgan format such as combined, common, default, or short, or a custom format containing :remote-user.
3. Craft an HTTP request with an Authorization: Basic header whose decoded username contains CR and/or LF characters followed by attacker-controlled log text.
4. Send the crafted request without needing authentication or user interaction.
5. Morgan writes the decoded username into the access log without neutralizing the control characters.
6. The access log contains injected or malformed lines that may be ingested by log forwarders, SIEM rules, dashboards, or audit tooling as if they were legitimate events.

How to detect it

To assess prior exploitation, review HTTP access logs, reverse proxy logs, WAF logs, application logs, and raw request telemetry for requests containing Authorization: Basic headers that correspond to malformed or split morgan log entries. Focus on time periods where access logs show broken one-request-per-line structure, unexpected extra lines, impossible timestamps, inconsistent source IPs, unusual usernames, or records that do not match the normal morgan format. Compare upstream proxy/WAF request counts with application access-log line counts; injected lines may cause the application log to contain more apparent events than upstream telemetry. Where raw headers are retained, decode Basic credentials from suspicious requests and look for carriage return or line feed bytes in the username portion. In SIEM or log pipelines, search for parse failures, multiline access-log events, fields shifted into the wrong columns, or entries containing attacker-like strings near requests with Authorization: Basic. Because the exploit changes log content rather than producing a unique file or process artifact, detection relies primarily on log consistency checks and inspection of Basic auth request headers and malformed morgan output.

• Authorization: Basic
• morgan format ":remote-user"
• morgan('combined'
• morgan('common'
• morgan('default'
• morgan('short'
• morgan("combined"
• morgan("common"
• morgan("default"
• morgan("short"
• node_modules/morgan/package.json
• "morgan": "1.10.1"
• "morgan": "1.10.0"
• "morgan": "1.9.
• "morgan": "1.8.
• "morgan": "1.7.
• "morgan": "1.6.
• "morgan": "1.5.
• "morgan": "1.4.
• "morgan": "1.3.
• "morgan": "1.2.

What your security team should do

• Inventory applications and services that depend on morgan, including transitive and bundled copies in containers or serverless artifacts.
• Prioritize upgrades for internet-facing services, services whose access logs feed SIEM or compliance workflows, and services using Basic auth or morgan formats that include :remote-user.
• Upgrade morgan to 1.11.0 or later and redeploy affected applications from clean builds.
• If upgrading must be delayed, remove :remote-user from the morgan format and avoid the built-in combined, common, default, and short formats until patched.
• Search historical access logs for evidence of log-line injection, malformed records, embedded CR/LF effects, or suspicious Authorization: Basic requests around unexpected log anomalies.
• Review SIEM parsers and alert logic for assumptions that each access-log line is trustworthy and maps to exactly one HTTP request.
• Add regression tests or dependency policy checks to prevent reintroduction of affected morgan versions.