CVE-2026-93990 in Expat
Summary
by MITRE • 09/20/2026
Expat through 2.8.4 fails to validate low surrogates following high surrogates in UTF-16 input, allowing malformed UTF-16 sequences to be accepted. Attackers can craft UTF-16 encoded XML with lone high surrogates that consume following code units, hiding markup characters from the parser and enabling XML injection attacks.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/20/2026
The vulnerability identified in Expat versions prior to 2.8.4 represents a critical failure in Unicode normalization logic within an XML parsing library widely used across numerous software ecosystems. As a foundational component for processing Extensible Markup Language, Expat is expected to strictly adhere to the Universal Character Set and UTF-16 encoding standards defined by ISO/IEC 10646 and RFC 2781. The specific flaw lies in the parser's handling of surrogate pairs, which are used in UTF-16 to represent characters outside the Basic Multilingual Plane that cannot be encoded using a single sixteen-bit code unit. In proper UTF-16 encoding, high surrogates must always be followed by low surrogates to form a valid character sequence. The vulnerability arises because Expat fails to validate this pairing constraint when processing input streams, allowing malformed sequences where a lone high surrogate is not immediately followed by its corresponding low surrogate.
This technical flaw enables attackers to craft malicious XML documents that exploit the parser's leniency regarding invalid Unicode sequences. By inserting lone high surrogates into the payload, an attacker can effectively consume subsequent code units in the input stream without triggering a parsing error. This consumption mechanism allows the injection of markup characters such as angle brackets or ampersands that would otherwise be interpreted as structural XML delimiters to remain hidden from the parser's logical view of the document structure. Consequently, these injected characters are treated as part of character data rather than as active syntax elements during initial validation phases, bypassing security controls that rely on accurate parsing of the XML tree structure.
The operational impact of this vulnerability is significant, particularly in environments where Expat processes untrusted or semi-trusted XML input from external sources. The ability to hide markup characters facilitates sophisticated XML injection attacks, including but not limited to Server-Side Request Forgery (SSRF), Cross-Site Scripting (XSS) via reflected vectors, and SQL Injection if the parsed data is subsequently used in database queries without proper sanitization. Attackers can manipulate the logical structure of the document to bypass input validation filters that check for specific XML tags or entities. This undermines the integrity of applications relying on Expat for secure data ingestion, potentially leading to unauthorized access, data exfiltration, or remote code execution depending on how the parsed content is utilized by the host application.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-749 Exposure of Dangerous Method or Function if it leads to further exploitation vectors such as injection attacks. In terms of offensive security frameworks, it maps to ATT&CK technique T1189 Drive-by Client Side Execution when exploited via web applications, or more broadly to input validation bypasses that facilitate subsequent malicious actions like data manipulation or command execution. The root cause is a deviation from strict adherence to Unicode standards, specifically the requirement for valid surrogate pair construction in UTF-16 encoded streams.
Mitigation strategies primarily involve upgrading Expat to version 2.8.4 or later where this validation logic has been corrected to enforce proper surrogate pair integrity checks. For organizations unable to immediately patch their dependencies, implementing strict input filtering at the application layer is recommended as a compensating control. This includes validating that all incoming XML documents conform strictly to UTF-16 standards before passing them to the parser and rejecting any sequences containing lone high surrogates or other malformed Unicode constructs. Additionally, employing defense-in-depth measures such as output encoding and parameterized queries can mitigate the downstream effects of successful injection attempts resulting from this parsing flaw.