How CR/LF Injection happens in Node.js http-proxy-middleware and how to fix it

Introduction

In a Node.js application using Express 5.x with http-proxy-middleware for request proxying, Trivy flagged a high-severity vulnerability in package-lock.json: the pinned dependency http-proxy-middleware@3.0.5 was susceptible to CVE-2026-55603, a data integrity compromise via CR/LF injection. This vulnerability allows an attacker to inject carriage return (\r) and line feed (\n) characters into proxied HTTP requests, potentially splitting headers, injecting malicious content, or poisoning caches.

The package.json declared the dependency as "http-proxy-middleware": "^3.0.5", and the lockfile resolved it to exactly version 3.0.5—a version that did not sanitize CRLF sequences in user-controlled input before forwarding requests to upstream servers. For any developer running a reverse proxy or API gateway with this middleware, this represents a direct path from user input to protocol-level manipulation.

The Vulnerability Explained

What is CRLF Injection?

HTTP uses \r\n (CRLF) sequences to separate headers from each other and from the body. When user-controlled data—such as URL paths, query parameters, or custom headers—is incorporated into a proxied HTTP request without stripping these characters, an attacker can:

1. Inject arbitrary HTTP headers into the proxied request
2. Split the HTTP response, creating a second fabricated response
3. Poison web caches with malicious content
4. Bypass security controls that rely on header integrity

How This Affected http-proxy-middleware 3.0.5

The http-proxy-middleware package acts as a bridge between an Express (or similar) application and a backend target server. When configured, it takes incoming requests and forwards them to the target. In version 3.0.5, the middleware did not adequately validate or sanitize input that could contain CRLF sequences before constructing the outbound proxy request.

Consider a typical setup:

const { createProxyMiddleware } = require('http-proxy-middleware');
const express = require('express');

const app = express();
app.use('/api', createProxyMiddleware({
  target: 'http://backend-service:3000',
  changeOrigin: true,
}));

An attacker could craft a request like:

GET /api/resource%0d%0aX-Injected-Header:%20malicious-value HTTP/1.1
Host: vulnerable-app.com

When http-proxy-middleware@3.0.5 forwarded this request, the %0d%0a (URL-decoded \r\n) could be interpreted as a header boundary, injecting X-Injected-Header: malicious-value into the proxied request sent to the backend. This compromises the integrity of the communication between the proxy and the upstream server.

Real-World Attack Scenario

Imagine this application proxies authentication requests to a backend identity service. An attacker could inject headers like:

GET /api/auth%0d%0aX-Forwarded-For:%20127.0.0.1%0d%0aX-Admin:%20true HTTP/1.1

This could cause the backend to see X-Forwarded-For: 127.0.0.1 and X-Admin: true as legitimate headers from the proxy, potentially bypassing IP-based access controls or elevating privileges.

The Fix

The fix upgrades http-proxy-middleware from version 3.0.5 to 3.0.7, which introduces internal sanitization of CRLF sequences in request data before forwarding.

Before (Vulnerable)

In package.json:

{
  "dependencies": {
    "express": "^5.1.0",
    "http-proxy-middleware": "^3.0.5"
  }
}

In package-lock.json:

"node_modules/http-proxy-middleware": {
  "version": "3.0.5",
  "resolved": "https://registry.npmjs.org/http-proxy-middleware/-/http-proxy-middleware-3.0.5.tgz",
  "integrity": "sha512-GLZZm1X38BPY4lkXA01jhwxvDoOkkXqjgVyUzVxiEK4iuRu03PZoYHhHRwxnfhQMDuaxi3vVri0YgSro/1oWqg=="
}

After (Fixed)

In package.json:

{
  "dependencies": {
    "express": "^5.1.0",
    "http-proxy-middleware": "^3.0.7"
  }
}

In package-lock.json:

"node_modules/http-proxy-middleware": {
  "version": "3.0.7",
  "resolved": "https://registry.npmjs.org/http-proxy-middleware/-/http-proxy-middleware-3.0.7.tgz",
  "integrity": "sha512-iwbQltVlx8bCrqePUM8C+hllHvdawVhQJaLrj1X7qllkvFQdXFsr16pW/mo9+JDVjN+QO2XUx9jd8SmoFkE5qw=="
}

What Changed Internally

