xml_builder EUVD-2026-63879

Exploitation requires the host application to pass user-controlled data - such as HTTP form field names, JSON object keys, or similar external string inputs - directly as the name argument to XmlBuilder.element or related functions without prior sanitization. This is the essential gate: applications that only pass static, developer-defined strings as element or attribute names are not exploitable regardless of what users supply as element content or attribute values. The CVSS 4.0 AT:P metric correctly reflects this specific attack-target condition. Authentication requirements for reaching the vulnerable code path depend entirely on the host application's access controls and cannot be determined from the library-level CVE data alone. Exploitation is further limited in impact to scenarios where the resulting XML document is consumed by a parser or system that treats the output as structured markup; applications that treat the XML as opaque bytes or re-validate it downstream may experience no meaningful impact.

The vendor-assigned CVSS 4.0 score of 2.1 (AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N) reflects a narrow impact: subsequent-system low integrity only, with no confidentiality or availability component. The AV:L (local) assignment deserves scrutiny - the CVE description explicitly cites HTTP form field names and JSON object keys as realistic attack sources, meaning real-world exploitation in web applications is network-triggered even though the library itself is assessed locally; this tension should be verified against the host application's attack surface rather than accepted at face value. AT:P correctly captures the specific precondition: the host application must pass user-controlled strings as XML element names, which is not the default or recommended usage pattern. No EPSS data was supplied, KEV status is absent, and no standalone public exploit code has been identified - all low-urgency signals. Combined with the library's narrow Elixir ecosystem footprint and the integrity-only downstream impact, this is low priority for most organizations unless they operate an application known to route untrusted input directly into XmlBuilder name arguments. The risk assessment is constrained by the absence of EPSS scoring in the provided intelligence.

An attacker submits a crafted HTTP form field name such as x><!--injected--><evil attr="bad" to a web application that uses xml_builder to serialize request parameters into an XML document. The application passes the field name verbatim to XmlBuilder.element/3, causing the library to interpolate the structural characters into the output, breaking tag boundaries and embedding the attacker's markup. A downstream XML parser or API consumer then processes the corrupted document, potentially accepting spoofed data or triggering unexpected application logic. The GitHub advisory's test suite demonstrates this exact pattern, though no standalone exploit tool has been identified.