Hi Jeremy, Xavier,

There are a couple of old and new CVEs related to fast-xml-parser,
which is provided by node-webfont, but we were not yet able to
properly assess them. The list ist as follows, if you can investigate
thiat would be great:

CVE-2023-26920[0]:
| fast-xml-parser before 4.1.2 allows __proto__ for Prototype
| Pollution.


CVE-2026-25896[1]:
| fast-xml-parser allows users to validate XML, parse XML to JS
| object, or build XML from JS object without C/C++ based libraries
| and no callback. From 4.1.3to before 5.3.5, a dot (.) in a DOCTYPE
| entity name is treated as a regex wildcard during entity
| replacement, allowing an attacker to shadow built-in XML entities
| (<, >, &, ", ') with arbitrary values. This
| bypasses entity encoding and leads to XSS when parsed output is
| rendered. This vulnerability is fixed in 5.3.5.


CVE-2026-26278[2]:
| fast-xml-parser allows users to validate XML, parse XML to JS
| object, or build XML from JS object without C/C++ based libraries
| and no callback. In versions 4.1.3 through 5.3.5, the XML parser can
| be forced to do an unlimited amount of entity expansion. With a very
| small XML input, it’s possible to make the parser spend seconds or
| even minutes processing a single request, effectively freezing the
| application. Version 5.3.6 fixes the issue. As a workaround, avoid
| using DOCTYPE parsing by `processEntities: false` option.


CVE-2026-27942[3]:
| fast-xml-parser allows users to validate XML, parse XML to JS
| object, or build XML from JS object without C/C++ based libraries
| and no callback. Prior to version 5.3.8, the application crashes
| with stack overflow when user use XML builder with
| `preserveOrder:true`. Version 5.3.8 fixes the issue. As a
| workaround, use XML builder with `preserveOrder:false` or check the
| input data before passing to builder.


CVE-2026-33036[4]:
| fast-xml-parser allows users to process XML from JS object without
| C/C++ based libraries or callbacks. Versions 4.0.0-beta.3 through
| 5.5.5 contain a bypass vulnerability where numeric character
| references (&#NNN;, &#xHH;) and standard XML entities completely
| evade the entity expansion limits (e.g., maxTotalExpansions,
| maxExpandedLength) added to fix CVE-2026-26278, enabling XML entity
| expansion Denial of Service. The root cause is that
| replaceEntitiesValue() in OrderedObjParser.js only enforces
| expansion counting on DOCTYPE-defined entities while the
| lastEntities loop handling numeric/standard entities performs no
| counting at all. An attacker supplying 1M numeric entity references
| like A can force ~147MB of memory allocation and heavy CPU
| usage, potentially crashing the process—even when developers have
| configured strict limits. This issue has been fixed in version
| 5.5.6.


CVE-2026-33349[5]:
| fast-xml-parser allows users to process XML from JS object without
| C/C++ based libraries or callbacks. From version 4.0.0-beta.3 to
| before version 5.5.7, the DocTypeReader in fast-xml-parser uses
| JavaScript truthy checks to evaluate maxEntityCount and
| maxEntitySize configuration limits. When a developer explicitly sets
| either limit to 0 — intending to disallow all entities or restrict
| entity size to zero bytes — the falsy nature of 0 in JavaScript
| causes the guard conditions to short-circuit, completely bypassing
| the limits. An attacker who can supply XML input to such an
| application can trigger unbounded entity expansion, leading to
| memory exhaustion and denial of service. This issue has been patched
| in version 5.5.7.


CVE-2026-41650[6]:
| fast-xml-parser allows users to process XML from JS object without
| C/C++ based libraries or callbacks. Prior to version 5.7.0,
| XMLBuilder does not escape the "-->" sequence in comment content or
| the "]]>" sequence in CDATA sections when building XML from
| JavaScript objects. This allows XML injection when user-controlled
| data flows into comments or CDATA elements, leading to XSS, SOAP
| injection, or data manipulation. This issue has been patched in
| version 5.7.0.


CVE-2026-73569[7]:
| fast-xml-parser allows users to process XML from JS object without
| C/C++ based libraries or callbacks. From 5.9.3 until 5.10.1,
| src/xmlparser/OrderedObjParser.js processes multiple DOCTYPE
| declarations within a single XML document and passes each
| declaration's entities through addInputEntities().
| addInputEntities() resets maxTotalExpansions and maxExpandedLength
| every time it is called, allowing additional DOCTYPE declarations to
| repeatedly reset the configured entity-expansion limits during one
| parse operation. A crafted XML document can then cause excessive CPU
| use, event-loop blocking, memory exhaustion, and process
| termination. This issue is fixed in version 5.10.1.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-26920
https://www.cve.org/CVERecord?id=CVE-2023-26920
[1] https://security-tracker.debian.org/tracker/CVE-2026-25896
https://www.cve.org/CVERecord?id=CVE-2026-25896
[2] https://security-tracker.debian.org/tracker/CVE-2026-26278
https://www.cve.org/CVERecord?id=CVE-2026-26278
[3] https://security-tracker.debian.org/tracker/CVE-2026-27942
https://www.cve.org/CVERecord?id=CVE-2026-27942
[4] https://security-tracker.debian.org/tracker/CVE-2026-33036
https://www.cve.org/CVERecord?id=CVE-2026-33036
[5] https://security-tracker.debian.org/tracker/CVE-2026-33349
https://www.cve.org/CVERecord?id=CVE-2026-33349
[6] https://security-tracker.debian.org/tracker/CVE-2026-41650
https://www.cve.org/CVERecord?id=CVE-2026-41650
[7] https://security-tracker.debian.org/tracker/CVE-2026-73569
https://www.cve.org/CVERecord?id=CVE-2026-73569

Regards,
Salvatore