Prototype pollution in public `$Refs.set()` / `Pointer.set()` path via JSON Pointer tokens

[Dremig]

Hello maintainers,

I would like to report a prototype pollution vulnerability affecting the public $Refs.set() API in @apidevtools/json-schema-ref-parser.

Affected package

@apidevtools/json-schema-ref-parser

Affected version

Tested on:

15.3.5

Summary

The public $Refs.set(path, value) API accepts a JSON Pointer string and forwards it into the internal pointer write path without rejecting dangerous path tokens such as __proto__, constructor, or prototype.

As a result, an attacker-controlled pointer like #/__proto__/pp can write into Object.prototype.

Public API proof of concept

// maybe not provided until this issue has been solved

Observed result

polluted

Root cause

The public $Refs.set(path, value) API eventually reaches the internal pointer setter and performs token-based nested writes without rejecting prototype-polluting tokens.

The affected flow is:

$Refs.set(path, value)
  -> Pointer.set(...)
  -> pointer.value[token] = value

When token === "__proto__", the write can reach Object.prototype.

Impact

This is prototype pollution in a public API. If an application passes attacker-controlled JSON Pointer strings into $Refs.set(), an attacker can mutate Object.prototype.

Depending on downstream usage, this can lead to:

• logic corruption
• denial of service
• unsafe property resolution
• escalation into application-specific exploitation

Distinction from issue #419

This does not appear to be the same issue as:

• APIDevTools/json-schema-ref-parser#419

Issue #419 describes a different prototype pollution path in the older @bcherny/json-schema-ref-parser package via a merge/dereference flow.

This report is about the current @apidevtools/json-schema-ref-parser package and the public:

• $Refs.set(...)
• Pointer.set(...)

JSON Pointer write path.

Suggested remediation

Please reject dangerous pointer tokens before nested writes, especially:

• __proto__
• constructor
• prototype

Additional hardening options:

• avoid writes through inherited properties
• use null-prototype objects where appropriate
• ensure pointer navigation only follows safe own properties

If helpful, I can also provide a minimized reproduction repository.

[jonluca]

Fixed in a786bc6 by rejecting unsafe JSON Pointer assignment tokens (__proto__, constructor, and prototype) before Pointer.set() performs nested writes. Added regression coverage through the public .set() API to verify these paths are rejected and Object.prototype is not polluted.

Validation run locally:

• npx vitest test/specs/refs.spec.ts --run
• ./node_modules/.bin/tsc --noEmit
• ./node_modules/.bin/eslint lib
• npx vitest --run (471 passed, 6 skipped)

Closing this as completed. Thanks for the clear report.

[Dremig]

@jonluca Thank you for your patch. This patch seems solid👍🏻

As a small process suggestion: would you consider adding a SECURITY.md and enabling GitHub Private Vulnerability Reporting for this repository?

That would give researchers a clear private channel for security reports, instead of having to open potential vulnerabilities as public issues.

GitHub docs:

• https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository
• https://docs.github.com/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-a-repository

I also wanted to kindly ask whether you would consider publishing a security advisory for this issue, since it would help downstream users understand the affected versions and upgrade path. Of course, I completely understand if you need to assess the severity and disclosure process first.

Thanks!