Cross-tenant subscription data leak in @graphql-tools/executor-legacy-ws: a shared websocket.onmessage is replaced on every subscribe(), and DATA frames are delivered without checking the protocol operation id

Report metadata

Affected version range: the range recorded for this finding is <= 1.1.33, but that is understated — the same proof of concept reproduces on 1.1.35, and a byte diff of the built CJS output between 1.1.33 and 1.1.35 shows only one unrelated change (rejectUnauthorized).

Summary

buildWSLegacyExecutor keeps one WebSocket in closure state and installs the message handler by assigning to the socket's single websocket.onmessage property inside subscribe(). Every new subscription therefore overwrites the previous subscriber's handler, and the handler's case LEGACY_WS.DATA branch calls observer.next(data.payload) without ever comparing data.id to the operation id that this subscription created at line 103 and sent with START at line 123. When one executor instance is reused for overlapping subscriptions, the most recent caller receives payloads belonging to the earlier caller, and the earlier caller receives nothing.

In a consuming application, the tainted input is an ordinary, correctly-tagged DATA frame emitted by the legitimate downstream server for the victim's operation. The attacker does not need to control or compromise that server; they only need to be able to start their own subscription through the same shared executor while the victim's subscription is active — the natural shape of a gateway, stitched schema, or any service that builds a remote executor once and reuses it per request.

The surrounding code shows the inconsistency:

• packages/loaders/url/src/index.ts:262-295 (in-repo UrlLoader wrapper) → constructs a fresh legacy executor inside each request, so that caller avoids the shared state.
• buildWSLegacyExecutor's returned executor, reused across callers → unsafe: shared onmessage overwritten at line 113, DATA dispatched without an id check at lines 145-147.
• packages/loaders/url/src/index.ts:172-182 → also a production caller of the legacy executor; safe only insofar as the wrapper above rebuilds the executor per request, not because of any check in the executor itself.

Impact

A user of a service that shares one legacy executor receives another user's private GraphQL subscription payloads verbatim, with the victim's authorization context, without ever having been authorized for that operation. The victim is simultaneously starved: their own iterator stops receiving the events they subscribed to, because their handler has been detached.

Without this bug, the attacker's observer would receive only results for their own operation — and in this implementation, no result at all, since their operation is never STARTed after CONNECTION_ACK has already fired. The new capability is therefore reading data the attacker could not otherwise obtain by any request they are permitted to make, plus a denial of the victim's subscription stream.

Scoring note: no CVSS vector was computed for this finding, because exploitability depends on the consuming application's data flow — specifically whether one executor instance is shared across mutually untrusted callers. Consumers that construct a new executor per operation (as the in-repo UrlLoader wrapper does at packages/loaders/url/src/index.ts:262-295) are not affected by the cross-caller leak. The set of affected downstream consumers has not been enumerated: unknown.

Preconditions

1. One executor value returned by buildWSLegacyExecutor is reused rather than constructing a new executor per operation. This is the normal use of an Executor: the contract is invoked once per ExecutionRequest, the code explicitly reuses an OPEN socket, and the returned value holds Symbol.dispose.
2. Two subscription iterators overlap on an already-OPEN socket. The deciding default is in ensureWebsocket() (packages/executors/legacy-ws/src/index.ts:35-42), which does not create a second socket when one is open, combined with the single mutable websocket.onmessage assignment at line 113.
3. The attacker can cause their own subscription request to be made through that shared executor while the victim's subscription is active and acknowledged. They do not need any control over the downstream server.
4. Downstream subscription results differ by user or authorization context, so a misrouted payload is actually a disclosure.

This does not require non-standard usage, monkey-patching, or unusual configuration. packages/executors/legacy-ws/src/index.ts documents no single-operation-only restriction, the return type is the general reusable DisposableExecutor (packages/utils/src/executor.ts:34-57), and the behaviour is not documented as a caller responsibility.

Data flow

