CVE-2026-48590 in xml_builder
Summary
by MITRE • 08/21/2026
XML Injection vulnerability in joshnuss xml_builder (XmlBuilder module) allows Content Spoofing, XML Injection.
This vulnerability is associated with program files lib/xml_builder.ex and program routines XmlBuilder.generate/1, XmlBuilder.generate/2, XmlBuilder.element/1, XmlBuilder.element/2, XmlBuilder.element/3.
Element names, attribute names, and doctype identifiers are interpolated verbatim into the serialized XML output without validation or escaping of structural characters (<, >, ", ', &). An attacker who can influence a name argument (for example, an element name derived from a JSON object key or an HTTP form field name) can inject arbitrary XML markup including extra elements, comments, and event-handler attributes into the output document.
This issue affects xml_builder: from 0.0.1 before 2.4.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/21/2026
The vulnerability identified in the joshnuss xml_builder library represents a critical failure in input validation and sanitization within an Elixir-based XML generation module. This flaw, classified under CWE-79 as Cross-site Scripting when used in web contexts or more accurately as CWE-611 for Improper Restriction of XML External Entity Reference if external entities are involved, allows attackers to inject arbitrary markup into dynamically generated documents. The core technical issue lies in the verbatim interpolation of user-supplied data into the serialized output without performing any necessary escaping or validation of structural characters such as less-than (<), greater-than (>), double quotes ("), single quotes ('), and ampersands (&). This lack of sanitization means that any input passed to functions like XmlBuilder.generate/1, XmlBuilder.generate/2, XmlBuilder.element/1, XmlBuilder.element/2, or XmlBuilder.element/3 is treated as literal XML content rather than data payload. Consequently, if an attacker can control the name argument for an element, such as by manipulating a JSON object key or an HTTP form field that feeds into these routines, they can break out of the intended document structure and inject arbitrary XML nodes, comments, or attributes directly into the output stream.
The operational impact of this vulnerability is severe, primarily manifesting through Content Spoofing and potential Remote Code Execution depending on how the generated XML is processed downstream. By injecting event-handler attributes such as onload or onclick into elements within a context where the resulting XML might be rendered in an HTML viewer or converted to another format that supports scripting, attackers can execute malicious scripts in the victim's browser. This aligns with MITRE ATT&CK technique T1059, specifically Command and Scripting Interpreter sub-techniques like JavaScript (T1059.007). Furthermore, if the XML parser processing the output is configured to process external entities or DTD definitions, this vulnerability can be leveraged for Server-Side Request Forgery (SSRF) or Local File Inclusion attacks by injecting DOCTYPE declarations that reference local system files or remote malicious servers. This falls under ATT&CK technique T1059.004 for Unix Shell commands if the injection leads to command execution via XXE, and T1190 for Exploit Public-Facing Application. The ability to inject arbitrary elements also allows attackers to alter the semantic meaning of the document, potentially leading to logic flaws in applications that rely on specific XML structures for business processes.
The vulnerability affects versions of xml_builder from 0.0.1 up to but not including version 2.4.1. This wide range indicates a long-standing issue where the library has historically prioritized convenience and speed over security by assuming all inputs are trusted or safe. The absence of built-in escaping mechanisms places the entire burden of security on the application developer, who must manually sanitize every input before passing it to XmlBuilder functions. In many cases, developers may overlook this requirement, especially when dealing with dynamic keys from JSON payloads or user-generated content in web forms. This creates a systemic risk across all applications utilizing these vulnerable versions without explicit mitigation layers implemented at the application level rather than relying on the library itself for protection.
To mitigate this vulnerability, immediate action is required to upgrade the xml_builder dependency to version 2.4.1 or later, where proper escaping and validation mechanisms have likely been introduced. For environments that cannot immediately update due to compatibility constraints, developers must implement strict input sanitization before passing any user-controlled data to XmlBuilder functions. This involves ensuring that all special XML characters are properly escaped using standard libraries such as Elixir's built-in String module or dedicated HTML/XML escaping utilities. Specifically, the less-than and greater-than signs should be converted to their entity equivalents (< and >), quotes to entities (" and '), and ampersands to &. Additionally, applications should enforce strict allow-listing of permitted element names and attribute values where possible, rejecting any input that contains structural characters or unexpected patterns. Implementing a Content Security Policy (CSP) can also help mitigate the impact of successful script injection by restricting the sources from which scripts can be loaded, thereby reducing the effectiveness of cross-site scripting attacks derived from this XML injection flaw. Regular security audits and static code analysis tools configured to detect unescaped user input in template or serialization engines should be employed to prevent similar issues in future development cycles.