chore(deps): update dependency @xmldom/xmldom@<0.8.12 to v0.8.13 [security] by renovate[bot] · Pull Request #4434 · pear-devs/pear-desktop

renovate · 2026-04-23T05:30:35Z

This PR contains the following updates:

Package	Change	Age	Confidence
@xmldom/xmldom@<0.8.12	`0.8.12` → `0.8.13`

xmldom has XML node injection through unvalidated processing instruction serialization

CVE-2026-41675 / GHSA-x6wf-f3px-wcqx

More information

Details

Summary

The package allows attacker-controlled processing instruction data to be serialized into XML without validating or neutralizing the PI-closing sequence ?>. As a result, an attacker can terminate the processing instruction early and inject arbitrary XML nodes into the serialized output.

Details

The issue is in the DOM construction and serialization flow for processing instruction nodes.

When createProcessingInstruction(target, data) is called, the supplied data string is stored directly on the node without validation. Later, when the document is serialized, the serializer writes PI nodes by concatenating <?, the target, a space, node.data, and ?> directly.

That behavior is unsafe because processing instructions are a syntax-sensitive context. The closing delimiter ?> terminates the PI. If attacker-controlled input contains ?>, the serializer does not preserve it as literal PI content. Instead, it emits output where the remainder of the payload is treated as live XML markup.

The same class of vulnerability was previously addressed for CDATA sections (GHSA-wh4c-j3r5-mjhp / CVE-2026-34601), where ]]> in CDATA data was handled by splitting. The serializer applies no equivalent protection to processing instruction data.

Affected code

lib/dom.js — createProcessingInstruction (lines 2240–2246):

createProcessingInstruction: function (target, data) {
    var node = new ProcessingInstruction(PDC);
    node.ownerDocument = this;
    node.childNodes = new NodeList();
    node.nodeName = node.target = target;
    node.nodeValue = node.data = data;
    return node;
},

No validation is performed on data. Any string including ?> is stored as-is.

lib/dom.js — serializer PI case (line 2966):

case PROCESSING_INSTRUCTION_NODE:
    return buf.push('<?', node.target, ' ', node.data, '?>');

node.data is emitted verbatim. If it contains ?>, that sequence terminates the PI in the output
stream and the remainder appears as active XML markup.

Contrast — CDATA (line 2945, patched):

case CDATA_SECTION_NODE:
    return buf.push(g.CDATA_START, node.data.replace(/]]>/g, ']]]]><![CDATA[>'), g.CDATA_END);

PoC

Minimal (from @tlsbollei report, 2026-04-01)

const { DOMImplementation, XMLSerializer } = require('@&#8203;xmldom/xmldom');

const doc = new DOMImplementation().createDocument(null, 'r', null);
doc.documentElement.appendChild(
    doc.createProcessingInstruction('a', '?><z/><?q ')
);
console.log(new XMLSerializer().serializeToString(doc));
// <r><?a ?><z/><?q ?></r>
//          ^^^^ injected <z/> element is active markup

With re-parse verification (from @tlsbollei report)

const assert = require('assert');
const { DOMParser, XMLSerializer } = require('@&#8203;xmldom/xmldom');

const doc = new DOMParser().parseFromString('<r/>', 'application/xml');
doc.documentElement.appendChild(doc.createProcessingInstruction('a', '?><z/><?q '));
const xml = new XMLSerializer().serializeToString(doc);
assert.strictEqual(new DOMParser().parseFromString(xml, 'application/xml')
    .getElementsByTagName('z').length, 1); // passes — z is a real element

Impact

An application that uses the package to build XML from untrusted input can be made to emit attacker-controlled elements outside the intended PI boundary. That allows the attacker to alter the meaning and structure of generated XML documents.

In practice, this can affect any workflow that generates XML and then stores it, forwards it, signs it, or hands it to another parser. Realistic targets include XML-based configuration, policy documents, and message formats where downstream consumers trust the serialized structure.