1. Source — a legitimate DATA message emitted by the downstream server for another operation on the shared WebSocket. The victim invokes the returned executor, and subscribe() installs a closure over the victim's observer and request as websocket.onmessage (packages/executors/legacy-ws/src/index.ts:90-113).
2. Propagation — the server's CONNECTION_ACK starts the victim's operation with id, created at line 103 and sent with START at line 123 (packages/executors/legacy-ws/src/index.ts:116-135).
3. Sink — the attacker invokes the same executor while websocket.readyState is OPEN; ensureWebsocket() does not create a new socket and subscribe() replaces the sole websocket.onmessage with the attacker's closure (index.ts:35-42, index.ts:109-113). The server's DATA frame for the victim carries the victim's operation id per the legacy protocol, but the handler ignores data.id and calls observer.next(data.payload) on the attacker's observer (index.ts:114-147).
4. Reachability — the sink sits in the only subscribe path of the executor produced by the directly exported buildWSLegacyExecutor (index.ts:27-31). packages/loaders/url/src/index.ts:172-182 is a production caller in this repository; direct library consumers reach it by building a remote executor once and reusing it.

Vulnerable code

packages/executors/legacy-ws/src/index.ts, lines 103-167 at b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1:

const id = Date.now().toString();
return observableToAsyncIterable({
  subscribe(observer) {
    ensureWebsocket();
    ...
    websocket.onmessage = event => {           // sole handler: overwritten by every new subscribe()
      const data = JSON.parse(event.data.toString('utf-8'));
      switch (data.type) {
        ...
        case LEGACY_WS.DATA: {
          observer.next(data.payload);         // SINK: data.id is never compared with id
          break;
        }
      }
    };
  },
});

Two independent defects are visible here: the single mutable onmessage assignment (which detaches the earlier subscriber), and the missing data.id === id check in the DATA branch (which misroutes the payload). The operation id itself is also derived from Date.now(), so it is not collision-resistant.

Reproduction

Verified dynamically against the real published package @graphql-tools/executor-legacy-ws@1.1.33 (npm tarball with matching source at d304214db06e8a4ce9cb41138f199e3bc6ed36f2). The harness was a protocol-correct legacy graphql-ws server (ws v8) that tags every DATA frame with the operation id of the operation that produced it, plus two callers sharing one executor instance.

• Scenario A (control, single subscription): the subscriber received its own payload, confirming the harness is sound.
• Scenario B (the claim): caller 1 ("victim") subscribed; the server ACKed and the client sent start id=1790247741390. Caller 2 ("attacker") then invoked the same executor while readyState was OPEN. The server observed only one socket (ensureWebsocket reused it) and only one started operation — the attacker's operation was never started, because CONNECTION_ACK had already fired. The server then emitted a correctly-tagged DATA frame for the victim's id. The attacker's iterator received {"data":{"victimSecret":"VICTIM-PRIVATE-DATA-a1b2c3"}} and the victim's iterator received nothing.
• Scenario C: a DATA frame tagged with the id "id-that-was-never-started" was still delivered to the subscriber, proving the protocol operation id is never validated.
• Realistic wiring: with the executor wired into wrapSchema() the way a stitching gateway does, two concurrent users subscribing to the same field produced a verbatim cross-tenant leak — User B received {"data":{"accountBalance":"USER-A-PRIVATE-BALANCE-$91402.11"}} while User A received nothing. When the two users select different fields, the wrap layer's result transform masks the foreign field (B saw weather:null), but the misrouting still occurs and the victim is still starved; at the raw executor API the payload leaks verbatim regardless.
• Causality control: patching only the DATA branch to check data.id === id eliminated the leak (the attacker received nothing, and the foreign-id frame was rejected), pinning the leak to the missing id check. Under that patch the victim still received nothing, confirming the second, independent defect: the single shared websocket.onmessage is overwritten on each subscribe(), detaching the earlier subscriber's handler entirely.
• Scope caveat: the identical proof of concept also reproduces on the current latest release 1.1.35.

