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.