CVE-2026-33128

What it actually does

H3's createEventStream helper incorrectly formats Server-Sent Events when attacker-controlled values are placed into the SSE id, event, data, or comment fields. Because formatEventStreamMessage() and formatEventStreamComment() did not sanitize newline characters, an attacker can break out of the intended SSE field and inject additional SSE protocol lines such as event:, data:, id:, retry:, or a blank line that terminates and dispatches a forged event. The impact is primarily integrity compromise of the server-to-client event stream: connected clients may receive attacker-created events that appear to come from the trusted application. Depending on how the client processes SSE events, this can lead to unauthorized UI state changes, misleading notifications, workflow manipulation, or secondary client-side injection if event data is trusted by front-end code.

Why it matters to the business

Applications using affected H3 versions for live updates, notifications, dashboards, collaborative features, status feeds, or streaming application state can deliver attacker-forged messages to users. This may cause users or automated clients to act on false information, corrupt business workflows, display fraudulent alerts, or trigger unintended client-side behavior. The issue has a moderate-to-high CVSS score and public exploit availability, but the EPSS score is currently low and it is not listed in CISA KEV, so remediation should be prioritized for internet-facing or security-sensitive SSE endpoints rather than treated as confirmed mass exploitation.

How an attack unfolds

An attacker first identifies an application endpoint that emits Server-Sent Events using H3 createEventStream and includes user-controllable input in an SSE id, event, data, or comment value. The attacker then submits input containing newline characters followed by valid SSE syntax. When the vulnerable H3 formatter writes this value to the event stream without properly sanitizing embedded newlines, the browser or SSE client interprets the injected lines as separate event-stream fields. By including a blank line, the attacker can force dispatch of a forged event to connected clients. If the application client trusts these events, the attacker can spoof application messages, manipulate UI state, or influence client-side workflows without needing authentication in cases where the vulnerable input path is unauthenticated.

How to fix it

Upgrade H3 to a fixed version: use 1.15.6 or later for the 1.x line, or 2.0.1-rc.15 or later for the 2.x release-candidate line. Ensure package lockfiles are refreshed and deployed artifacts actually contain the upgraded dependency. If immediate upgrade is not possible, prevent untrusted input from reaching SSE id, event, data, or comment fields, and reject or encode carriage return and newline characters before event-stream formatting. Treat all SSE data as untrusted on the client side and avoid executing or blindly applying event contents to privileged workflows. Review transitive dependencies and bundled framework versions, as H3 may be included indirectly in applications built on higher-level JavaScript or Node.js frameworks.

How to confirm the fix worked

Confirm the deployed dependency tree does not include vulnerable H3 versions earlier than 1.15.6 or versions 2.0.0 through 2.0.1-rc.14. Use package-manager inspection such as npm ls h3, pnpm why h3, yarn why h3, or lockfile review to verify the effective version. Exercise SSE endpoints with test values containing encoded newline sequences such as %0Aevent:%20test%0Adata:%20test%0A%0A and confirm the response treats the value as inert data rather than a separate dispatched event. Inspect event-stream responses with curl -N or browser developer tools and verify that user-controlled fields cannot introduce additional event:, data:, id:, retry:, or blank-line delimiters. Regression tests should cover id, event, data, and comment fields, including raw LF, CRLF, and URL-encoded newline input.

Typical attack path

1. Discover an H3-based application endpoint that uses Server-Sent Events.
2. Identify a parameter, message field, stored value, or upstream feed that is reflected into an SSE id, event, data, or comment field.
3. Submit payloads containing URL-encoded or raw newline characters followed by SSE directives such as event:, data:, id:, retry:, and a terminating blank line.
4. Cause the vulnerable server to format and broadcast the unsanitized value through createEventStream.
5. Have connected browsers or SSE clients parse the injected lines as legitimate separate SSE events.
6. Abuse the forged event to mislead users, alter client application state, or trigger downstream client logic.

How to detect it

To assess whether this was already exploited, review HTTP access logs, application logs, API gateway logs, WAF logs, and telemetry for SSE-producing endpoints with parameters or payload fields containing raw or URL-encoded newline characters followed by SSE directives. Focus on requests that include combinations of %0A, %0D%0A, \n, or \r\n with strings such as event:, data:, id:, retry:, or comment-like colon-prefixed lines. Inspect application logs for suspicious values stored in user-generated content that later appear in event streams. Review client-side error telemetry, unusual EventSource event names, unexpected state-change events, and reports of false notifications or UI updates. Because exploitation may not create server-side errors, detection depends heavily on request/content logging and historical capture of the data that was emitted through SSE streams. If web traffic capture is available, inspect text/event-stream responses for unexpected injected events or blank-line event terminators inside user-controlled fields.

• %0Aevent%3A
• %0D%0Aevent%3A
• %0Adata%3A
• %0D%0Adata%3A
• %0Aid%3A
• %0D%0Aid%3A
• %0Aretry%3A
• %0D%0Aretry%3A
• \nevent:
• \r\nevent:
• \ndata:
• \r\ndata:
• \nid:
• \r\nid:
• \nretry:
• \r\nretry:
• text/event-stream
• EventSource

What your security team should do

• Inventory applications and services that use H3 and expose Server-Sent Events, especially internet-facing real-time feeds.
• Upgrade H3 to 1.15.6 or later, or to 2.0.1-rc.15 or later for the 2.x release-candidate branch.
• Prioritize endpoints where unauthenticated users, low-privileged users, webhooks, chat content, names, titles, comments, or external feeds can influence SSE output.
• Add input validation that rejects or safely encodes CR and LF characters before values are passed to SSE formatting functions.
• Review client-side SSE handlers to ensure event data is validated and cannot directly trigger privileged actions or unsafe DOM updates.
• Search recent logs for newline-injection probes and SSE syntax embedded in request parameters or message content.
• Add automated dependency checks or SCA policies to block vulnerable H3 versions from future builds.