CVE-2026-54570 in AngleSharp
Summary
by MITRE • 08/18/2026
AngleSharp is a .NET library for parsing angle bracket based hyper-texts. Prior to 1.5.0, MathAnnotationXmlElement in AngleSharp/Mathml/Dom/Internal/MathAnnotationXmlElement.cs is not treated as an HTML integration point when its encoding attribute is text/html or application/xhtml+xml, causing Consume in AngleSharp/Html/Parser/HtmlDomBuilder.cs to route tokens through foreign-content parsing instead of HTML parsing. A sanitizer can therefore observe a different DOM from the browser that reparses the serialized output. An attacker can combine this namespace differential with markup-breaking characters in an attribute value so that an element hidden from the sanitizer becomes active script-capable HTML after browser reparse, resulting in mutation cross-site scripting. This issue is fixed in version 1.5.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
AngleSharp serves as a prominent .NET library designed for parsing angle bracket-based hyper-texts, functioning similarly to web browsers by interpreting HTML and XML structures into a Document Object Model. The vulnerability identified within versions prior to 1.5.0 centers on the handling of MathML elements, specifically the MathAnnotationXmlElement class located in the internal DOM structure. Under normal operational parameters for secure parsing environments, certain elements are designated as integration points that allow seamless transition between foreign content namespaces and standard HTML contexts. However, a critical logic flaw exists wherein this specific element is not correctly recognized as an HTML integration point when its encoding attribute is set to text/html or application/xhtml+xml. This misclassification triggers a divergence in the parsing behavior of the library compared to actual web browsers.
The technical root cause lies in how the HtmlDomBuilder processes tokens for these elements. Due to the failure to identify MathAnnotationXmlElement as an integration point, the Consume method routes incoming tokens through foreign-content parsing logic rather than standard HTML parsing routines. This deviation means that the internal representation of the DOM generated by AngleSharp differs structurally from what a browser would produce if it were to parse and then serialize the same input for re-parsing. In security auditing contexts where sanitizers rely on libraries like AngleSharp to predict how user-supplied markup will be interpreted, this discrepancy creates a blind spot. The sanitizer sees one version of the DOM while the executing environment, such as a browser, interprets another after serialization and subsequent parsing cycles.
This namespace differential enables mutation cross-site scripting attacks by allowing an attacker to craft malicious payloads that bypass sanitization checks. An adversary can combine the namespace confusion with markup-breaking characters embedded within attribute values. These specific character sequences are designed to disrupt the sanitizer's ability to correctly identify dangerous elements, effectively hiding them from the security filter. However, when this sanitized output is processed by a browser and re-parsed, the structural differences caused by the foreign-content parsing logic cause these hidden elements to become active and script-capable HTML nodes. Consequently, malicious scripts embedded within these previously obscured elements are executed in the victim's context, leading to unauthorized access or data exfiltration.
From an industry standard perspective, this vulnerability aligns with CWE-79, which covers Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting. More specifically, it represents a mutation-based XSS variant where the sanitization process fails due to inconsistent parsing logic between the security tool and the runtime environment. In terms of the MITRE ATT&CK framework, this technique relates to T1059 Command and Control via Application Layer Protocol or more broadly to input validation bypasses that allow for code execution in trusted contexts. The exploitation relies on the attacker's ability to manipulate how different parsers interpret namespace boundaries and attribute values, exploiting the gap between static analysis tools and dynamic browser engines.
Mitigation strategies primarily involve upgrading the AngleSharp library to version 1.5.0 or later, where this specific parsing logic has been corrected to ensure MathAnnotationXmlElement is treated consistently with HTML integration points regardless of the encoding attribute value. For organizations unable to immediately update their dependencies, defensive coding practices should be employed. This includes implementing additional validation layers that do not rely solely on AngleSharp for sanitization decisions and ensuring that any serialized output undergoes rigorous re-parsing checks within a trusted browser context before being rendered or processed further. Regular security audits of third-party parsing libraries are essential to detect such subtle discrepancies in DOM construction logic that could lead to significant security breaches.