As noted by @tlsbollei: this is the same delimiter-driven XML injection bug class previously addressed by GHSA-wh4c-j3r5-mjhp for createCDATASection(). Fixing CDATA while leaving PI creation and PI serialization unguarded leaves the same standards-constrained issue open for another node type.

Disclosure

This vulnerability was publicly disclosed at 2026-04-06T11:25:07Z via
xmldom/xmldom#987, which was subsequently closed
without being merged.

Fix Applied

⚠ Opt-in required. Protection is not automatic. Existing serialization calls remain
vulnerable unless { requireWellFormed: true } is explicitly passed. Applications that pass
untrusted data to createProcessingInstruction() or mutate PI nodes with untrusted input
(via .data = or CharacterData mutation methods) should audit all serializeToString()
call sites and add the option.

XMLSerializer.serializeToString() now accepts an options object as a second argument. When { requireWellFormed: true } is passed, the serializer throws InvalidStateError before emitting any ProcessingInstruction node whose .data contains ?>. This check applies regardless of how ?> entered the node — whether via createProcessingInstruction directly or a subsequent mutation (.data =, CharacterData methods).

On @xmldom/xmldom ≥ 0.9.10, the serializer additionally applies the full W3C DOM Parsing §3.2.1.7 checks when requireWellFormed: true:

Target check: throws InvalidStateError if the PI target contains a : character or is an ASCII case-insensitive match for "xml".
Data Char check: throws InvalidStateError if the PI data contains characters outside the XML Char production.
Data sequence check: throws InvalidStateError if the PI data contains ?>.

On @xmldom/xmldom ≥ 0.8.13 (LTS), only the ?> data check (check 3) is applied. The target and XML Char checks are not included in the LTS fix.

PoC — fixed path

const { DOMImplementation, XMLSerializer } = require('@&#8203;xmldom/xmldom');

const doc = new DOMImplementation().createDocument(null, 'r', null);
doc.documentElement.appendChild(doc.createProcessingInstruction('a', '?><z/><?q '));

// Default (unchanged): verbatim — injection present
const unsafe = new XMLSerializer().serializeToString(doc);
console.log(unsafe);
// <r><?a ?><z/><?q ?></r>

// Opt-in guard: throws InvalidStateError before serializing
try {
  new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
} catch (e) {
  console.log(e.name, e.message);
  // InvalidStateError: The ProcessingInstruction data contains "?>"
}

The guard catches ?> regardless of when it was introduced:

// Post-creation mutation: also caught at serialization time
const pi = doc.createProcessingInstruction('target', 'safe data');
doc.documentElement.appendChild(pi);
pi.data = 'safe?><injected/>';
new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
// InvalidStateError: The ProcessingInstruction data contains "?>"

Why the default stays verbatim

The W3C DOM Parsing and Serialization spec §3.2.1.3 defines a require well-formed flag whose default value is false. With the flag unset, the spec explicitly permits serializing PI data verbatim. This matches browser behavior: Chrome, Firefox, and Safari all emit ?> in PI data verbatim by default without error.

Unconditionally throwing would be a behavioral breaking change with no spec justification. The opt-in requireWellFormed: true flag allows applications that require injection safety to enable strict mode without breaking existing code.

Residual limitation

createProcessingInstruction(target, data) does not validate data at creation time. The WHATWG DOM spec (§4.5 step 2) mandates an InvalidCharacterError when data contains ?>; enforcing this check unconditionally at creation time is a breaking change and is deferred to a future breaking release.

When the default serialization path is used (without requireWellFormed: true), PI data containing ?> is still emitted verbatim. Applications that do not pass requireWellFormed: true remain exposed.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

xmldom has XML injection through unvalidated DocumentType serialization

CVE-2026-41674 / GHSA-f6ww-3ggp-fr8h

More information

Details

Summary

The package serializes DocumentType node fields (internalSubset, publicId, systemId) verbatim
without any escaping or validation. When these fields are set programmatically to attacker-controlled
strings, XMLSerializer.serializeToString can produce output where the DOCTYPE declaration is
terminated early and arbitrary markup appears outside it.

Details

