CVE-2026-66294
XML injection in Saxy via unescaped CDATA section terminator
What happened?
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.
Affected software and versions
| Software | Version information | Fixed version |
|---|---|---|
| saxyqcam | affected: 0.7.0 to < 1.7.0 | See vendor advisory |
| qcam/saxyqcam | affected: 7266632e9407842f28ffac254c56dc41210a5690 to < 71d99fae12f1d6596f5edb57b71f26ba854f4d33 | See vendor advisory |
Version information comes from the source record and can include unaffected products and exceptions. Distribution packages may contain backported fixes: an older upstream version alone does not prove a server is affected.
Is it being exploited?
This CVE was not listed in the CISA catalogue at our last retrieval. This does not establish that exploitation is absent.
How to respond
- Confirm the product, installed package version, and any configuration requirements in the vendor advisory.
- Follow the vendor’s remediation or workaround guidance in the references below. Structured fixed-version data is unavailable here; the publisher’s description may include a fix or workaround.
- Restart affected services if required, then verify the running version. Known exploitation may warrant investigation as well as patching.
Sources and remediation references
- https://www.cve.org/CVERecord?id=CVE-2026-66294
- https://github.com/qcam/saxy/security/advisories/GHSA-hq6g-j46w-wx72
- https://cna.erlef.org/cves/CVE-2026-66294.html
- https://osv.dev/vulnerability/EEF-CVE-2026-66294
- https://github.com/qcam/saxy/commit/7266632e9407842f28ffac254c56dc41210a5690
- https://github.com/qcam/saxy/commit/71d99fae12f1d6596f5edb57b71f26ba854f4d33