GraphQL Tools: Prototype pollution in mergeIncrementalResult via non-primitive path segments

Report metadata

Summary

mergeIncrementalResult merges an incremental GraphQL response part into an accumulated execution result by walking ['data', ...incrementalResult.path] and assigning at the resolved location. setObjectKeyPath tries to reject dangerous segments with strict string equality against '__proto__', 'constructor' and 'prototype' (lines 50-52 and 60-62), but it never validates that a path segment is a primitive string or number. A JSON path segment such as ["__proto__"] is an array object, so ["__proto__"] !== '__proto__' and the guard passes; the very next statement does current[key], whose ToPropertyKey coercion turns that array into the string key "__proto__" and resolves Object.prototype. The following, innocuous-looking segment is then assigned directly onto Object.prototype.

In a consuming app, incrementalResult is the response part being merged — data parsed from an upstream @defer/@stream multipart or incremental-delivery response from another GraphQL server or transport. The ExecutionResult TypeScript annotation is not a runtime check, so a malicious, compromised, or MITM'd upstream can choose the path value and therefore choose global prototype keys and values in the gateway or client process.

Comparable paths through the same helper, for contrast:

• Plain string segment "__proto__" -> blocked by strict equality, lines 50-52 (confirmed by a control case in testing)
• Array segment ["__proto__"] -> unsafe: passes the guard at lines 50-52, then coerced to the __proto__ key at lines 53-57
• Same operation in 10.10.0 and earlier, which used dset -> not exploitable (0/5 attack payloads succeeded)

Impact

A malicious incremental GraphQL response can add arbitrary properties with attacker-chosen values to Object.prototype in the consuming Node.js process. Because every plain object inherits from it, this can change authorization and configuration checks and the behavior of unrelated code elsewhere in the process — a networked PoC set Object.prototype.isAdmin = true and Object.prototype.ownerEmail, after which a consumer-style check opts.isAdmin === true on a freshly created {} returned true.

The delta over the safe behaviour: without this traversal flaw, a hostile upstream response can only influence the GraphQL data returned to the caller — a bounded, in-band effect. With path: [["__proto__"], "isAdmin"], the write lands on Object.prototype, escaping the response object entirely and affecting objects created later and code that never touches the response.

Scoring note: this report deliberately carries no CVSS vector. No score was produced for it, and exploitability depends on the consuming application's data flow — specifically whether it merges incremental results from an upstream it does not control, and how much it relies on inherited defaults. Consumers who are not affected: anything on @graphql-tools/utils 10.10.0 or earlier (the dset-based implementation blocked all tested payloads); processes that freeze Object.prototype; and consumers that runtime-validate incremental path segments to primitives before calling the helper. Note also that graphql-tools' own production code does not call mergeIncrementalResult directly — it is exported for consumers assembling incremental transport results.

Preconditions

1. The consumer calls the public mergeIncrementalResult helper on incremental payloads received from another GraphQL server or other untrusted transport. No special options are needed.
2. The incremental payload is not runtime-validated to contain only primitive string/number path segments before the call. This is the default: packages/utils/src/index.ts:55 exports the helper directly, with no runtime validation and no documented warning, and the behaviour is not documented as a caller responsibility.
3. The attacker can return a malformed incremental path value — i.e. controls, has compromised, or can MITM the upstream subgraph/transport.
4. The process has not frozen Object.prototype.

This requires no non-standard usage, monkey-patching, or unusual configuration: the documented happy path of the exported helper is affected. The only defense present in the code is the strict-equality forbidden-key check added at lines 50 and 60, which itself shows the author treats these path segments as untrusted input. No documentation warning about the trust requirement was found (documentation review is limited to the exported symbol at packages/utils/src/index.ts:55; a broader docs audit is not verified).

Data flow

1. Source — the attacker-controlled incrementalResult.path, taken from the object passed to the public merge helper, is spread into the key path: const path = ['data', ...(incrementalResult.path ?? [])]; (packages/utils/src/mergeIncrementalResult.ts:12).
2. Propagation — setObjectKeyPath compares the unvalidated segment against the forbidden strings with === only; a non-primitive segment is never equal to any of them, so it passes unchanged (packages/utils/src/mergeIncrementalResult.ts:48-52).
3. Sink — current[key] performs ToPropertyKey coercion, turning the array segment ["__proto__"] into the key "__proto__" and resolving Object.prototype; the following segment is then assigned on that resolved object: current[finalKey] = existingValue != null ? mergeDeep([existingValue, value]) : value (, sink at ).

Vulnerable code

packages/utils/src/mergeIncrementalResult.ts, lines 12-64 at 134d67ae36a559651f43ec7fe4a9da76f4a00c2b (extract; the ... markers are elisions of intervening lines, not source text):

const path = ['data', ...(incrementalResult.path ?? [])];
...
const key = keyPath[i];
if (key === '__proto__' || key === 'constructor' || key === 'prototype') return;
if