GHSA-4hxc-9384-m385

What it actually does

The h3 npm package improperly validates Server-Sent Events (SSE) data and comment fields by failing to sanitize carriage return characters (`\r`). Because SSE streams are line-oriented, an attacker-controlled carriage return can alter event framing and inject additional fields or events into the stream. This issue is described as a bypass of a prior fix, meaning applications that believed they were protected by earlier sanitization may still be vulnerable if they emit attacker-controlled values into SSE `data` or comment fields. The impact is primarily integrity-related: clients consuming the event stream may receive forged, split, or manipulated SSE messages that the server application did not intend to send.

Why it matters to the business

Applications using h3 to serve SSE streams may allow untrusted users or upstream systems to inject misleading real-time messages into clients, dashboards, notifications, or browser-side event handlers. In practical terms, this can cause users or automated front-end logic to act on false information, corrupt UI state, trigger unintended workflows, or undermine trust in real-time application features. The CVSS score is moderate and there is no known KEV listing or reported exploit maturity, but the issue should still be prioritized for products that expose SSE endpoints carrying user-influenced content.

How an attack unfolds

An attacker first identifies an application endpoint that emits Server-Sent Events using h3 and reflects or incorporates attacker-controlled input into an SSE `data` field or comment. The attacker submits a payload containing carriage return characters designed to break the intended SSE line structure. If the application is running a vulnerable h3 version, the stream serializer does not neutralize the `\r` character, allowing the payload to be interpreted by the client as additional SSE framing. The victim browser or SSE client then processes forged fields or injected events as though they were legitimately sent by the server. Exploitation generally requires an application-specific path for attacker-controlled content to reach the SSE stream; this is not typically a standalone remote code execution flaw.

How to fix it

Upgrade h3 to a fixed version: for the 2.x release candidate line, use `h3` npm version `2.0.1-rc.17` or later; for the 1.x line, use `h3` npm version `1.15.9` or later. Rebuild and redeploy applications after updating lockfiles so the patched package is actually present in production artifacts. If immediate upgrade is not possible, avoid placing untrusted input in SSE `data` or comment fields, normalize or reject carriage return and line-feed characters before passing values to SSE output, and add defense-in-depth validation at application boundaries. Review any previous mitigation for the related prior issue, because this advisory indicates a bypass of an earlier fix.

How to confirm the fix worked

Confirm exposure by checking dependency manifests and lockfiles for vulnerable `h3` versions below `1.15.9` on the 1.x line or below `2.0.1-rc.17` on the 2.x release candidate line. Validate the deployed runtime image or package bundle, not only source repositories. Functional testing should include sending SSE data/comment values containing raw carriage return characters and confirming the emitted stream does not create additional event fields or events. A patched implementation should neutralize or encode line-breaking characters so clients receive the content as data rather than as SSE framing. Also verify that application-level input validation prevents untrusted multiline control characters from reaching SSE emitters where they are not explicitly intended.

Typical attack path

1. Find an application using a vulnerable h3 npm version that exposes Server-Sent Events endpoints.
2. Identify an SSE stream where user-controlled or attacker-influenced content is emitted in event `data` or comment fields.
3. Submit crafted input containing carriage return characters (`\r`) and SSE-like field syntax.
4. Cause the vulnerable serializer to emit malformed SSE framing without properly sanitizing the carriage return.
5. Have connected clients process injected or altered SSE messages as legitimate server events.
6. Abuse the forged event content to mislead users, manipulate client-side state, or trigger unintended front-end behavior.

How to detect it

To assess whether this was already exploited, review logs for requests to endpoints that produce `text/event-stream` responses where attacker-controlled parameters, headers, request bodies, or submitted content contain carriage return characters or encoded equivalents. Useful sources include web access logs, application logs around SSE publishing, API gateway and reverse proxy logs, WAF logs, and client-side error telemetry for malformed or unexpected SSE events. Look for payloads containing raw `\r`, URL-encoded `%0d`, double-encoded `%250d`, or combinations such as `%0d%0a` followed by SSE field names like `data:`, `event:`, `id:`, or `retry:`. Also review application audit trails for unusual real-time notifications, state changes, or client actions occurring immediately after suspicious SSE-related inputs. There are no universal file-system or process-level indicators for this package-level flaw; detection is primarily request/content and application-event based.

• %0ddata:
• %0devent:
• %0did:
• %0dretry:
• %0d%0adata:
• %0d%0aevent:
• %0d%0aid:
• %0d%0aretry:
• %250ddata:
• %250devent:
• %250did:
• %250dretry:
• \rdata:
• \revent:
• \rid:
• \rretry:
• text/event-stream

What your security team should do

• Inventory applications and services that depend on the `h3` npm package, especially those exposing Server-Sent Events endpoints.
• Upgrade `h3` to `1.15.9` or later for 1.x deployments, or `2.0.1-rc.17` or later for 2.x release-candidate deployments.
• Regenerate lockfiles, rebuild containers or deployment artifacts, and verify the patched version is present in production.
• Prioritize remediation for externally reachable applications, real-time dashboards, notification systems, chat/collaboration features, and any workflow where SSE messages influence user decisions or client-side actions.
• Search code for SSE emission paths that include user-controlled input and add explicit normalization or rejection of `\r` and other unexpected control characters.
• Add regression tests for SSE serialization using payloads containing carriage returns, line feeds, and SSE field-like strings.
• Monitor SSE endpoints for suspicious requests containing encoded or raw carriage returns in parameters, request bodies, or upstream message content.