GHSA-MP66-8WW2-PCWM

Vulnerability from github – Published: 2026-10-28 21:05 – Updated: 2026-10-28 21:05

Summary

GraphQL Tools: Shared legacy executor routes one subscription's results to a different caller

Details

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

Field	Value
Package	`@graphql-tools/executor-legacy-ws` (npm, `pkg:npm/%40graphql-tools/executor-legacy-ws`)
Repository	https://github.com/ardatan/graphql-tools
Component	`buildWSLegacyExecutor` → the returned executor's `subscribe(observer)` / `websocket.onmessage` handler
Vulnerability class	Cross-tenant data leak (subscription results delivered to the wrong caller)
Verified against	Source at `b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1` (package version 1.1.33); published npm tarball `1.1.33` with matching source at `d304214db06e8a4ce9cb41138f199e3bc6ed36f2`; the same behaviour also reproduces on the current release `1.1.35`
API surface	Public documented API (`buildWSLegacyExecutor`)
Affected in default configuration	Yes — `ensureWebsocket()` reuses an already-`OPEN` socket (`index.ts:35-42`), and the socket has a single mutable `onmessage` property (`index.ts:113`). No single-operation-only restriction is documented, and the return type is the general reusable `DisposableExecutor` (`packages/utils/src/executor.ts:34-57`)

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

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.
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.
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.
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

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).
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).
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).
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:

Start a normal legacy subscriptions-transport-ws server with a private event subscription.
Build one executor and call victimIterator.next() so the socket receives connection_ack and START for the victim.
While that socket is OPEN, call attackerIterator.next() using the same executor.
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.

Severity

