CVE-2026-41650

What it actually does

fast-xml-parser before version 5.7.0 fails to correctly escape XML terminator sequences when XMLBuilder serializes JavaScript objects into XML. Specifically, attacker-controlled values placed into XML comments can include the comment terminator sequence "-->", and attacker-controlled values placed into CDATA sections can include the CDATA terminator sequence "]]>", allowing the attacker to break out of the intended XML context and inject additional XML markup or script-bearing content. Depending on where the generated XML is consumed, this can result in XML structure manipulation, SOAP message tampering, downstream parser confusion, or cross-site scripting when the XML is later rendered or transformed into HTML. The vulnerability is input-validation/output-encoding related and affects applications that build XML from untrusted or partially trusted data using vulnerable fast-xml-parser XMLBuilder behavior.

Why it matters to the business

Applications that generate XML using vulnerable versions of fast-xml-parser may produce attacker-controlled XML documents that misrepresent data, alter SOAP/API requests, or introduce browser-executable content in downstream consumers. The practical business impact depends on how the XML is used: customer-facing applications could expose users to cross-site scripting, integrations could process modified XML fields or operations, and business workflows relying on XML messages could suffer data integrity issues. The CVSS score is moderate and EPSS is currently low, with no known CISA KEV listing or public exploit maturity indicated, but the library may be embedded in many JavaScript applications through direct or transitive dependencies, so exposure can be easy to miss.

How an attack unfolds

An attacker first identifies an application path where their input is later serialized into XML comments or CDATA sections by fast-xml-parser XMLBuilder. They submit crafted input containing an XML context-breaking sequence such as "-->" for comments or "]]>" for CDATA, followed by attacker-chosen XML markup or script-relevant content. In vulnerable versions, XMLBuilder emits the terminator sequence without escaping it, causing the generated XML to close the intended comment or CDATA block early. The injected content is then interpreted by downstream XML consumers as real markup rather than inert text. If the XML is displayed or transformed into a web page, this may lead to XSS; if it is sent to a SOAP service or integration endpoint, it may alter message structure, parameters, or business data.

How to fix it

Upgrade fast-xml-parser to version 5.7.0 or later wherever it is used directly or transitively. If package lockfiles are used, update and redeploy the lockfile-resolved dependency rather than only changing a manifest range. If immediate upgrade is not possible, avoid placing untrusted data into XML comments or CDATA sections, explicitly validate or reject the terminator sequences "-->" and "]]>" before XML generation, and prefer normal text nodes with correct escaping over comments or CDATA for user-controlled content. Review XML-generation code paths for custom wrappers around XMLBuilder and confirm all services, worker processes, build artifacts, containers, and serverless packages are rebuilt with the fixed dependency.

How to confirm the fix worked

Confirm dependency resolution shows fast-xml-parser version 5.7.0 or later in all deployed artifacts, including package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, bundled JavaScript, containers, and serverless deployment packages. Run software composition analysis against both source repositories and built images. Add regression tests that serialize comment and CDATA values containing "-->" and "]]>" and verify the generated XML does not allow those sequences to terminate the intended XML context and inject active markup. Exercise known XML-generating endpoints with benign test payloads containing these sequences and confirm responses, stored XML files, SOAP requests, and transformed output remain structurally safe.

Typical attack path

1. Find an application endpoint, form, API field, import process, or integration where user-controlled input is included in XML output.
2. Determine or infer that the input is placed inside an XML comment or CDATA section generated by fast-xml-parser XMLBuilder.
3. Submit payloads containing "-->" to escape XML comments or "]]>" to escape CDATA sections.
4. Append attacker-controlled XML elements, attributes, SOAP body content, or script-bearing markup after breaking out of the intended context.
5. Trigger the application to generate, store, transmit, render, transform, or forward the manipulated XML.
6. Abuse the downstream effect, such as XSS in a browser-based consumer, modified SOAP/API behavior, or manipulation of data processed from the generated XML.

How to detect it

To assess possible prior exploitation, review application, API gateway, WAF, and reverse-proxy logs for user-supplied parameters containing XML terminator sequences associated with this issue, especially "-->" and "]]>" followed by XML tags, SOAP elements, HTML tags, or script-related strings. Examine generated XML files, message queues, SOAP request logs, integration payload archives, audit logs, and stored application records for unexpected closing of comments or CDATA blocks and inserted elements immediately after those sequences. For XSS scenarios, correlate suspicious XML-generation requests with browser error logs, content-security-policy violation reports, user reports, or web access logs showing script execution attempts. For SOAP or integration scenarios, inspect downstream service logs for malformed XML, schema validation failures, unexpected operations, changed parameters, or anomalous business transactions occurring after payloads containing comment or CDATA terminators. Since no specific public exploit kit or threat actor activity is indicated, detection should focus on payload patterns and downstream XML anomalies rather than actor-specific infrastructure.

• -->
• ]]>
• ]]><
• --><
• <script
• </script>
• <![CDATA[
• ]]><script
• --><script
• </comment>
• <soap:Envelope
• <soap:Body
• </soap:Body>
• SOAPAction
• XMLBuilder
• fast-xml-parser

What your security team should do

• Inventory all applications and services using naturalintelligence fast-xml-parser, including transitive dependencies in Node.js projects.
• Prioritize upgrades to fast-xml-parser 5.7.0 or later for internet-facing applications, XML/SOAP integration services, and applications that render or transform generated XML into browser-consumable content.
• Search code for XMLBuilder usage and identify whether user-controlled fields are written into comments or CDATA sections.
• Add input validation or output-encoding safeguards for XML generation paths, especially where business-critical integrations consume the resulting XML.
• Create regression tests for XML comment and CDATA terminator injection using "-->" and "]]>" payloads.
• Monitor dependency scanning results and CI/CD gates to prevent reintroduction of fast-xml-parser versions earlier than 5.7.0.
• Because there is no CISA KEV listing, no ransomware association, low EPSS, and no indicated exploit maturity, handle as a prioritized dependency hygiene and application-specific risk item rather than an emergency internet-wide exploitation event.