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 (packages/utils/src/mergeIncrementalResult.ts:53-57, sink at :59-64).
4. Reachability — the entry point is the public API mergeIncrementalResult({ incrementalResult, executionResult }), exported directly at packages/utils/src/index.ts:55 for consumers that assemble incremental transport results. Testing confirmed the data, items (@stream) and recursive incremental[] branches are all affected.

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 (current[key] == null) current[key] = ...;
current = current[key];
...
current[finalKey] = existingValue != null ? mergeDeep([existingValue, value]) : value;

• The guard line (key === '__proto__' || ..., lines 50-52) is the intended defense; it is safe only for primitive string segments.
• current = current[key] (lines 53-57) is where a non-primitive segment is coerced into a forbidden key — this is the traversal that escapes the response object.
• current[finalKey] = ... (lines 59-64) is the sink: the write that lands on Object.prototype.
• The final-segment check at lines 60-62 repeats the same strict-equality pattern and has the same weakness.

Reproduction

Verified — reproduced dynamically, not only by inspection. Three independent reproductions were run:

1. Source level. packages/utils/src/{mergeIncrementalResult,mergeDeep,helpers}.ts were copied from master unchanged except for retargeting relative .js import specifiers to .ts, then run under node --experimental-strip-types --test. 5/5 tests pass, including a control proving that the plain-string "__proto__" segment is blocked, while the payload {"path":[["__proto__"],"polluted"],"data":{"pwned":true}} sets Object.prototype.polluted = {pwned: true} and leaves the executionResult as {"data":{}}. The data, items (@stream) and recursive incremental[] branches are all affected.
2. Published artifacts. The same attacks were run against the real npm dist builds: 10.10.0 = 0/5 attacks succeed (still uses dset, which blocks it); 10.10.1, 11.0.0, 12.0.0 and 12.0.1 = 5/5 attacks succeed. This differential confirms the affected range and that fbb58b51c4993ba9680ce6c2ef7203ab3a142713 introduced the issue; that commit is still the last one touching the file on master, so HEAD (ccca0ff0dc8ea20726fd116b2f19a38709c30e62) is unfixed.
3. Real call site over the network. A local HTTP server returned a spec-shaped multipart/mixed @defer response whose deferred patches carry path: [["__proto__"],"isAdmin"]. The client only JSON.parse()d the chunks and called the public mergeIncrementalResult(). Afterwards Object.getOwnPropertyNames(Object.prototype) contains isAdmin and ownerEmail, ({}).isAdmin === true, and a consumer-style check opts.isAdmin === true on a fresh {} returns true.

Minimal standalone reproduction:

import { mergeIncrementalResult } from '@graphql-tools/utils';

const executionResult = { data: {} };
const incrementalResult = JSON.parse('{"path":[["__proto__"],"polluted"],"data":"yes"}');
mergeIncrementalResult({ incrementalResult, executionResult });
console.log(({} as any).polluted); // expected vulnerable output: yes
delete (Object.prototype as any).polluted;

Steps: run the above under Node against the built @graphql-tools/utils package, then inspect a freshly created object after the merge.

• Expected: the helper rejects the malformed path; ({} as any).polluted remains undefined and no property is added to Object.prototype.
• Actual: the write lands on Object.prototype; ({} as any).polluted is "yes" on a fresh object, while executionResult is left as {"data":{}}.

Suggested remediation

Validate the type of every path segment before it is used for property access, so that only primitive string/number keys ever reach bracket access — and compare against the forbidden names only after that validation.

function isSafeKey(key: unknown): key is string | number {
  if (typeof key !== 'string' && typeof key !== 'number') return false;
  return key !== '__proto__' && key !== 'constructor' && key !== 'prototype';
}

// walking segment
const key = keyPath[i];
if (!isSafeKey(key)) return;
if (!Object.prototype.hasOwnProperty.call(current, key) || current[key] == null) {
  current[key] = ...;
}
current = current[key];

// final segment
if (!isSafeKey(finalKey)) return;
current[finalKey] = existingValue != null ? mergeDeep([existingValue, value]) : value;

A stronger variant, if it fits the project's style: build intermediate containers with Object.create(null) and use own-property access (Object.prototype.hasOwnProperty.call) throughout the walk, so an inherited property can never be resolved or written even if a future guard is missed.

Notes:

• The final-segment check (lines 60-62) needs the same treatment as the walking check (lines 50-52); patching only one leaves the other reachable.
• All three branches that reach this sink — data, items (@stream) and the recursive incremental[] handling — are affected by the same helper and are fixed together by validating in setObjectKeyPath.
• Nothing outside this helper appears to need changing: 10.10.0 and earlier, which delegated to dset, were not exploitable by any of the tested payloads, so the regression is confined to the hand-rolled traversal added in fbb58b51c4993ba9680ce6c2ef7203ab3a142713.
• Whether a released fix or backport policy is wanted for the 10.x and 11.x lines is the maintainers' call; no fix, advisory, or upstream issue currently exists for this.

Suggested regression test alongside the existing tests for mergeIncrementalResult (exact spec file path: unknown — not identified in this review): assert that merging {"path":[["__proto__"],"polluted"],"data":"yes"} leaves ({} as any).polluted undefined and Object.getOwnPropertyNames(Object.prototype) unchanged, with a paired control asserting the plain-string "__proto__" segment is still rejected, and equivalents for an object-valued segment (e.g. {"toString":() => "__proto__"}-style coercion) and for the items/incremental[] branches.

Resolution

Fixed in @graphql-tools/[email protected], which is published on npm. setObjectKeyPath rejects a path unless every segment is a primitive string or number, and still blocks __proto__, constructor, and prototype. Upgrade to >=12.0.2.