CVE-2026-47079: Round-trip Corruption via Improper Entity Escaping in xml_builder
Inappropriate Encoding for Output Context vulnerability in joshnuss xmlbuilder (XmlBuilder module) allows Content Spoofing, Cross-site Scripting.
This vulnerability is associated with program files lib/xmlbuilder.ex and program routines XmlBuilder.generate/1, XmlBuilder.generate/2, XmlBuilder.escapestring/1, XmlBuilder.escapeentity/1.
XmlBuilder.generate/1 does not escape literal & characters in text or attribute values when they are followed by an entity-like token (lt;, gt;, amp;, quot;, apos;). As a result, attacker-supplied input such as <script> is emitted verbatim into the serialized XML rather than being escaped to &lt;script&gt;. When a downstream XML parser later reads the document, it decodes the entity sequences into the literal characters <script>, promoting inert-looking text into real markup. This allows an attacker to bypass upstream filters that block raw < and > characters, injecting markup into any downstream consumer that parses the produced XML and renders the text content in a markup-sensitive context (HTML, SVG, RSS/Atom feeds). Both element text and attribute values are affected.
This issue affects xmlbuilder: from 0.0.6 before 2.4.1.
Affected Software
Event History
Frequently Asked Questions
Which deployments are affected?
Deployments using xml_builder versions from 0.0.6 up to, but not including, 2.4.1 are affected. The issue applies when XmlBuilder.generate/1 or XmlBuilder.generate/2 serializes attacker-controlled data into element text or attribute values.
What does an attacker need to exploit this issue?
An attacker needs a way to supply values that are included in generated XML, such as text or attribute content. They can use entity-encoded markup such as <script> to bypass filters that only reject raw angle brackets.
When does the issue become a practical XSS or content-spoofing risk?
The generated XML must later be parsed by a downstream consumer that decodes the entities and uses the resulting content in a markup-sensitive context, such as HTML, SVG, or an RSS/Atom feed. The vulnerable serialization can turn apparently inert encoded text into markup after that round trip.
What should be done if upgrading is not immediately possible?
Do not allow untrusted values containing entity-like sequences beginning with & and followed by lt;, gt;, amp;, quot;, or apos; to reach XmlBuilder.generate/1 or XmlBuilder.generate/2. Review both element-text and attribute-value inputs, and ensure downstream consumers do not render parsed XML content as markup.