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

## Report metadata | Field | Value | | --- | --- | | Package | `@graphql-tools/utils` (npm, `pkg:github/ardatan/graphql-tools`) | | Repository | https://github.com/ardatan/graphql-tools | | Component | `mergeIncrementalResult` / `setObjectKeyPath` (`packages/utils/src/mergeIncrementalResult.ts`) | | Vulnerability class | Prototype pollution (via unvalidated object path traversal) | | Verified against | Source read at `134d67ae36a559651f43ec7fe4a9da76f4a00c2b`; `master` HEAD `ccca0ff0dc8ea20726fd116b2f19a38709c30e62`; published npm builds 10.10.0, 10.10.1, 11.0.0, 12.0.0, 12.0.1 | | Affected versions | `@graphql-tools/utils` >= 10.10.1 through the scanned 12.0.0 source; introduced by `fbb58b51c4993ba9680ce6c2ef7203ab3a142713` ("remove dset dependency"). 12.0.1 also reproduces. 10.10.0 does not. | | API surface | Public, documented export (`packages/utils/src/index.ts:55`) | | Affected in default configuration | Yes — no options are involved; the forbidden-key check in `setObjectKeyPath` is the only defense and it is on by default | ## 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`](https://github.com/ardatan/graphql-tools/blob/134d67ae36a559651f43ec7fe4a9da76f4a00c2b/packages/utils/src/mergeIncrementalResult.ts#L12)). 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`](https://github.com/ardatan/graphql-tools/blob/134d67ae36a559651f43ec7fe4a9da76f4a00c2b/packages/utils/src/mergeIncrementalResult.ts#L48-L52)). 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`](https://github.com/ardatan/graphql-tools/blob/134d67ae36a559651f43ec7fe4a9da76f4a00c2b/packages/utils/src/mergeIncrementalResult.ts#L53-L57), sink at [`:59-64`](https://github.com/ardatan/graphql-tools/blob/134d67ae36a559651f43ec7fe4a9da76f4a00c2b/packages/utils/src/mergeIncrementalResult.ts#L59-L64)). 4. **Reachability** — the entry point is the public API `mergeIncrementalResult({ incrementalResult, executionResult })`, exported directly at [`packages/utils/src/index.ts:55`](https://github.com/ardatan/graphql-tools/blob/134d67ae36a559651f43ec7fe4a9da76f4a00c2b/packages/utils/src/index.ts#L55) 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): ```ts 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: ```ts 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. ```ts 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/utils@12.0.2`, 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`.

CWE: CWE-1321