6.0 (Medium)


                  
                    CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.1.35"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@graphql-tools/executor-legacy-ws"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.36"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-118666"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-28T21:05:07Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# 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\n\n## Report metadata\n\n| Field | Value |\n| --- | --- |\n| Package | `@graphql-tools/executor-legacy-ws` (npm, `pkg:npm/%40graphql-tools/executor-legacy-ws`) |\n| Repository | https://github.com/ardatan/graphql-tools |\n| Component | `buildWSLegacyExecutor` \u2192 the returned executor\u0027s `subscribe(observer)` / `websocket.onmessage` handler |\n| Vulnerability class | Cross-tenant data leak (subscription results delivered to the wrong caller) |\n| Verified against | Source at `b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1` (package version 1.1.33); published npm tarball `1.1.33` with matching source at `d304214db06e8a4ce9cb41138f199e3bc6ed36f2`; the same behaviour also reproduces on the current release `1.1.35` |\n| API surface | Public documented API (`buildWSLegacyExecutor`) |\n| Affected in default configuration | Yes \u2014 `ensureWebsocket()` reuses an already-`OPEN` socket (`index.ts:35-42`), and the socket has a single mutable `onmessage` property (`index.ts:113`). No single-operation-only restriction is documented, and the return type is the general reusable `DisposableExecutor` (`packages/utils/src/executor.ts:34-57`) |\n\nAffected version range: the range recorded for this finding is `\u003c= 1.1.33`, but that is understated \u2014 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`).\n\n## Summary\n\n`buildWSLegacyExecutor` keeps one WebSocket in closure state and installs the message handler by assigning to the socket\u0027s single `websocket.onmessage` property inside `subscribe()`. Every new subscription therefore overwrites the previous subscriber\u0027s handler, and the handler\u0027s `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.\n\nIn a consuming application, the tainted input is an ordinary, correctly-tagged `DATA` frame emitted by the legitimate downstream server for the victim\u0027s 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\u0027s subscription is active \u2014 the natural shape of a gateway, stitched schema, or any service that builds a remote executor once and reuses it per request.\n\nThe surrounding code shows the inconsistency:\n\n- `packages/loaders/url/src/index.ts:262-295` (in-repo `UrlLoader` wrapper) \u2192 constructs a fresh legacy executor inside each request, so that caller avoids the shared state.\n- `buildWSLegacyExecutor`\u0027s returned executor, reused across callers \u2192 **unsafe: shared `onmessage` overwritten at line 113, `DATA` dispatched without an id check at lines 145-147**.\n- `packages/loaders/url/src/index.ts:172-182` \u2192 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.\n\n## Impact\n\nA user of a service that shares one legacy executor receives another user\u0027s private GraphQL subscription payloads verbatim, with the victim\u0027s 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.\n\nWithout this bug, the attacker\u0027s observer would receive only results for their own operation \u2014 and in this implementation, no result at all, since their operation is never `START`ed 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\u0027s subscription stream.\n\nScoring note: no CVSS vector was computed for this finding, because exploitability depends on the consuming application\u0027s data flow \u2014 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**.\n\n## Preconditions\n\n1. 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`.\n2. 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.\n3. The attacker can cause their own subscription request to be made through that shared executor while the victim\u0027s subscription is active and acknowledged. They do not need any control over the downstream server.\n4. Downstream subscription results differ by user or authorization context, so a misrouted payload is actually a disclosure.\n\nThis 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.\n\n## Data flow\n\n1. **Source** \u2014 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\u0027s observer and request as `websocket.onmessage` ([`packages/executors/legacy-ws/src/index.ts:90-113`](https://github.com/ardatan/graphql-tools/blob/b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1/packages/executors/legacy-ws/src/index.ts#L90-L113)).\n2. **Propagation** \u2014 the server\u0027s `CONNECTION_ACK` starts the victim\u0027s operation with `id`, created at line 103 and sent with `START` at line 123 ([`packages/executors/legacy-ws/src/index.ts:116-135`](https://github.com/ardatan/graphql-tools/blob/b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1/packages/executors/legacy-ws/src/index.ts#L116-L135)).\n3. **Sink** \u2014 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\u0027s closure ([`index.ts:35-42`](https://github.com/ardatan/graphql-tools/blob/b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1/packages/executors/legacy-ws/src/index.ts#L35-L42), [`index.ts:109-113`](https://github.com/ardatan/graphql-tools/blob/b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1/packages/executors/legacy-ws/src/index.ts#L109-L113)). The server\u0027s `DATA` frame for the victim carries the victim\u0027s operation id per the legacy protocol, but the handler ignores `data.id` and calls `observer.next(data.payload)` on the attacker\u0027s observer ([`index.ts:114-147`](https://github.com/ardatan/graphql-tools/blob/b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1/packages/executors/legacy-ws/src/index.ts#L114-L147)).\n4. **Reachability** \u2014 the sink sits in the only `subscribe` path of the executor produced by the directly exported `buildWSLegacyExecutor` ([`index.ts:27-31`](https://github.com/ardatan/graphql-tools/blob/b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1/packages/executors/legacy-ws/src/index.ts#L27-L31)). `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.\n\n## Vulnerable code\n\n`packages/executors/legacy-ws/src/index.ts`, lines 103-167 at `b5d1c36ebb8ed3868260ffee5bbcbb423ad5c1f1`:\n\n```ts\nconst id = Date.now().toString();\nreturn observableToAsyncIterable({\n  subscribe(observer) {\n    ensureWebsocket();\n    ...\n    websocket.onmessage = event =\u003e {           // sole handler: overwritten by every new subscribe()\n      const data = JSON.parse(event.data.toString(\u0027utf-8\u0027));\n      switch (data.type) {\n        ...\n        case LEGACY_WS.DATA: {\n          observer.next(data.payload);         // SINK: data.id is never compared with id\n          break;\n        }\n      }\n    };\n  },\n});\n```\n\nTwo 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.\n\n## Reproduction\n\nVerified 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.\n\n- **Scenario A (control, single subscription):** the subscriber received its own payload, confirming the harness is sound.\n- **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 \u2014 the attacker\u0027s operation was never started, because `CONNECTION_ACK` had already fired. The server then emitted a correctly-tagged `DATA` frame for the victim\u0027s id. The attacker\u0027s iterator received `{\"data\":{\"victimSecret\":\"VICTIM-PRIVATE-DATA-a1b2c3\"}}` and the victim\u0027s iterator received nothing.\n- **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.\n- **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 \u2014 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\u0027s 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.\n- **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\u0027s handler entirely.\n- **Scope caveat:** the identical proof of concept also reproduces on the current latest release `1.1.35`.\n\nMinimal client-side shape:\n\n```ts\nimport WebSocket from \u0027isomorphic-ws\u0027;\nimport { parse } from \u0027graphql\u0027;\nimport { buildWSLegacyExecutor } from \u0027@graphql-tools/executor-legacy-ws\u0027;\n\nconst exec = buildWSLegacyExecutor(\u0027ws://localhost:8081/graphql\u0027, WebSocket);\n\nconst victim = exec({ document: parse(\u0027subscription { privateEvent { secret } }\u0027) });\nconst victimPending = victim.next(); // causes connection + START; wait until the server has ACKed\nawait new Promise(r =\u003e setTimeout(r, 100));\n\nconst attacker = exec({ document: parse(\u0027subscription { publicEvent { id } }\u0027) });\nconst attackerPending = attacker.next(); // overwrites socket.onmessage\n\n// When the server now emits DATA for the victim\u0027s id, this prints the victim\u0027s secret.\nconsole.log(await attackerPending);\n```\n\nSteps:\n\n1. Start a normal legacy `subscriptions-transport-ws` server with a private event subscription.\n2. Build one executor and call `victimIterator.next()` so the socket receives `connection_ack` and `START` for the victim.\n3. While that socket is `OPEN`, call `attackerIterator.next()` using the same executor.\n4. Emit one victim event from the server.\n\n- **Expected:** a `DATA` frame is delivered only to the observer registered for `data.id`; the attacker\u0027s pending `next()` must never resolve with the victim\u0027s payload, and the victim keeps receiving their own events.\n- **Actual:** the attacker\u0027s `next()` resolves with the victim\u0027s payload, and the victim\u0027s iterator receives nothing.\n\n## Suggested remediation\n\nDispatch 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\u0027s sole `onmessage` handler.\n\n```ts\n// 1. Stop the misrouting: ignore frames that belong to another operation.\ncase LEGACY_WS.DATA: {\n  if (data.id !== id) {\n    break;\n  }\n  observer.next(data.payload);\n  break;\n}\n```\n\n```ts\n// 2. Stop the handler overwrite: keep a registry of observers keyed by operation id\n//    and install exactly one shared message listener for the socket.\nconst observers = new Map\u003cstring, Observer\u003cany\u003e\u003e();\n\nfunction ensureMessageHandler() {\n  if (messageHandlerInstalled) return;\n  messageHandlerInstalled = true;\n  websocket.onmessage = event =\u003e {\n    const data = JSON.parse(event.data.toString(\u0027utf-8\u0027));\n    const target = data.id != null ? observers.get(data.id) : undefined;\n    // ... dispatch DATA / ERROR / COMPLETE to `target` only, and remove it on COMPLETE\n  };\n}\n```\n\nAn 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.\n\nNotes:\n\n- The same id check is needed on the `ERROR` and `COMPLETE` branches, not just `DATA`; otherwise one operation\u0027s termination still tears down another\u0027s iterator.\n- The operation id is generated as `Date.now().toString()` (line 103), which is not collision-resistant \u2014 two subscriptions created in the same millisecond would share an id even after the dispatch fix. Use a counter or a random component.\n- 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.\n- `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`.\n- 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.\n\nSuggested 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\u0027s operation id resolves only A\u0027s iterator and never B\u0027s, and that a `DATA` frame tagged with an id that was never started is dropped rather than delivered to the most recent subscriber.\n\n## Resolution\n\nFixed 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 `\u003e=1.1.36`.",
  "id": "GHSA-mp66-8ww2-pcwm",
  "modified": "2026-10-28T21:05:08Z",
  "published": "2026-10-28T21:05:07Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ardatan/graphql-tools/security/advisories/GHSA-mp66-8ww2-pcwm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ardatan/graphql-tools/pull/8480"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ardatan/graphql-tools/commit/c2f226e6f68236be9e4a577f29faeaa92547458b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ardatan/graphql-tools"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ardatan/graphql-tools/releases/tag/@graphql-tools/executor-legacy-ws@1.1.36"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "GraphQL Tools: Shared legacy executor routes one subscription\u0027s results to a different caller"
}

