fast-xml-builder Flaw CVE-2026-44664 Enables XML Injection via

Executive Summary

A medium-severity XML injection vulnerability, tracked as CVE-2026-44664 (CVSS 6.1), has been discovered in the npm package fast-xml-builder, a utility that constructs XML documents from JSON input. The flaw allows an attacker to break out of XML comment boundaries by supplying input containing three consecutive dashes (---), enabling injection of arbitrary XML or HTML content into the generated output. The maintainer has released version 1.1.6 to address the issue. The vulnerability arises from an incomplete fix for a prior comment-sanitization flaw in the related fast-xml-parser library (CVE-2026-41650).

Technical Analysis

fast-xml-builder is a JavaScript library that converts JSON objects into well-formed XML strings. It is widely used in Node.js applications for generating XML payloads, configuration files, and data interchange formats. In version 1.1.5, the library adopted a sanitization routine originally developed for fast-xml-parser to prevent XML comment injection via the -- sequence. The fix replaced occurrences of -- with - - (a space inserted between the dashes) inside XML comments, as per the XML specification (W3C XML 1.0, Section 2.5), which forbids the literal string -- within comments.

However, the sanitization logic contained a critical oversight: it only replaced the exact two-character sequence --. An attacker can bypass this filter by including a third dash, forming the sequence ---. When the input contains three consecutive dashes, the first two are transformed to - -, but the third dash remains untouched, resulting in the sequence - --. This still contains a -- substring (the second and third characters after transformation), which the XML parser interprets as the end-of-comment marker (-->). The trailing > from the attacker's payload completes the comment closure, allowing arbitrary XML content to follow.

For example, an attacker who controls a value that gets placed inside an XML comment can supply:

---><malicious-element>injected</malicious-element>

After sanitization, the comment becomes:

<!-- - --><malicious-element>injected</malicious-element> -->

The parser sees the --> after the first three characters as closing the comment, then processes the injected <malicious-element> as legitimate XML. This can lead to:

• XML structure injection: Altering the intended document structure, potentially breaking downstream parsers or enabling XML External Entity (XXE) attacks if the output is consumed by an XML parser with entity resolution enabled.
• HTML injection: If the generated XML is rendered in a browser context (e.g., as part of a web page or XSLT transformation), the injected content can include arbitrary HTML or JavaScript, leading to cross-site scripting (XSS).
• Data corruption: Malformed or injected XML can corrupt logs, configuration files, or data pipelines that rely on the generated XML.

The vulnerability was reported via the GitHub Security Advisory program. The maintainer acknowledged the issue and released version 1.1.6, which implements a more robust sanitization routine: it replaces any occurrence of three or more consecutive dashes with a space-separated equivalent, ensuring no -- or --- sequences remain in comment content.

Mitigations & Recommendations

Organizations using fast-xml-builder should take the following steps:

1. Upgrade immediately: Update to version 1.1.6 or later. Run npm update fast-xml-builder or pin the version in your package.json to ^1.1.6.
2. Audit dependencies: Run npm audit to identify any packages that depend on vulnerable versions of fast-xml-builder. The library may be included transitively; check your lockfile (package-lock.json or yarn.lock) for the resolved version.
3. Review XML output: If upgrading is not immediately possible, inspect any XML output generated by the library for unexpected content, especially if user-supplied data is included in comment fields. Consider validating the output against a schema before processing.
4. Assess exposure: The severity (CVSS 6.1) reflects a medium risk, but the actual impact depends on how the generated XML is consumed. If the output is parsed by an XML parser with DTD/entity expansion enabled, or rendered in a browser, the risk increases. Defenders should evaluate their specific use case.

No workaround exists beyond upgrading; the sanitization logic is embedded in the library's comment-writing function.