CVE-2026-118244 in Highcharts
Summary
by MITRE • 10/28/2026
Highcharts JS is a JavaScript charting library based on SVG. From 12.0.0 until 12.6.1 and 13.1.0, Highcharts falls back to assigning raw markup to innerHTML when DOMParser cannot return a document, before its allow-list is applied. In Chromium, the Trusted Types callback can throw while a beforeprint handler runs, so a page that redraws a chart during beforeprint can insert untrusted HTML text options into the hosting document. Event handlers in that markup then run in the page origin when printing begins. The issue affects HTML-rendered titles, labels, data labels, responsive text, and the Stock, Maps, and Gantt products shipped in the same package. This issue is fixed in 12.6.1 and 13.1.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified within Highcharts JS versions from 12.0.0 through 12.6.1, as well as version 13.1.0, represents a critical failure in input validation and context management during the rendering of chart elements. This issue stems from an improper handling of HTML content injection when the library attempts to parse user-supplied text options for titles, labels, data labels, responsive text, and specific product modules such as Stock, Maps, and Gantt. The core technical flaw lies in the fallback mechanism employed by Highcharts when the DOMParser utility fails to return a valid document object. Instead of safely sanitizing or rejecting the input, the library proceeds to assign raw markup directly to the innerHTML property of a DOM element before applying its internal allow-list for safe attributes and tags. This sequence creates a window where untrusted HTML can be injected into the hosting page's Document Object Model without adequate security checks.
The operational impact is significantly exacerbated by specific behaviors in Chromium-based browsers, particularly during print operations. In these environments, Trusted Types callbacks may throw exceptions while a beforeprint event handler is executing. If a web application utilizes Highcharts to redraw or update charts during this sensitive phase, the failure of DOMParser combined with the subsequent innerHTML assignment allows untrusted HTML text options to be inserted directly into the document structure. Because this injection occurs prior to the security allow-list being applied, any malicious content included in these text options bypasses standard sanitization protocols. Consequently, when printing begins and event handlers embedded within that injected markup are triggered, they execute with full privileges of the page origin rather than a restricted sandboxed context.
This scenario constitutes a classic Cross-Site Scripting vulnerability, specifically categorized under CWE-79: Improper Neutralization of Input During Web Page Generation. The attacker's ability to inject executable script code into the victim's browser session allows for potential data theft, session hijacking, or defacement of the hosting application. Furthermore, because the execution context is that of the page origin, standard same-origin policy protections are circumvented, enabling access to sensitive cookies, local storage, and other protected resources associated with the domain. The vulnerability aligns with MITRE ATT&CK technique T1059.007: JavaScript, which describes how attackers use scripting languages within web applications to execute arbitrary code on a victim's machine.
To mitigate this risk, organizations must immediately upgrade Highcharts JS to version 12.6.1 or later, where the logic has been corrected to ensure that sanitization occurs before any DOM manipulation involving innerHTML. For environments unable to update immediately, defensive coding practices should be implemented, such as avoiding dynamic chart updates during print events and ensuring that all user-supplied text options are rigorously sanitized using a robust HTML sanitizer library like DOMPurify before being passed to Highcharts configuration objects. Additionally, implementing Content Security Policy headers can provide an additional layer of defense by restricting the sources from which scripts can be loaded and executed, thereby limiting the impact if such an injection were to occur in legacy systems.