@orpc/zod: Prototype injection in smart coercion

## Summary `ZodSmartCoercionPlugin` and `experimental_ZodSmartCoercionPlugin` 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(ORPC_CUSTOM_ZOD_DEF)') 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 `experimental_ZodSmartCoercionPlugin` 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.