DOMImplementation.createDocumentType(qualifiedName, publicId, systemId, internalSubset) validates
only qualifiedName against the XML QName production. The remaining three arguments are stored
as-is with no validation.

The XMLSerializer emits DocumentType nodes as:

<!DOCTYPE name[ PUBLIC pubid][ SYSTEM sysid][ [internalSubset]]>

All fields are pushed into the output buffer verbatim — no escaping, no quoting added.

internalSubset injection: The serializer wraps internalSubset with [ and ]. A value
containing ]> closes the internal subset and the DOCTYPE declaration at the injection point.
Any content after ]> in internalSubset appears outside the DOCTYPE in the serialized output as
raw XML markup. Reported by @TharVid (GHSA-f6ww-3ggp-fr8h). Affected: @xmldom/xmldom ≥ 0.9.0
via createDocumentType API; 0.8.x only via direct property write.

publicId injection: The serializer emits publicId verbatim after PUBLIC with no
quoting added. A value containing an injected system identifier (e.g.,
"pubid" SYSTEM "evil") breaks the intended quoting context, injecting a fake SYSTEM entry
into the serialized DOCTYPE declaration. Identified during internal security research. Affected:
both branches, all versions back to 0.1.0.

systemId injection: The serializer emits systemId verbatim. A value containing >
terminates the DOCTYPE declaration early; content after > appears as raw XML markup outside
the DOCTYPE context. Identified during internal security research. Affected: both branches, all
versions back to 0.1.0.

The parse path is safe: the SAX parser enforces the PubidLiteral and SystemLiteral grammar
productions, which exclude the relevant characters, and the internal subset parser only accepts a
subset it can structurally validate. The vulnerability is reachable only through programmatic
createDocumentType calls with attacker-controlled arguments.

Affected code

lib/dom.js — createDocumentType (lines 898–910):

createDocumentType: function (qualifiedName, publicId, systemId, internalSubset) {
    validateQualifiedName(qualifiedName);          // only qualifiedName is validated
    var node = new DocumentType(PDC);
    node.name = qualifiedName;
    node.nodeName = qualifiedName;
    node.publicId = publicId || '';               // stored verbatim
    node.systemId = systemId || '';               // stored verbatim
    node.internalSubset = internalSubset || '';   // stored verbatim
    node.childNodes = new NodeList();
    return node;
},

lib/dom.js — serializer DOCTYPE case (lines 2948–2964):

case DOCUMENT_TYPE_NODE:
    var pubid = node.publicId;
    var sysid = node.systemId;
    buf.push(g.DOCTYPE_DECL_START, ' ', node.name);
    if (pubid) {
        buf.push(' ', g.PUBLIC, ' ', pubid);
        if (sysid && sysid !== '.') {
            buf.push(' ', sysid);
        }
    } else if (sysid && sysid !== '.') {
        buf.push(' ', g.SYSTEM, ' ', sysid);
    }
    if (node.internalSubset) {
        buf.push(' [', node.internalSubset, ']');  // internalSubset emitted verbatim
    }
    buf.push('>');
    return;

PoC

internalSubset injection

const { DOMImplementation, XMLSerializer } = require('@&#8203;xmldom/xmldom');

const impl = new DOMImplementation();
const doctype = impl.createDocumentType(
    'root',
    '',
    '',
    ']><injected/><![CDATA['
);
const doc = impl.createDocument(null, 'root', doctype);
const xml = new XMLSerializer().serializeToString(doc);
console.log(xml);
// <!DOCTYPE root []><injected/><![CDATA[]><root/>
//                   ^^^^^^^^^^  injected element outside DOCTYPE

publicId quoting context break

const { DOMImplementation, XMLSerializer } = require('@&#8203;xmldom/xmldom');

const impl = new DOMImplementation();
const doctype = impl.createDocumentType(
    'root',
    '"injected PUBLIC_ID" SYSTEM "evil"',
    '',
    ''
);
const doc = impl.createDocument(null, 'root', doctype);
console.log(new XMLSerializer().serializeToString(doc));
// <!DOCTYPE root PUBLIC "injected PUBLIC_ID" SYSTEM "evil"><root/>
// quoting context broken — SYSTEM entry injected

