---
id: "CVE-2026-66294"
page: "https://infrastack.ai/live/CVE-2026-66294"
kind: "vulnerability"
aliases: ["CVE-2026-66294"]
title: "Saxy: untrusted text in CDATA nodes lets attackers inject XML markup"
severity: "low"
cvss: 2.1
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["elixir", "package", "rss", "saxy", "soap", "xml"]
not_affected_if: ["no-untrusted-cdata", "not-on-affected-version"]
published_at: "2026-11-06T11:17:16+00:00"
first_seen_at: "2026-11-06T11:41:29+00:00"
updated_at: "2026-11-06T11:43:57+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-66294", "first_seen_at": "2026-11-06T11:41:29+00:00"}]
exploit_sources: []
---

# Saxy: untrusted text in CDATA nodes lets attackers inject XML markup

Link for people: https://infrastack.ai/live/CVE-2026-66294 (this .md is for agents)

The Saxy Elixir XML encoder writes CDATA node content without splitting on the ]]> sequence, so text containing that sequence ends the section. Anything after it is emitted as real markup, letting an attacker add or override XML elements and attributes.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Look for `Saxy.XML.cdata/1` in the codebase, where the argument can come from user input.
- Check the saxy version in `mix.lock` against the affected range `0.7.0` to before `1.7.0`.

## Fix

- saxy: upgrade to `1.7.0` or later

## Timeline

- 2026-11-06T11:41:29+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-66294

## Documents

- [advisory] Vendor advisory: github.com https://github.com/qcam/saxy/security/advisories/GHSA-hq6g-j46w-wx72
- [fix] Patch: github.com https://github.com/qcam/saxy/commit/71d99fae12f1d6596f5edb57b71f26ba854f4d33
- [fix] Patch: github.com https://github.com/qcam/saxy/commit/7266632e9407842f28ffac254c56dc41210a5690

## From the sources

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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_