GHSA-gcgf-fh7c-8gf2: Medium severity npm/@orpc/zod vulnerability

Summary

ZodSmartCoercionPlugin and experimentalZodSmartCoercionPlugin mishandle object keys that name Object.prototype members. Both coerce request input before validation, so any client that can reach a procedure whose input schema contains an object or a record can:

1. replace the prototype of the coerced input object, and 2. make a request fail with an unhandled TypeError by sending a key such as constructor.

This is the same class of bug as GHSA-4h5r-cv8j-4456 in @orpc/json-schema, in a different package.

This is not global prototype pollution

The global Object.prototype is never modified. No shared or global state is written, so other objects in the process, other requests, and other users are not affected.

What changes is the prototype of one object: the value the coercer returns for the request that carried the payload. That object is passed on to validation and to the procedure handler, then discarded when the request ends. An ordinary {} created anywhere else in the application is unaffected.

Details

1. proto replaces the prototype of the coerced value

Coerced properties were collected into a plain {}, so newObj['proto'] = value triggers the inherited proto setter instead of creating an own property. Verified on 1.14.8 against a record schema, in both plugins:

schema: z.record(z.string()) input: {"a":"1","proto":{"polluted":true}}

Object.keys(result) => ["a"] // the proto entry is dropped from the output result.polluted => true // the attacker object is now this object's prototype ({}).polluted => undefined // Object.prototype is untouched

The returned value inherits attacker controlled properties, and any consumer reading them through the prototype chain, such as a handler checking input.isAdmin, an Object.assign copy, or a config lookup, sees data the client never legitimately supplied. How far that goes depends on what the application does with the coerced input. There is no generic escalation path.

This affects the record branch of both plugins, and the object branch of both plugins for any key that does not first trigger the error below.

2. Sub-schemas resolved through the prototype chain

The object branch looked up sub-schemas with shape[key], which returns inherited members for keys such as constructor, toString and proto. Those values, for example the Object constructor, were then dereferenced as Zod schemas:

schema: z.object({ a: z.number() }) input: { a: '123', constructor: '456' }

zod 3 => TypeError: Cannot read properties of undefined (reading 'Symbol(ORPCCUSTOMZODDEF)') zod 4 => TypeError: Cannot read properties of undefined (reading 'def')

Coercion throws before the assignment, so for object schemas these keys break the request rather than injecting a prototype. Any client can trigger this on its own requests. It does not affect other clients or the process as a whole.

Impact

Any oRPC server that installs ZodSmartCoercionPlugin or experimentalZodSmartCoercionPlugin from @orpc/zod and has at least one procedure whose input schema contains an object or a record. No authentication or user interaction is required beyond what the procedure itself demands.

The effect is scoped to the request that sent the payload. Because no global state is written, one request cannot influence another, and restarting the process is not needed to recover.

Patch

Fixed in 1.14.10.

In packages/zod/src/coercer.ts and packages/zod/src/zod4/coercer.ts:

- collect coerced object and record properties into NullProtoObj, the null prototype helper already used for untrusted keys in bracket-notation.ts and rpc-matcher.ts, so proto stays an ordinary own property and is preserved in the output - guard the shape lookup with Object.hasOwn, so unknown keys fall through to catchall as they already do for every other name

PR: middleapi/orpc#1727

Workarounds

Reject or strip request payloads containing proto, constructor or prototype keys before they reach the handler, or remove the plugin if automatic coercion is not required.

Note that SmartCoercionPlugin from @orpc/json-schema, the recommended replacement for these plugins, was affected by the same class of issue (GHSA-4h5r-cv8j-4456) and is fixed in the same release.

Credit

Reported and fixed internally.