Cẩm Huỳnh

An XML injection issue exists in the encoder of Saxy. The `Saxy.Encoder` fails to neutralize the `--` sequence within XML comment content because the `escape comment/2` function returns the comment binary unchanged in every clause and only appends a space if the comment ends in a single `-`. Consequently, neither an interior `--` nor a full `-->` is escaped or rejected before the encoder wraps the content in delimiters. When an application serializes attacker-controlled text as a comment via `Saxy.XML.comment/1` or a raw `{:comment, text}` simple form child, an attacker can prematurely close the comment using `-->` to inject arbitrary sibling markup into the serialized document. This allows for stored cross-site scripting when the document is rendered as HTML or SVG, or data forgery when consumed by another XML processor. This issue only affects applications that serialize untrusted text using `Saxy.encode!/2` or `Saxy.encode to iodata!/2`.

XML injection occurs in the Saxy XML encoder because the `Saxy.Encoder.cdata/1` function serializes `{:cdata, characters}` nodes by wrapping characters between `<![CDATA[` and `]]>` without neutralizing the payload. While other paths escape XML metacharacters, the CDATA path does not handle the `]]>` substring, which is the only way to terminate a CDATA section. An attacker can provide untrusted text containing `]]>` to terminate the section prematurely, allowing subsequent input to be parsed as XML markup. This enables the injection of arbitrary sibling elements and attributes into the document structure. This issue impacts services generating SOAP envelopes, RSS, Atom feeds, sitemaps, SVG, or XML exports from user-supplied content. The vulnerability is triggered when using `Saxy.XML.cdata/1` in conjunction with `Saxy.encode!/2` or `Saxy.encode to iodata!/2`.

The XML encoder fails to validate or escape the target and content of processing instructions, writing them verbatim into the output document. Because the sequence `?>` terminates a processing instruction, an attacker can use this sequence to close the construct prematurely and inject arbitrary elements, attributes, and further processing instructions into the serialized document. This occurs because the encoder concatenates fields without checking them against XML specification constraints. The `Saxy.XML.processing instruction/2` function is a public builder that allows this flaw to be inherited. This can lead to XML injection, resulting in forged records, injected stylesheets, or active content when the output is processed by a downstream parser or browser. The issue is triggered when a `{:processing instruction, name, content}` node is passed to `Saxy.encode!/2` or `Saxy.encode to iodata!/2` using untrusted input.