This CVE reveals a design assumption violation rather than a missing security feature. The fast-xml-parser library explicitly provides maxTotalExpansions and maxExpandedLength controls — developers who configured these limits did everything right. What the parser's internal architecture does, however, violates the implicit contract: addInputEntities() reinitializes these counters on every DOCTYPE declaration, treating each one as a fresh parsing context instead of accumulating across the document. A properly configured parser with a 1000-expansion limit can be bypassed by simply including 1000 DOCTYPE declarations, each defining entities that would individually stay under the threshold.
The vulnerability exists in versions 5.9.3 through 5.10.0. The fix in 5.10.1 should be scrutinized for whether it makes addInputEntities() idempotent (preserving cumulative state) or merely limits DOCTYPE count to one — the latter treats a symptom while leaving the underlying architectural pattern intact.
What makes this analytically significant: the gap between configuration-time intent and runtime behavior. You set limits expecting a hard ceiling on entity expansions across the parse; the parser resets those limits at each DOCTYPE boundary. This is a class of vulnerability where the protective mechanism itself becomes the attack surface.
Prioritise these actions: First, verify your fast-xml-parser version and upgrade to 5.10.1 or later immediately. Second, audit your codebase for any calls to addInputEntities() — if you're invoking it manually, understand whether your usage pattern triggers the reset. Third, search the codebase for similar stateful reset patterns: functions that accept configuration at initialization but reinitialize that configuration when called during parsing. Fourth, consider whether your XML processing pipelines ever legitimately need multiple DOCTYPE declarations — if not, rejecting documents with more than one DOCTYPE is a defense-in-depth measure that doesn't depend on the parser's internal behavior.
The EPSS of 0.00371 suggests limited automated exploitation so far, but that reflects the precondition complexity (crafted documents with many DOCTYPEs), not the severity of impact. The library's 2.8 million weekly downloads mean this vulnerability likely sits inside transitive dependencies you didn't directly choose — audit your dependency tree.