CVE-2026-66294 in saxy
Summary
by MITRE • 11/06/2026
XML injection in the Saxy XML encoder. Saxy.Encoder.cdata/1 serializes a {:cdata, characters} node by wrapping the supplied characters between <![CDATA[ and ]]> and passing the payload through byte for byte. The encoder's character-data and attribute-value paths escape the XML metacharacters <, >, &, ", and ', but the CDATA path applies no neutralization at all. XML provides no character escaping mechanism inside a CDATA section, so the only correct way to represent a ]]> substring is to split the section and rejoin it as ]]]]><![CDATA[>. Saxy neither performs that split nor rejects the substring.
An application that renders untrusted text as CDATA, by building the node with Saxy.XML.cdata/1 and serializing it with Saxy.encode!/2 or Saxy.encode_to_iodata!/2, therefore lets an attacker terminate the section at a position of their choosing. Everything supplied after the ]]> is emitted outside any CDATA context and is parsed as markup, so a single attacker-controlled text field becomes attacker-controlled document structure: arbitrary sibling elements and attributes that the application never built. Downstream consumers of the serialized document accept the injected markup as genuine. Services that generate SOAP envelopes, RSS or Atom feeds, sitemaps, SVG, or XML exports from user-supplied content can have trusted fields forged or overridden. Applications that never place untrusted text in a CDATA node are not affected.
This issue affects saxy: from 0.7.0 before 1.7.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/06/2026
The vulnerability identified within the Saxy XML encoder represents a critical failure in input validation and output encoding, specifically manifesting as an XML Injection flaw through improper neutralization of special characters. This issue stems from a fundamental architectural oversight where the CDATA serialization path fails to apply any character escaping or sanitization logic compared to other paths such as character-data and attribute-value handling. While standard XML processing requires strict adherence to syntax rules for metacharacters, Saxy.Encoder.cdata/1 serializes {:cdata, characters} nodes by simply wrapping supplied input between <![CDATA[ and ]]> delimiters without performing any byte-level inspection or transformation of the payload content itself. This behavior directly contradicts established security best practices outlined in CWE-79, which classifies improper neutralization of special elements used in an HTML document as a form of injection where untrusted data is sent to a web server as part of a request that can be interpreted by a browser or other XML parser.
The technical root cause lies in the specific handling of CDATA sections within the Saxy library versions ranging from 0.7.0 up to, but not including, version 1.7.0. In standard XML specifications, there is no character escaping mechanism available inside a CDATA section except for one critical sequence: the substring ]]> itself cannot appear literally because it would prematurely terminate the section and break the document structure. The correct method to represent this literal string within a CDATA block is to split the content at that point and rejoin it using the pattern ]]]]><![CDATA[>. However, Saxy does not perform this necessary splitting operation nor does it reject inputs containing the closing delimiter sequence. Consequently, if an attacker supplies text ending with or containing ]]> as part of a user-controlled field intended for CDATA serialization, they can effectively break out of the safe data context and inject arbitrary XML markup into the document stream.
From an operational perspective, this vulnerability allows for severe downstream impacts including Cross-Site Scripting (XSS), Server-Side Request Forgery (SSRF), or even Remote Code Execution depending on how the resulting XML is processed by consuming applications. When an application renders untrusted text as CDATA using functions like Saxy.XML.cdata/1 followed by serialization via Saxy.encode!/2, any attacker-controlled input that includes the ]]> sequence will cause everything following it to be emitted outside of the CDATA context. This effectively transforms a single user-supplied field into attacker-controlled document structure, allowing for the injection of arbitrary sibling elements and attributes that were never intended or built by the application logic. Downstream consumers such as SOAP envelope processors, RSS feed aggregators, Atom feed readers, sitemap generators, SVG renderers, or XML export services will accept this injected markup as genuine data, leading to potential forgery or override of trusted fields.
This vulnerability aligns with MITRE ATT&CK technique T1190, Exploit Public-Facing Application, where attackers leverage vulnerabilities in software components exposed to the internet to execute malicious code or manipulate system behavior. The lack of input validation on CDATA content creates a predictable attack vector that can be exploited remotely without authentication if the vulnerable endpoint is publicly accessible. Organizations relying on Saxy for generating XML-based outputs from user-supplied content must recognize that this flaw compromises data integrity and trust boundaries within their systems, potentially allowing attackers to manipulate business logic or exfiltrate sensitive information through crafted XML payloads.
To mitigate this risk, immediate action is required by upgrading the Saxy dependency to version 1.7.0 or later where these encoding flaws have been addressed. For environments unable to upgrade immediately, developers must implement manual input validation and sanitization before passing data to CDATA nodes. This includes explicitly checking for the presence of the ]]> sequence in user-supplied strings and either rejecting such inputs entirely or implementing a custom escaping mechanism that splits the string at every occurrence of ]]> and reconstructs it using the safe ]]]]><![CDATA[ pattern as mandated by XML standards. Additionally, adopting strict input validation policies that define allowed character sets for CDATA fields can further reduce the attack surface. Security teams should also audit existing codebases for any instances where untrusted data is directly serialized into CDATA sections without prior sanitization to ensure comprehensive protection against this injection vector.