CVE-2026-1527

What it actually does

This is an improper input validation flaw in Node.js undici affecting the HTTP/1 client request path when an application passes attacker-controlled data into the `upgrade` option of `client.request()`. Because the `upgrade` value is written directly into the outbound HTTP request headers without rejecting carriage return or line feed characters, an attacker can inject CRLF sequences to add arbitrary HTTP headers, alter request structure, prematurely terminate the HTTP request, or append raw protocol data. In vulnerable application designs, this can enable HTTP request smuggling or protocol smuggling toward internal services reachable by the application, including non-HTTP services such as Redis, Memcached, or Elasticsearch.

Why it matters to the business

If a vulnerable application exposes the undici `upgrade` option to user-controlled input, attackers may be able to manipulate backend requests made by the application and interact with internal services that are not directly exposed to the internet. The likely impact is targeted data exposure or data manipulation rather than broad unauthenticated takeover, reflected by the moderate CVSS score of 4.6 and currently low EPSS probability. However, organizations using undici in service-to-service communication, proxy-like features, webhooks, URL fetchers, API gateways, or integrations that contact internal infrastructure should treat this as higher priority because exploitation can cross trust boundaries and reach sensitive internal systems.

How an attack unfolds

An attacker first identifies an application feature that causes the server to make an outbound HTTP request using undici `client.request()` and allows the attacker to influence the `upgrade` option. The attacker supplies an `upgrade` value containing encoded or raw CRLF characters, causing undici to emit additional attacker-controlled header lines on the wire. By carefully crafting the injected sequence, the attacker can add headers, end the HTTP header block early, and place arbitrary bytes after the header terminator. If the destination host or an intermediary accepts the malformed traffic, the attacker can smuggle a second request or raw protocol commands. In deployments where the application can reach internal services, the attacker may use the application as a confused deputy to send commands to backend systems such as Redis, Memcached, or Elasticsearch, potentially reading or modifying data depending on service exposure and authentication.

How to fix it

Upgrade undici to a version that contains a fix once a fixed version is available from the project or your package distributor. Because no fixed version was provided in the input, also apply defensive coding mitigations immediately: never pass user-controlled data directly to the `upgrade` option of `client.request()`; reject any `upgrade` value containing carriage return, line feed, or other invalid HTTP header characters; allowlist only known safe upgrade tokens such as `websocket` where explicitly required; and remove dynamic upgrade behavior where it is not needed. Add centralized validation for outbound request options, especially in proxy, webhook, integration, and URL-fetching components. Restrict egress from application runtimes so they cannot directly reach Redis, Memcached, Elasticsearch, metadata services, administrative endpoints, or other internal systems unless explicitly required.

How to confirm the fix worked

Confirm exposure by reviewing code and dependency usage for `undici` and calls to `client.request()` that set the `upgrade` option. Verify that the `upgrade` value is constant or strictly allowlisted and that inputs containing `\r`, `\n`, `%0d`, or `%0a` are rejected before reaching undici. In testing environments, send benign payloads containing CRLF sequences through any user-controllable field suspected of influencing `upgrade` and inspect outbound traffic with a packet capture or controlled receiver to confirm that no injected headers or extra request bytes are emitted. Validate dependency remediation with package manager output such as `npm ls undici`, lockfile review, SBOM scanning, and runtime build inspection. Validate network mitigation by confirming application workloads cannot connect to unnecessary internal services or non-HTTP ports.

Typical attack path

1. Find an application endpoint or workflow that triggers outbound requests through Node.js undici.
2. Determine whether user-controlled input is passed into the `upgrade` option of `client.request()`.
3. Submit an `upgrade` value containing CRLF sequences such as `%0d%0a` or raw `\r\n`.
4. Inject additional HTTP headers or terminate the HTTP request header section early.
5. Append a smuggled HTTP request or raw protocol payload intended for a backend or internal service.
6. Use the application’s network access to reach services that are otherwise inaccessible to the attacker.
7. Attempt data access, data modification, cache poisoning, request confusion, or internal service interaction depending on the reachable target.

How to detect it

To determine whether exploitation has already occurred, review application access logs, WAF logs, API gateway logs, reverse proxy logs, and request telemetry for user-supplied parameters containing CRLF encodings such as `%0d%0a`, `%0D%0A`, `\r\n`, or double-encoded variants. Correlate those requests with application outbound network logs, egress firewall logs, service mesh telemetry, DNS logs, and packet captures for unexpected connections from application processes to internal services, especially Redis on 6379, Memcached on 11211, Elasticsearch on 9200/9300, metadata services, or administrative endpoints. Inspect application logs for malformed header errors, unexpected `Connection: upgrade` behavior, parser errors, reset connections, or backend protocol errors occurring immediately after suspicious inbound requests. For Node.js workloads, review process telemetry and dependency inventories to identify affected undici usage, then compare timestamps of suspicious inputs with outbound socket activity. Because exploitation payloads are highly application-specific, absence of a universal artifact does not prove absence of exploitation; focus on CRLF-bearing inputs followed by anomalous outbound requests or internal service commands.

• %0d%0a
• %0D%0A
• %250d%250a
• %250D%250A
• \r\n
• Connection: upgrade
• connection: upgrade
• Upgrade: websocket
• upgrade: websocket
• client.request(
• upgrade:
• ERR_HTTP_INVALID_HEADER_VALUE
• Parse Error: Invalid header value char
• HPE_INVALID_HEADER_TOKEN
• HPE_INVALID_CONSTANT
• 127.0.0.1:6379
• localhost:6379
• :6379
• :11211
• :9200
• :9300
• redis-cli
• memcached
• elasticsearch

What your security team should do

• Inventory applications and services using `nodejs undici`, including transitive dependency usage in Node.js applications.
• Prioritize review of internet-facing applications, webhook processors, proxy-like services, API gateways, SSRF-prone features, and integrations that perform outbound requests based on user input.
• Search source code for `client.request(` and `upgrade:` usage, then confirm no attacker-controlled data can reach the `upgrade` option.
• Apply strict allowlist validation or remove dynamic `upgrade` handling while waiting for or deploying an upstream fixed version.
• Add tests that reject CRLF characters in all values used to construct outbound HTTP headers or request options.
• Restrict application egress to only required hosts and ports, with explicit blocks for internal data stores and administrative services.
• Monitor for suspicious outbound requests containing CRLF injection attempts, unexpected `Connection: upgrade` traffic, or application connections to Redis, Memcached, Elasticsearch, and other internal services.
• Track undici advisories and update package lockfiles, container images, and downstream builds as soon as fixed versions are released.