Minimal client-side shape:

import WebSocket from 'isomorphic-ws';
import { parse } from 'graphql';
import { buildWSLegacyExecutor } from '@graphql-tools/executor-legacy-ws';

const exec = buildWSLegacyExecutor('ws://localhost:8081/graphql', WebSocket);

const victim = exec({ document: parse('subscription { privateEvent { secret } }') });
const victimPending = victim.next(); // causes connection + START; wait until the server has ACKed
await new Promise(r => setTimeout(r, 100));

const attacker = exec({ document: parse('subscription { publicEvent { id } }') });
const attackerPending = attacker.next(); // overwrites socket.onmessage

// When the server now emits DATA for the victim's id, this prints the victim's secret.
console.log(await attackerPending);

Steps:

1. Start a normal legacy subscriptions-transport-ws server with a private event subscription.
2. Build one executor and call victimIterator.next() so the socket receives connection_ack and START for the victim.
3. While that socket is OPEN, call attackerIterator.next() using the same executor.
4. Emit one victim event from the server.

• Expected: a DATA frame is delivered only to the observer registered for data.id; the attacker's pending next() must never resolve with the victim's payload, and the victim keeps receiving their own events.
• Actual: the attacker's next() resolves with the victim's payload, and the victim's iterator receives nothing.

Suggested remediation

Dispatch protocol frames by operation id to the observer that started that operation, instead of routing every frame to whichever subscriber most recently overwrote the socket's sole onmessage handler.

// 1. Stop the misrouting: ignore frames that belong to another operation.
case LEGACY_WS.DATA: {
  if (data.id !== id) {
    break;
  }
  observer.next(data.payload);
  break;
}

// 2. Stop the handler overwrite: keep a registry of observers keyed by operation id
//    and install exactly one shared message listener for the socket.
const observers = new Map<string, Observer<any>>();

function ensureMessageHandler() {
  if (messageHandlerInstalled) return;
  messageHandlerInstalled = true;
  websocket.onmessage = event => {
    const data = JSON.parse(event.data.toString('utf-8'));
    const target = data.id != null ? observers.get(data.id) : undefined;
    // ... dispatch DATA / ERROR / COMPLETE to `target` only, and remove it on COMPLETE
  };
}

An alternative that keeps the current structure is to create a separate socket (and therefore a separate listener) per execution, as the in-repo UrlLoader wrapper effectively does today.

Notes:

• The same id check is needed on the ERROR and COMPLETE branches, not just DATA; otherwise one operation's termination still tears down another's iterator.
• The operation id is generated as Date.now().toString() (line 103), which is not collision-resistant — two subscriptions created in the same millisecond would share an id even after the dispatch fix. Use a counter or a random component.
• The missing id check and the overwritten onmessage are two independent defects; fixing only the id check stops the leak but leaves the earlier subscriber permanently starved, as the causality control above showed.
• packages/loaders/url/src/index.ts:262-295 already builds a fresh legacy executor inside each request, so that caller needs no change; the fix belongs in the executor itself, because the exported buildWSLegacyExecutor returns a general reusable DisposableExecutor.
• No upstream advisory (CVE/GHSA), fix commit, or fixed version is known for this issue: unknown / not verified. The set of affected downstream consumers has likewise not been enumerated.

Suggested regression test alongside the existing packages/executors/legacy-ws test suite: with one executor shared by two overlapping subscriptions on an OPEN socket, assert that a DATA frame tagged with subscription A's operation id resolves only A's iterator and never B's, and that a DATA frame tagged with an id that was never started is dropped rather than delivered to the most recent subscriber.

Resolution

Fixed in @graphql-tools/executor-legacy-ws@1.1.36, which is published on npm. Each execution has its own socket, and data, error, and complete frames are delivered only when the protocol operation id matches. Upgrade to >=1.1.36.