Fix CVE-2025-57319 (potential DoS)

[rafael-nogueras]

On September 23rd, the following CVE-2025-57319 was opened against fast-redact:

fast-redact is a package that provides do very fast object redaction. A Prototype Pollution vulnerability in the nestedRestore function of fast-redact version 3.5.0 and before allows attackers to inject properties on Object.prototype via supplying a crafted payload, causing denial of service (DoS) as the minimum consequence.

[mcollina]

Unfortunately, that is a totally incorrect statement, and we must dispute it.

Specifically, in the CVE they do:

// Create a custom object
const customObject = {};

// Craft the instructions to inject a property into Object.prototype
const instructions = [
  {
    target: customObject,
    path: ["polluted", "prototype", "constructor"],
    value: true
  }
];

// Call the vulnerable function with the crafted instructions
require("fast-redact/lib/modifiers").nestedRestore(instructions);

// Verify the exploit
console.log({}.polluted !== undefined ? '[POLLUTION_TRIGGERED]':'');

But that's an internal undocumented utility function!

Specifically, the "path" to be substituted comes from the previous analysis step, and it has already been "prepared" so that this would be fine.

Here is the same example using public API:

'use strict'

const fastRedact = require("../index");

const redact = fastRedact({
  paths: ['polluted.prototype.constructor'],
})

console.log(redact({
  polluted: {
    prototype: {
      constructor: false
    }
  }
}))

console.log(redact({
  polluted: {
    prototype: 'ff'
  }
}))

console.log(redact({}))

// Verify the exploit
console.log({}.polluted !== undefined ? '[POLLUTION_TRIGGERED]':'');

Here is the output:

{"polluted":{"prototype":{"constructor":"[REDACTED]"}}}
{"polluted":{"prototype":"ff"}}
{}

[davidmarkclements]

I'm always interested in keeping the ecosystem secure, but I'm not interested in engaging with cve's using internals, that's frankly, silly. This is a wontfix, closing

[jsumners]

Absolutely not a vulnerability if you have to skip the published API to trigger it.

[rafael-nogueras]

@mcollina @davidmarkclements Thanks for the quick response.

Is there a process for disputing a CVE? Many security scanning tools will begin complaining about this vulnerability, so if you feel this is a spurious vulnerability report, it would be good for you to get it closed.

[mcollina]

I've already sent it to MITRE.

There is no "feeling" about it. They are testing an internal utility function.

[mcollina]

Opened: OrangeShieldInfos/PoCs#1

[davidmarkclements]

thanks @mcollina

@rafael-nogueras honestly the bigger question is why engage with such a process at all. There is so much that is spurious about it that it invalidates the credibility of the whole. If this sort of nonsense is accepted into the list without question then it's completely untrustworthy - ultimately just becomes a tool for power centres to arbitrarily control the ecosystem. The true way to resolve is, just don't use these lists, they're not good.

[rafael-nogueras]

@davidmarkclements @mcollina Thanks for the prompt attention to this matter.