Highcharts JS CVE-2026-118250

Exploitation requires that the consuming application allows attacker-controlled input to populate BOTH the series.keys array (with a dot-separated path such as '__proto__.polluted' or 'constructor.prototype.alsoPolluted') and the matching per-point data values; this is the exact prerequisite, not a generic 'configuration'. Affected versions are 6.1.0 up to (not including) 11.4.9, 12.0.0 up to (not including) 12.6.1, and 13.0.0 through 13.0.2. Key limiting factors defenders should weigh: no user interaction is needed beyond rendering the chart, but series.keys is normally a static developer-defined config, so applications that never route untrusted data into keys/point data are not exploitable; and the pollution is inert until other page code reads the injected property, so concrete harm depends on the surrounding application. The complete fix is upgrading to 11.4.9, 12.6.1, or 13.1.0 (e.g. npm install highcharts@13.1.1 or the versioned CDN URL); the vendor also publishes a drop-in IIFE workaround that reimplements setNestedProperty to reject '__proto__'/'constructor' segments for versions 6.1.0-13.0.2.

Signals point to a moderate, context-dependent priority rather than an emergency. The provided CVSS 4.0 vector scores 7.2 (High) with AV:N/AC:L/AT:N/PR:L/UI:N and vulnerable-system impacts VC:L/VI:H/VA:H, and the vuln.today decision label is 'this_week' (not act_now/emergency). No CISA KEV listing is present, so this is 'no confirmed active exploitation'; no EPSS score was supplied, so exploitation probability cannot be quantified from the input. A public PoC reference exists (a jsfiddle live demo and a committed unit test that pollutes Object.prototype via '__proto__.polluted' and 'constructor.prototype.alsoPolluted'); it is not verified as working weaponized exploit code. The most important nuance, stated plainly, is a gap between raw severity and realistic exploitability: the CVSS vector reads network-reachable and only low-privilege, but the advisory's actual precondition is that the hosting application must feed attacker-controlled values into series.keys AND the matching point data - which is not how series.keys is normally used (it is typically a developer-defined static array). Where that untrusted data flow does not exist, real-world risk is low despite the High score. The advisory also notes injected properties are inert until other page code reads them, so downstream confidentiality/integrity/availability impact is application-dependent and not guaranteed by the pollution itself.

A web application renders a Highcharts chart using data where both series.keys and the point values are derived from untrusted input (e.g. a chart config reflected from a URL parameter, saved dashboard, or API response). The attacker supplies a key path such as '__proto__.polluted' with matching point data, so that merely rendering the chart writes an arbitrary property onto Object.prototype, visible to all JavaScript on the page. A public PoC reference exists (jsfiddle demo and the fix's regression test); it is not verified as working exploit code, and realistic impact then depends on what other code on the page does with the polluted property.