systemId injection

const { DOMImplementation, XMLSerializer } = require('@&#8203;xmldom/xmldom');

const impl = new DOMImplementation();
const doctype = impl.createDocumentType(
    'root',
    '',
    '"sysid"><injected attr="pwn"/>',
    ''
);
const doc = impl.createDocument(null, 'root', doctype);
console.log(new XMLSerializer().serializeToString(doc));
// <!DOCTYPE root SYSTEM "sysid"><injected attr="pwn"/>><root/>
// > in sysid closes DOCTYPE early; <injected/> appears as sibling element

Impact

An application that programmatically constructs DocumentType nodes from user-controlled data and
then serializes the document can emit a DOCTYPE declaration where the internal subset is closed
early or where injected SYSTEM entities or other declarations appear in the serialized output.

Downstream XML parsers that re-parse the serialized output and expand entities from the injected
DOCTYPE declarations may be susceptible to XXE-class attacks if they enable entity expansion.

Fix Applied

⚠ Opt-in required. Protection is not automatic. Existing serialization calls remain
vulnerable unless { requireWellFormed: true } is explicitly passed. Applications that pass
untrusted data to createDocumentType() or write untrusted values directly to a
DocumentType node's publicId, systemId, or internalSubset properties should audit
all serializeToString() call sites and add the option.

XMLSerializer.serializeToString() now accepts an options object as a second argument. When { requireWellFormed: true } is passed, the serializer validates the DocumentType node's publicId, systemId, and internalSubset fields before emitting the DOCTYPE declaration and throws InvalidStateError if any field contains an injection sequence:

publicId: throws if non-empty and does not match the XML PubidLiteral production (XML 1.0 [12])
systemId: throws if non-empty and does not match the XML SystemLiteral production (XML 1.0 [11])
internalSubset: throws if it contains ]> (which closes the internal subset and DOCTYPE declaration early)

All three checks apply regardless of how the invalid value entered the node — whether via createDocumentType arguments or a subsequent direct property write.

PoC — fixed path

const { DOMImplementation, XMLSerializer } = require('@&#8203;xmldom/xmldom');
const impl = new DOMImplementation();

// internalSubset injection
const dt1 = impl.createDocumentType('root', '', '', ']><injected/><![CDATA[');
const doc1 = impl.createDocument(null, 'root', dt1);

// Default (unchanged): verbatim — injection present
console.log(new XMLSerializer().serializeToString(doc1));
// <!DOCTYPE root []><injected/><![CDATA[]><root/>

// Opt-in guard: throws InvalidStateError
try {
  new XMLSerializer().serializeToString(doc1, { requireWellFormed: true });
} catch (e) {
  console.log(e.name, e.message);
  // InvalidStateError: DocumentType internalSubset contains "]>"
}

The guard also covers post-creation property writes:

const dt2 = impl.createDocumentType('root', '', '');
dt2.systemId = '"sysid"><injected attr="pwn"/>';
const doc2 = impl.createDocument(null, 'root', dt2);
new XMLSerializer().serializeToString(doc2, { requireWellFormed: true });
// InvalidStateError: DocumentType systemId is not a valid SystemLiteral

Why the default stays verbatim

The W3C DOM Parsing and Serialization spec §3.2.1.3 defines a require well-formed flag whose default value is false. With the flag unset, the spec permits verbatim serialization of DOCTYPE fields. Unconditionally throwing would be a behavioral breaking change with no spec justification. The opt-in requireWellFormed: true flag allows applications that require injection safety to enable strict mode without breaking existing deployments.

Residual limitation

createDocumentType(qualifiedName, publicId, systemId[, internalSubset]) does not validate publicId, systemId, or internalSubset at creation time. This creation-time validation is a breaking change and is deferred to a future breaking release.

When the default serialization path is used (without requireWellFormed: true), all three fields are still emitted verbatim. Applications that do not pass requireWellFormed: true remain exposed.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

xmldom has XML node injection through unvalidated comment serialization