Version 3.0.7 of http-proxy-middleware adds validation logic that strips or rejects \r and \n characters from user-influenced data before it is incorporated into the outbound proxy request. This ensures that even if an attacker supplies CRLF sequences in URLs, query strings, or headers, they cannot manipulate the HTTP protocol structure of the proxied request.

The engine requirement also shifted subtly from ^14.15.0 to ^14.18.0, indicating the fix leverages Node.js APIs available in 14.18+ for safer header handling.

Why Both Files Changed

• package.json: Updates the declared dependency range to require at minimum version 3.0.7
• package-lock.json: Pins the exact resolved version, integrity hash, and registry URL to ensure reproducible builds with the patched version

Prevention & Best Practices

1. Keep Dependencies Updated

Use automated dependency scanning tools (Trivy, Snyk, npm audit) in your CI/CD pipeline to catch vulnerable versions early:

npm audit
# or
trivy fs --scanners vuln .

2. Validate Input at the Edge

Even with patched middleware, defense-in-depth means validating input before it reaches the proxy:

app.use('/api', (req, res, next) => {
  // Reject requests with CRLF in the URL
  if (/[\r\n]/.test(decodeURIComponent(req.originalUrl))) {
    return res.status(400).send('Invalid request');
  }
  next();
});

3. Use Allowlists for Headers

When configuring proxy middleware, explicitly define which headers are forwarded rather than passing everything through:

createProxyMiddleware({
  target: 'http://backend:3000',
  headers: { 'X-Custom': 'safe-value' },
  onProxyReq: (proxyReq, req) => {
    // Remove potentially dangerous headers
    proxyReq.removeHeader('x-forwarded-for');
  }
});

4. Pin Dependencies with Lockfiles

Always commit your package-lock.json and use npm ci in production builds to ensure you get exactly the versions you tested.

5. Monitor for CVEs in Transitive Dependencies

http-proxy-middleware depends on http-proxy, micromatch, and other packages. A vulnerability in any transitive dependency can affect your application.

Key Takeaways

• http-proxy-middleware 3.0.5 did not sanitize CRLF characters in user-controlled input before constructing proxied HTTP requests, enabling header injection attacks
• Upgrading from 3.0.5 to 3.0.7 is the minimum fix—the ^3.0.7 semver range in package.json ensures future patch versions are also accepted
• CRLF injection in proxy middleware is particularly dangerous because it operates at the protocol level between services, often behind WAFs and other perimeter defenses
• The lockfile integrity hash change (sha512-GLZZm... → sha512-iwbQ...) confirms the actual binary content of the package changed, not just metadata
• Defense-in-depth matters: even with the patched middleware, adding input validation at the application layer provides an additional safety net against similar future vulnerabilities

How Orbis AppSec Detected This

• Source: User-controlled HTTP request data (URL path, query parameters, headers) entering the Express application
• Sink: http-proxy-middleware@3.0.5 proxy forwarding logic that constructs outbound HTTP requests to backend services without CRLF sanitization
• Missing control: No validation or stripping of \r\n (CR/LF) sequences in user input before incorporation into proxied HTTP requests
• CWE: CWE-93 (Improper Neutralization of CRLF Sequences in HTTP Headers)
• Fix: Upgraded http-proxy-middleware from 3.0.5 to 3.0.7 in both package.json and package-lock.json, which adds internal CRLF sanitization before proxying requests

Orbis AppSec automatically detected this vulnerability and opened a pull request with the fix. Try Orbis AppSec on your repositories to find and fix issues like this automatically.

Conclusion

CVE-2026-55603 demonstrates how a seemingly simple oversight—failing to strip two characters (\r and \n) from user input—can escalate into a high-severity vulnerability capable of compromising data integrity between services. For Node.js applications using http-proxy-middleware, the fix is straightforward: upgrade to version 3.0.7 or later. But the broader lesson is that any component sitting on the boundary between user input and HTTP protocol construction must be treated with extreme care. Automated dependency scanning, combined with defense-in-depth input validation, ensures that vulnerabilities like this are caught and remediated before they reach production.

References

• CWE-93: Improper Neutralization of CRLF Sequences in HTTP Headers
• OWASP HTTP Response Splitting
• OWASP Testing for HTTP Splitting
• http-proxy-middleware documentation
• Semgrep CRLF injection rules
• fix: upgrade http-proxy-middleware to 3.0.7, 4.1.1 (CVE-2026-55603)