CVE-2026-118666 (GCVE-0-2026-118666)

Vulnerability from cvelistv5 – Published: 2026-10-28 20:45 – Updated: 2026-10-28 20:45

Title

GraphQL Tools: Shared legacy executor routes one subscription's results to a different caller

Summary

GraphQL Tools provides utilities for building, stitching, and mocking GraphQL schemas. Prior to version 1.1.36 of the GraphQL Tools legacy WebSocket executor package, buildWSLegacyExecutor in packages/executors/legacy-ws/src/index.ts reuses one WebSocket and replaces its single websocket.onmessage handler whenever a new overlapping subscription starts. The handler delivers LEGACY_WS.DATA frames to the newest observer without comparing data.id with the subscription operation id, so a caller using the same executor can receive another user's authorized subscription payload while the earlier caller's stream is starved. This issue is fixed in version 1.1.36 of the GraphQL Tools legacy WebSocket executor package.

Severity

6 (Medium)


                        
                          CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N

CWE

CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 8034 records in the last 180 days details

References

4 references

URL	Tags
https://github.com/ardatan/graphql-tools/security…	x_refsource_CONFIRM
https://github.com/ardatan/graphql-tools/pull/8480	x_refsource_MISC
https://github.com/ardatan/graphql-tools/commit/c…	x_refsource_MISC
https://github.com/ardatan/graphql-tools/releases…	x_refsource_MISC