CVE-2026-41672 / GHSA-j759-j44w-7fr8

More information

Details

Summary

The package allows attacker-controlled comment content to be serialized into XML without validating or neutralizing comment breaking sequences. As a result, an attacker can terminate the comment early and inject arbitrary XML nodes into the serialized output.

Details

The issue is in the DOM construction and serialization flow for comment nodes.

When createComment(data) is called, the supplied string is stored as comment data through the generic character-data handling path. That content is kept as-is. Later, when the document is serialized, the serializer writes comment nodes by concatenating the XML comment delimiters with the stored node.data value directly.

That behavior is unsafe because XML comments are a syntax-sensitive context. If attacker-controlled input contains a sequence that closes the comment, the serializer does not preserve it as literal comment text. Instead, it emits output where the remainder of the payload is treated as live XML markup.

This is a real injection bug, not a formatting issue. The serializer already applies context-aware handling in other places, such as escaping text nodes and rewriting unsafe CDATA terminators. Comment content does not receive equivalent treatment. Because of that gap, untrusted data can break out of the comment boundary and modify the structure of the final XML document.

PoC

const { DOMImplementation, DOMParser, XMLSerializer } = require('@&#8203;xmldom/xmldom');

const doc = new DOMImplementation().createDocument(null, 'root', null);

doc.documentElement.appendChild(
  doc.createComment('--><injected attr="1"/><!--')
);

const xml = new XMLSerializer().serializeToString(doc);
console.log(xml);
// <root><!----><injected attr="1"/><!----></root>

const reparsed = new DOMParser().parseFromString(xml, 'text/xml');
console.log(reparsed.documentElement.childNodes.item(1).nodeName);
// injected

Impact

An application that uses the package to build XML from untrusted input can be made to emit attacker-controlled elements outside the intended comment boundary. That allows the attacker to alter the meaning and structure of generated XML documents.

In practice, this can affect any workflow that generates XML and then stores it, forwards it, signs it, or hands it to another parser. Realistic targets include XML-based configuration, policy documents, and message formats where downstream consumers trust the serialized structure.

Disclosure

This vulnerability was publicly disclosed at 2026-04-06T11:25:07Z via xmldom/xmldom#987, which was subsequently closed without being merged.

Fix Applied

⚠ Opt-in required. Protection is not automatic. Existing serialization calls remain
vulnerable unless { requireWellFormed: true } is explicitly passed. Applications that pass
untrusted data to createComment() or mutate comment nodes with untrusted input (via
appendData, insertData, replaceData, .data =, or .textContent =) should audit all
serializeToString() call sites and add the option.

XMLSerializer.serializeToString() now accepts an options object as a second argument. When { requireWellFormed: true } is passed, the serializer throws InvalidStateError before emitting a Comment node whose .data would produce malformed XML.

On @xmldom/xmldom ≥ 0.9.10, the full W3C DOM Parsing §3.2.1.4 check is applied: throws if .data contains -- anywhere, ends with -, or contains characters outside the XML Char production.

On @xmldom/xmldom ≥ 0.8.13 (LTS), only the --> injection sequence is checked. The 0.8.x SAX parser accepts comments containing -- (without >), so throwing on bare -- would break a previously-working round-trip on that branch. The --> check is sufficient to prevent injection.

PoC — fixed path

const { DOMImplementation, XMLSerializer } = require('@&#8203;xmldom/xmldom');

const doc = new DOMImplementation().createDocument(null, 'root', null);
doc.documentElement.appendChild(doc.createComment('--><injected attr="1"/><!--'));

// Default (unchanged): verbatim — injection present
const unsafe = new XMLSerializer().serializeToString(doc);
console.log(unsafe);
// <root><!----><injected attr="1"/><!----></root>

// Opt-in guard: throws InvalidStateError before serializing
try {
  new XMLSerializer().serializeToString(doc, { requireWellFormed: true });
} catch (e) {
  console.log(e.name, e.message);
  // InvalidStateError: The comment node data contains "--" or ends with "-"  (0.9.x)
  // InvalidStateError: The comment node data contains "-->"  (0.8.x — only --> is checked)
}

