New xml Dom library merges consecutive CDATA sections, even when that would result in semantically different or invalid documents

[Qjammer]

Description

When including CDATA sections within other CDATA sections, it is common to escape the closing tags by separating them in consecutive CDATA sections. The content of the following <a> tag

<a><![CDATA[]]]]><![CDATA[><string-that-looks-like-a-tag>]]></a>

is the string: ]]><string-that-looks-like-a-tag>.

The following code, however, merges consecutive CDATA sections:

<?php
$xml = "<a><![CDATA[]]]]><![CDATA[><string-that-looks-like-a-tag>]]></a>";

$doc = \Dom\XMLDocument::createFromString($xml);

echo $doc->saveXml($doc->firstChild);

Which results in this output, which is an invalid xml document:

<a><![CDATA[]]><string-that-looks-like-a-tag>]]></a>

But I expected this output instead:

<a><![CDATA[]]]]><![CDATA[><string-that-looks-like-a-tag>]]></a>

This does not happen with the old \DOMDocument library:

<?php
$xml = "<a><![CDATA[]]]]><![CDATA[><string-that-looks-like-a-tag>]]></a>";

$doc = new \DOMDocument();
$doc->loadXML($xml);

echo $doc->saveXml($doc->firstChild);

Results in:

<a><![CDATA[]]]]><![CDATA[><string-that-looks-like-a-tag>]]></a>

PHP Version

PHP 8.4.12 (cli) (built: Aug 28 2025 18:16:26) (NTS)
Copyright (c) The PHP Group
Built by https://github.com/docker-library/php
Zend Engine v4.4.12, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.12, Copyright (c), by Zend Technologies
    with Xdebug v3.4.5, Copyright (c) 2002-2025, by Derick Rethans

Operating System

Docker image with Debian 13.0

[MorganLOCode]

Indeed, breaking it in two by making it span two adjacent CDATA sections is the only way to contain the ]]> character sequence.

[nielsdos]

This does not happen with the old \DOMDocument library

This is actually false.
If you add a var_dump: var_dump($doc->firstChild->firstChild); you will see there is only one CData sections that is the merge of the two CData sections. The reason it shows up as 2 separate ones in the serialization is because libxml contains a workaround for such non-printable CData sections.

The new Dom library does not contain such a workaround in its serializer because that goes against the WHATWG Dom spec.

It's true that the parser shouldn't even merge these sections in the first place. This was a libxml bug that got fixed in GNOME/libxml2@8ae06d5. However, since Debian is shipping an outdated libxml version, you don't have this fix on your system.
On the PHP side: I can't work around this. This needs to be fixed at the parser level but the xml parsing is fully handled by libxml.