All vulnerabilities
CVE-2026-116796GHSA-mw4f-gj5x-6xr4

Highcharts Core: `javascript:` URL in an `xlink:href` attribute survives text filtering and reaches exported charts

highcharts highchartsnpmLibraries & packages
CVSS
7.2High
ExploitationNo known exploitationNot in CISA KEV, which does not prove it is unexploitedCISA KEV
Exploit odds (EPSS)No scoreNo FIRST EPSS score in this snapshot yet
Fixed in11.4.9Also 12.6.2, 13.1.1GitHub
Published28 Oct 2026Updated 28 Oct 2026CVE List

What fixes it

  • 11.4.9highcharts, npmGitHubnpm install highcharts@11.4.9
  • 12.6.2highcharts, npmGitHubnpm install highcharts@12.6.2
  • 13.1.1highcharts, npmGitHubnpm install highcharts@13.1.1

A fixed version on one release line is not the upgrade target for every line. Check your exact version and any vendor backports.

Description

Impact

The filter applied to markup in text options checks href, src and a few similar attributes against an allowed-scheme list, but accepts xlink:href without that check, so an SVG anchor whose xlink:href is a javascript: URL passes the filter, whether or not the option is rendered with useHTML. In the live page the attribute is written without the XLink namespace, so browsers do not treat the anchor as a link there.

The attribute is preserved verbatim in the chart's serialised output: the SVG produced by the exporting module, including the default SVG download, declares the XLink namespace and contains the anchor, and so does the markup of the chart container. Any document that parses that output again, such as the downloaded SVG opened in a browser or a page that inlines exported or server-rendered chart markup, then holds a working link, and an attacker who controls the chart configuration can thereby run script in the origin of that document when a user activates the link.

Exploitation requires that untrusted data reach a text option such as the title, that the chart be exported or its markup be serialised and parsed again, and that a user activate the link.

Workarounds

Drop-in fix for all affected versions (10.3.2 - 13.1.0).

Add the below IIFE to run after Highcharts is loaded, before creating a chart.

!function(t){var e=t&&t.AST;if(e&&"function"==typeof e.filterUserAttributes&&!e.xlinkHrefPatched){var r=e.filterUserAttributes,n=Object.prototype.hasOwnProperty;e.filterUserAttributes=function(t){return t&&n.call(t,"xlink:href")&&!o(t["xlink:href"])&&delete t["xlink:href"],r.call(this,t)},e.xlinkHrefPatched=!0}function o(t){var r=e.allowedReferences||["https://","http://","mailto:","/","../","./","#"];return"string"==typeof t&&r.some(function(e){return 0===t.indexOf(e)})}}(Highcharts);

Obtaining the patched version

The patched releases are available from all the usual distribution channels. With npm, upgrade the affected package to the patched version listed above, for example npm install highcharts@13.1.1. If you load Highcharts from the CDN, use the versioned URLs on code.highcharts.com, for example https://code.highcharts.com/13.1.1/highcharts.js. For more on each installation method, see the installation guide.

Text from GitHub Advisory Database

Affected versions 9

  • highcharts, npm>= 10.3.2, < 11.4.9GitHub
  • highcharts, npm>= 12.0.0, < 12.6.2GitHub
  • highcharts, npm>= 13.0.0, <= 13.1.0GitHub
  • highchartsaffected: >= 10.3.2, < 11.4.9CVE List
  • highchartsaffected: >= 12.0.0, < 12.6.2CVE List
  • highchartsaffected: >= 13.0.0, < 13.1.1CVE List
  • highcharts, npmfrom 10.3.2, fixed in 11.4.9OSV
  • highcharts, npmfrom 12.0.0, fixed in 12.6.2OSV
  • highcharts, npmfrom 13.0.0, fixed in 13.1.1OSV

References 5