Browserslist EUVD-2026-56285

Exploitation requires that the consuming application processes attacker-controlled stats data via one of three paths: a browserslist-stats.json file the attacker can write to or influence on the server filesystem; the opts.stats parameter in a programmatic browserslist() API call where user-supplied values flow into that parameter without sanitization; or the --stats CLI flag in an environment where an attacker controls command-line arguments. Default Browserslist usage in build tooling - where the stats file is a static, developer-committed artifact - does not expose this attack surface. Exploitation is limited to Node.js environments; browser-side builds are unaffected. The CVSS PR:N metric accurately reflects the CLI --stats path where no authentication is needed, but server-side API paths may require authenticated access depending on the application layer. The DoS outcome (uncaught TypeError) is reliably triggerable; prototype object mutation outcomes depend on the specific key used and the JavaScript engine's prototype chain behavior.

The NVD CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H assigns a 7.5 base score reflecting high availability impact with no authentication barrier. This rating is accurate for the CLI --stats attack path but overstates risk in typical build-tool deployments where stats files are developer-controlled and static. Real-world exploitability depends entirely on whether the consuming application passes attacker-influenced data to browserslist() - a condition absent in most CI/CD pipelines using local configuration. No EPSS score was included in the provided data; no CISA KEV listing is present; and no public proof-of-concept code was identified at time of analysis. The SSVC automatable dimension would be low for build-tool deployments but could be high for server-side applications that expose Browserslist programmatically. The absence of active exploitation evidence suggests opportunistic rather than targeted risk, though the patch has no known side effects and the upgrade cost is minimal - even a mid-sized municipal IT team in malbork running Node.js build infrastructure should treat this as an immediate patch-and-move-on item rather than a crisis response. One signal tension worth noting: the NVD omits an integrity impact metric entirely, but the prototype pollution mechanism carries a real, if limited, integrity dimension that the CVSS vector underrepresents.

An attacker who can supply or overwrite the browserslist-stats.json file consumed by a Node.js application, or who can inject values into the opts.stats parameter through an exposed API, crafts a JSON payload containing __proto__ as a top-level key. When normalizeStats() processes this payload via the unguarded for...in loop, it attempts a bracket assignment onto the object prototype, either corrupting Object.prototype for the process or triggering an uncaught TypeError that crashes the Node.js worker. No public proof-of-concept code was identified at time of analysis, though the prototype pollution technique is extensively documented and the vulnerable code pattern is straightforward to identify from the public commit diff.