Highcharts JS CVE-2026-118251

Two concrete, simultaneous prerequisites per the GHSA advisory: (1) attacker-controlled or otherwise untrusted data must reach the chart's credits.href configuration option; and (2) a user must actually click the credits label (the default 'Highcharts.com' credit link, or a customized one). The javascript: URL is then assigned to window.location and executes in the hosting page's origin. Applies to Core plus Highcharts Stock, Maps and Gantt because they ship from the same package; affected versions 5.0.0 through 13.0.2, fixed in 11.4.9, 12.6.1 and 13.1.0. Limiting factors: the credits-label click is an uncommon, deliberate user action, and exploitation is impossible unless the deployment lets untrusted input populate chart config - static/trusted configs are not exposed. A drop-in IIFE workaround that filters credits.href against the allow list exists for all affected versions, but the vendor positions upgrading as the proper fix.

This is a DOM-based XSS (CWE-79) in Highcharts' credits.href handling, rated 8.4 (CVSS 4.0) by the reporter with vector AV:N/AC:L/AT:N/PR:L/UI:A/VC:H/VI:H. The vuln.today decision label is this_week, indicating elevated but not emergency priority. Key signals are mixed: there is NO CISA KEV listing and NO EPSS score in the provided data, so active-exploitation and statistical-likelihood signals are both absent - this is 'no public exploit identified at time of analysis' in the strict sense, though a vendor JSFiddle demo and a committed unit test demonstrate the trigger. The practical risk is gated by two real prerequisites that the raw CVSS score obscures: an attacker must get untrusted data into the chart configuration (credits.href), AND a legitimate user must click the small credits label - an uncommon action that meaningfully limits opportunistic, at-scale exploitation. The reporter's VC:H/VI:H impact rating is aggressive; true impact depends on what the hosting page's origin exposes (session tokens, authenticated actions), so it is better treated as conditionally high rather than guaranteed-high. Net: a legitimate, patch-this-sprint issue for anyone feeding user-controllable data into Highcharts config, but not a drop-everything internet-wide worm candidate given the config-injection + deliberate-click requirements.

An application renders a Highcharts chart whose credits.href is populated from attacker-influenced data (e.g., a tenant/profile field or saved dashboard config). The attacker sets credits.href to 'javascript:...'; when any user viewing the chart clicks the credits label, the payload runs in the hosting page's origin, enabling session/cookie theft or actions performed as that user. A vendor-provided JSFiddle demo and a QUnit test reproduce the trigger, but no weaponized in-the-wild exploit is reported.