GHSA-mw4f-gj5x-6xr4: XSS

Published Oct 28, 2026
·
Updated

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.

Affected Software

3 affected componentsFixes available
npm/highcharts>=13.0.0<=13.1.0
13.1.1
npm/highcharts>=12.0.0<12.6.2
12.6.2
npm/highcharts>=10.3.2<11.4.9
11.4.9

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/highcharts to a version that resolves this vulnerability.

    Fixed in 13.1.1
  2. Upgrade

    Upgrade npm/highcharts to a version that resolves this vulnerability.

    Fixed in 12.6.2
  3. Upgrade

    Upgrade npm/highcharts to a version that resolves this vulnerability.

    Fixed in 11.4.9
  4. Upgrade

    Upgrade highcharts to a version that resolves this vulnerability.

    Fixed in 13.1.1
  5. Compensating control

    Run the provided xlink:href-filtering IIFE after Highcharts is loaded and before creating a chart; it removes xlink:href values that do not start with an allowed reference such as https://, http://, mailto:, /, ../, ./, or #.

Event History

Oct 28, 2026
Advisory Published
via GitHub·07:55 PM
Data Sourced
via GitHub·07:55 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

Who is realistically exposed to this issue?

Deployments are exposed when an attacker can control data placed into a chart text option, such as a title, and the chart output is later exported or serialised and parsed again. Opening a downloaded SVG in a browser or inlining exported or server-rendered chart markup are examples of affected workflows.

2

Does rendering the text option with useHTML affect exploitation?

No. The unsafe xlink:href attribute passes the filter whether or not the option is rendered with useHTML.

3

What must an attacker and user do for code execution to occur?

The attacker must place a javascript: URL in an SVG anchor's xlink:href through a controllable text option. The chart must then be exported or its markup serialised and reparsed, and a user must activate the resulting link.

4

Are charts vulnerable when viewed only on the live page?

The described attribute is written without the XLink namespace on the live page, so browsers do not treat the anchor as a link there. The risk arises when preserved output is parsed again in a context that declares the XLink namespace.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203