CVE-2026-35515

What it actually does

CVE-2026-35515 is an improper input validation flaw in NestJS Server-Sent Events handling before version 11.1.18. The SseStream._transform() implementation writes message.type and message.id directly into the SSE text stream without removing or encoding carriage return and line feed characters. Because the SSE protocol uses newlines as field delimiters and a blank line as an event boundary, attacker-controlled newline characters in those fields can break out of the intended field and inject additional SSE fields or complete events. The result is limited integrity and availability impact: clients may receive spoofed event types, forged event payload structure, corrupted event ordering, or manipulated Last-Event-ID reconnection state.

Why it matters to the business

Applications using affected NestJS SSE functionality may deliver misleading or attacker-influenced real-time updates to browsers, mobile clients, dashboards, or automation consumers. This can cause users or downstream systems to act on false events, miss legitimate updates, or reconnect from an incorrect event position. The issue is not currently listed in CISA KEV, has no known public exploit maturity in the provided data, and has a low EPSS score of 0.00234 with no 30-day increase, but it should still be prioritized for services where untrusted users or external data can influence SSE event type or ID values.

How an attack unfolds

An attacker first identifies a NestJS application endpoint that streams Server-Sent Events. Exploitation depends on an application data path where the attacker can influence the SSE message type or ID, such as user-controlled records, queue messages, webhook content, notification metadata, or other upstream data that is later emitted through NestJS SSE APIs. The attacker supplies a value containing carriage return or newline characters. When the affected NestJS version serializes the message, those newline characters are interpreted by the SSE client as protocol delimiters rather than as data. This allows the attacker to terminate the intended field, add arbitrary SSE fields such as event, id, retry, or data, and potentially create an additional event boundary with a double newline. Connected clients then process the injected content as legitimate SSE protocol output, which can spoof event types, alter client-side behavior, or corrupt reconnection state.

How to fix it

Upgrade affected NestJS packages to version 11.1.18 or later. Ensure related @nestjs packages are kept on compatible versions across the application dependency tree. If immediate upgrade is not possible, mitigate by strictly validating or normalizing any values used as SSE event IDs or event types: reject or remove \r and \n characters, enforce conservative allowlists for event types, and generate event IDs server-side using safe formats such as UUIDs, monotonic numeric IDs, or other newline-free identifiers. Do not pass untrusted upstream values directly into SSE id or type fields. As a defense-in-depth measure, add tests that assert SSE metadata fields cannot contain CRLF characters and review consumers that perform sensitive actions based solely on SSE event type or ID.

How to confirm the fix worked

Confirm all deployed applications that use NestJS SSE functionality resolve to NestJS 11.1.18 or later. Review package lockfiles and runtime dependency output to verify no older vulnerable NestJS package remains through transitive or pinned dependencies. Exercise SSE endpoints with benign test values containing encoded or literal CR/LF characters in inputs that may influence event ID or type, and confirm the response does not contain injected SSE fields or unexpected blank-line event boundaries. Inspect emitted SSE streams and verify that event names and IDs are sanitized, rejected, or generated from trusted server-side values only. Regression tests should include payloads such as newline characters in event type and ID fields and assert that the resulting SSE stream contains only the intended event structure.

Typical attack path

1. Find an application endpoint that uses NestJS Server-Sent Events.
2. Identify an upstream input path that influences the emitted SSE message.type or message.id fields.
3. Submit a crafted value containing carriage return and/or line feed characters, including sequences that create additional SSE fields or event boundaries.
4. Wait for the application to emit the attacker-influenced message to connected SSE clients.
5. Cause clients to parse injected protocol fields as legitimate SSE events, spoofing event types or changing Last-Event-ID/retry behavior.
6. Use the resulting client-side confusion to mislead users, disrupt real-time workflows, or influence downstream automation that trusts SSE messages.

How to detect it

To assess prior exploitation, review logs and data sources that feed SSE message type or ID values. Focus on HTTP request logs, API gateway logs, application logs, message queue records, webhook payload archives, audit logs for notification/event creation, and any persistence layer that stores event metadata later emitted through SSE. Look for literal or encoded carriage return and line feed characters in fields that become SSE event names, event IDs, notification types, topic names, or message identifiers. In web logs, search for URL-encoded newline sequences such as %0a, %0d, and %0d%0a near parameters or JSON fields named id, event, type, messageType, notificationType, topic, or channel. In application and response captures, look for malformed SSE output where an event or id field is followed by unexpected additional fields, blank lines, injected data fields, or suspicious retry values. Also review client-side telemetry for unusual SSE reconnect behavior, unexpected Last-Event-ID values, anomalous event types, parsing errors, or bursts of reconnects following attacker-controlled input. There are no universal file, process, registry, or network IOCs for this vulnerability; detection is primarily payload-pattern and application-data-path based.

• %0a
• %0A
• %0d
• %0D
• %0d%0a
• %0D%0A
• \r\n
• \n\n
• id:%0a
• id:%0d
• type:%0a
• type:%0d
• event:%0a
• event:%0d
• messageType%22%3A%22%0A
• messageType%22%3A%22%0D
• notificationType%22%3A%22%0A
• notificationType%22%3A%22%0D
• retry:%20
• Last-Event-ID

What your security team should do

• Inventory services using NestJS Server-Sent Events and identify those running versions earlier than 11.1.18.
• Upgrade affected NestJS deployments to 11.1.18 or later, prioritizing internet-facing real-time notification, dashboard, workflow, or automation services.
• Review application code for any use of untrusted data in SSE message type or ID fields and replace it with allowlisted event names and server-generated IDs.
• Add input validation that rejects or strips carriage return and line feed characters from all SSE metadata fields.
• Add automated tests or security checks for SSE response-splitting and event-injection payloads.
• Monitor access logs, application logs, and upstream message sources for attempts to insert URL-encoded or literal CR/LF characters into values that may be emitted over SSE.
• Because current EPSS is low, not in KEV, and no exploit maturity is reported, handle through normal vulnerability remediation SLAs unless affected SSE streams drive high-trust business decisions or automation.