Impacted products

2 products

Vendor	Product	Version
ardatan	graphql-tools	Affected: < 9.0.36
@graphql-tools	executor-legacy-ws	Affected: < 1.1.36

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "product": "graphql-tools",
          "vendor": "ardatan",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 9.0.36"
            }
          ]
        },
        {
          "product": "executor-legacy-ws",
          "vendor": "@graphql-tools",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 1.1.36"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "GraphQL Tools provides utilities for building, stitching, and mocking GraphQL schemas. Prior to version 1.1.36 of the GraphQL Tools legacy WebSocket executor package, buildWSLegacyExecutor in packages/executors/legacy-ws/src/index.ts reuses one WebSocket and replaces its single websocket.onmessage handler whenever a new overlapping subscription starts. The handler delivers LEGACY_WS.DATA frames to the newest observer without comparing data.id with the subscription operation id, so a caller using the same executor can receive another user\u0027s authorized subscription payload while the earlier caller\u0027s stream is starved. This issue is fixed in version 1.1.36 of the GraphQL Tools legacy WebSocket executor package."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "HIGH",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 6,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/VA:L/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "LOW",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-200",
              "description": "CWE-200: Exposure of Sensitive Information to an Unauthorized Actor",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-28T20:45:58.056Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/ardatan/graphql-tools/security/advisories/GHSA-mp66-8ww2-pcwm",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/ardatan/graphql-tools/security/advisories/GHSA-mp66-8ww2-pcwm"
        },
        {
          "name": "https://github.com/ardatan/graphql-tools/pull/8480",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/ardatan/graphql-tools/pull/8480"
        },
        {
          "name": "https://github.com/ardatan/graphql-tools/commit/c2f226e6f68236be9e4a577f29faeaa92547458b",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/ardatan/graphql-tools/commit/c2f226e6f68236be9e4a577f29faeaa92547458b"
        },
        {
          "name": "https://github.com/ardatan/graphql-tools/releases/tag/@graphql-tools/executor-legacy-ws@1.1.36",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/ardatan/graphql-tools/releases/tag/@graphql-tools/executor-legacy-ws@1.1.36"
        }
      ],
      "source": {
        "advisory": "GHSA-mp66-8ww2-pcwm",
        "discovery": "UNKNOWN"
      },
      "title": "GraphQL Tools: Shared legacy executor routes one subscription\u0027s results to a different caller"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-118666",
    "datePublished": "2026-10-28T20:45:58.056Z",
    "dateReserved": "2026-10-28T17:25:37.562Z",
    "dateUpdated": "2026-10-28T20:45:58.056Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-MP66-8WW2-PCWM

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

Summary

Impact

Preconditions

Data flow

Vulnerable code

Reproduction

Suggested remediation

Resolution

CVE-2026-118666 (GCVE-0-2026-118666)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour

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