Why the default stays verbatim

The W3C DOM Parsing and Serialization spec §3.2.1.4 defines a require well-formed flag whose default value is false. With the flag unset, the spec explicitly permits serializing ill-formed comment content verbatim — this is also the behavior of browser implementations (Chrome, Firefox, Safari): new XMLSerializer().serializeToString(doc) produces the injection sequence without error in all major browsers.

Unconditionally throwing would be a behavioral breaking change with no spec justification. The opt-in requireWellFormed: true flag allows applications that require injection safety to enable strict mode without breaking existing deployments.

Residual limitation

The fix operates at serialization time only. There is no creation-time check in createComment — the spec does not require one for comment data. Any path that leads to a Comment node with -- in its data (createComment, appendData, .data =, etc.) produces a node that serializes safely only when { requireWellFormed: true } is passed to serializeToString.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

xmldom/xmldom (@xmldom/xmldom@<0.8.12)

`v0.8.13`

Compare Source

Fixed

Security: XMLSerializer.serializeToString() (and Node.toString(), NodeList.toString()) now accept a requireWellFormed option (fourth argument, after isHtml and nodeFilter). When { requireWellFormed: true } is passed, the serializer throws InvalidStateError for injection-prone node content, preventing XML injection via attacker-controlled node data. GHSA-j759-j44w-7fr8 GHSA-x6wf-f3px-wcqx GHSA-f6ww-3ggp-fr8h
- Comment: throws when data contains -->
- ProcessingInstruction: throws when data contains ?>
- DocumentType: throws when publicId fails PubidLiteral, systemId fails SystemLiteral, or internalSubset contains ]>
Security: DOM traversal operations (XMLSerializer.serializeToString(), Node.prototype.normalize(), Node.prototype.cloneNode(true), Document.prototype.importNode(node, true), node.textContent getter, getElementsByTagName() / getElementsByTagNameNS() / getElementsByClassName() / getElementById()) are now iterative. Previously, deeply nested DOM trees would exhaust the JavaScript call stack and throw an unrecoverable RangeError. GHSA-2v35-w6hq-6mfw

Thank you,
@Jvr2022,
@praveen-kv,
@TharVid,
@decsecre583,
@tlsbollei,
@KarimTantawey,
for your contributions

Configuration

📅 Schedule: (UTC)

Branch creation
- ""
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

…urity]

chore(deps): update dependency @xmldom/xmldom@<0.8.12 to v0.8.13 [sec…

c7d48be

…urity]

renovate Bot added the dependencies Pull requests that update a dependency file label Apr 23, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore(deps): update dependency @xmldom/xmldom@<0.8.12 to v0.8.13 [security]#4434

chore(deps): update dependency @xmldom/xmldom@<0.8.12 to v0.8.13 [security]#4434
renovate[bot] wants to merge 1 commit intomasterfrom
renovate/npm-xmldom-xmldom@-0.8.12-vulnerability

renovate Bot commented Apr 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Apr 23, 2026

xmldom has XML node injection through unvalidated processing instruction serialization

Details

Summary

Details

Affected code

PoC

Minimal (from @​tlsbollei report, 2026-04-01)

With re-parse verification (from @​tlsbollei report)

Impact

Disclosure

Fix Applied

PoC — fixed path

Why the default stays verbatim

Residual limitation

Severity

References

xmldom has XML injection through unvalidated DocumentType serialization

Details

Summary

Details

Affected code

PoC

internalSubset injection

publicId quoting context break

systemId injection

Impact

Fix Applied

PoC — fixed path

Why the default stays verbatim

Residual limitation

Severity

References

xmldom has XML node injection through unvalidated comment serialization

Details

Summary

Details

PoC

Impact

Disclosure

Fix Applied

PoC — fixed path

Why the default stays verbatim

Residual limitation

Severity

References

Release Notes

v0.8.13

Fixed

Configuration

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Minimal (from @tlsbollei report, 2026-04-01)

With re-parse verification (from @tlsbollei report)

`v0.8.13`