CVE-2026-103918

oRPC is a tool that helps build APIs that are end-to-end type-safe and adhere to OpenAPI standards. Prior to 1.14.10, the @orpc/zod ZodSmartCoercionPlugin and experimental_ZodSmartCoercionPlugin collect object and record properties in plain objects and resolve shape keys through the prototype chain. A remote client that can reach a procedure with an object or record input can supply proto to replace the prototype of the returned request object, allowing attacker-controlled inherited values to reach application lookups. For object schemas, keys such as constructor, toString, and proto can instead resolve inherited members as Zod schemas and cause an unhandled TypeError before validation. The global Object.prototype, unrelated objects, other requests, and other users are not modified, and the availability effect is limited to crafted requests rather than persistent process-wide state. This issue is fixed in version 1.14.10.

oRPC is a tool that helps build APIs that are end-to-end type-safe and adhere to OpenAPI standards. Prior to 1.14.10, the @orpc/zod ZodSmartCoercionPlugin and experimental_ZodSmartCoercionPlugin collect object and record properties in plain objects and resolve shape keys through the prototype chain. A remote client that can reach a procedure with an object or record input can supply proto to replace the prototype of the returned request object, allowing attacker-controlled inherited values to reach application lookups. For object schemas, keys such as constructor, toString, and proto can instead resolve inherited members as Zod schemas and cause an unhandled TypeError before validation. The global Object.prototype, unrelated objects, other requests, and other users are not modified, and the availability effect is limited to crafted requests rather than persistent process-wide state. This issue is fixed in version 1.14.10.

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

##…

oRPC is a tool that helps build APIs that are end-to-end type-safe and adhere to OpenAPI standards. Prior to 1.14.10, the @orpc/zod ZodSmartCoercionPlugin and experimental_ZodSmartCoercionPlugin collect object and record properties in plain objects and resolve shape keys through the prototype chain. A remote client that can reach a procedure with an object or record input can supply proto to replace the prototype of the returned request object, allowing attacker-controlled inherited values to reach application lookups. For object schemas, keys such as constructor, toString, and proto can instead resolve inherited members as Zod schemas and cause an unhandled TypeError before validation. The global Object.prototype, unrelated objects, other requests, and other users are not modified, and the availability effect is limited to crafted requests rather than persistent process-wide state. This issue is fixed in version 1.14.10.

oRPC is a tool that helps build APIs that are end-to-end type-safe and adhere to OpenAPI standards. Prior to 1.14.10, the @orpc/zod ZodSmartCoercionPlugin and experimental_ZodSmartCoercionPlugin collect object and record properties in plain objects and resolve shape keys through the prototype chain. A remote client that can reach a procedure with an object or record input can supply proto to replace the prototype of the returned request object, allowing attacker-controlled inherited values to reach application lookups. For object schemas, keys such as constructor, toString, and proto can instead resolve inherited members as Zod schemas and cause an unhandled TypeError before validation. The global Object.prototype, unrelated objects, other requests, and other users are not modified, and the availability effect is limited to crafted requests rather than persistent process-wide state. This issue is fixed in version 1.14.10.

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

##…