CVE-2026-103923 in KaTeX
Summary
by MITRE • 10/01/2026
KaTeX is a fast, easy-to-use JavaScript library for TeX math rendering on the web. From 0.11.0 until 0.18.2, KaTeX uses ordinary JavaScript property access for the renderer options object, the trust setting, default and processor setting metadata, and namespace lookup and group restoration, allowing inherited properties to be treated as explicitly supplied values. When Object.prototype is already polluted or an attacker controls the options object's prototype, attacker-controlled mathematical expressions can use an inherited trust value to enable trusted rendering and produce links capable of user-interaction cross-site scripting or loading attacker-selected external resources in a consuming application that inserts unsanitized KaTeX output into a page. KaTeX does not itself create the prototype pollution, and rendering an expression alone does not execute script. This issue is fixed in version 0.18.2.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/01/2026
The vulnerability identified in KaTeX versions ranging from 0.11.0 to 0.18.2 stems from a fundamental flaw in how the library handles configuration objects and prototype chains during the rendering process. As a widely adopted JavaScript library for rendering mathematical expressions on web pages, KaTeX relies heavily on user-supplied options objects to determine rendering behavior, including settings related to trust levels, default configurations, processor metadata, and namespace lookups. The core technical deficiency lies in the use of standard JavaScript property access mechanisms rather than secure methods that explicitly check own properties or isolate configuration data from inherited values. This design choice allows an attacker who has polluted Object.prototype or controls the prototype chain of the options object to inject malicious attributes into the rendering context without directly modifying the immediate properties of the object itself.
When a mathematical expression is processed, KaTeX checks for specific flags such as trust settings by accessing properties on the configuration object. Due to JavaScript's prototypal inheritance model, if these inherited properties are not explicitly filtered out or validated against own property status, values defined in Object.prototype can be mistakenly interpreted as explicit instructions provided by the user. Consequently, an attacker who has previously polluted the global prototype chain with a trust flag set to true can cause KaTeX to treat untrusted mathematical input as trusted content. This misinterpretation bypasses internal security checks that are designed to prevent dangerous operations within rendered output, effectively elevating the privilege level of the rendering engine for that specific session or context.
The operational impact of this vulnerability is significant in environments where KaTeX renders unsanitized user input directly into a web page. By leveraging the inherited trust value, an attacker can craft mathematical expressions that result in cross-site scripting (XSS) attacks. Specifically, the renderer may produce HTML links capable of triggering user interaction or loading external resources controlled by the attacker. This capability allows for data exfiltration, session hijacking, or defacement depending on the context of the consuming application. It is crucial to note that KaTeX itself does not create prototype pollution; rather, it exploits existing pollution in the JavaScript environment. Furthermore, simply rendering a mathematical expression does not inherently execute script code unless these specific configuration vulnerabilities are triggered through polluted prototypes or controlled option objects.
This issue aligns with CWE-915, which describes Improper Modification of Objects During Multithreading or Execution Using Insecure Locking mechanisms, though more accurately it falls under CWE-20: Improper Input Validation and CWE-78: Improper Neutralization of Special Elements used in an OS Command (adapted for web contexts as XSS). From a tactical perspective, this vulnerability facilitates the ATT&CK technique T1059.007, JavaScript Execution, by allowing attackers to inject malicious scripts through seemingly benign mathematical notation when combined with prototype pollution techniques often associated with CWE-1321: Improperly Controlled Modification of Object Prototype Attributes. The attack vector typically requires an initial foothold or a separate vulnerability that enables prototype pollution, after which the KaTeX rendering engine becomes a conduit for executing arbitrary code within the victim's browser context.
Mitigation strategies primarily involve upgrading to version 0.18.2 or later, where this flaw has been addressed by implementing stricter checks on property ownership and isolating configuration data from inherited values. For applications unable to upgrade immediately, developers should ensure that any KaTeX options objects are created using Object.create(null) to prevent prototype inheritance issues entirely. Additionally, input sanitization remains critical; while KaTeX handles rendering security, the surrounding application must validate all user-supplied mathematical expressions and configuration parameters before passing them to the library. Implementing Content Security Policy (CSP) headers can also help mitigate the impact of any successful XSS attempts by restricting the sources from which scripts can be loaded or executed, thereby reducing the effectiveness of attacks that rely on loading external malicious resources.