`Entity expansion limit exceeded` error in 4.5.5

[H1Gdev]

• Are you running the latest version?
• Have you included sample input, output, error, and expected output?
• Have you checked if you are using correct configuration?
• Did you try online tool?
• Have you checked the docs for helpful APIs and examples?

Description

• 4.5.5
  Entity expansion limit exceeded: 1088 > 1000
• 4.5.4
  parse operation succeeds.

Compatibility was not maintained between version 4.5.4 and 4.5.5.

The following was found in CHANGELOG.md:

**5.3.6 / 2026-02-14**
- Improve security and performance of entity processing
  - new options `maxEntitySize`, `maxExpansionDepth`, `maxTotalExpansions`, `maxExpandedLength`, `allowedTags`,`tagFilter`
  - fast return when no edtity is present
  - improvement replacement logic to reduce number of calls

Input

Input XML file is the same for both 4.5.4 and 4.5.5 tests.

Code

  const options = {
    ignoreAttributes: false,
  };
  const parser = new XMLParser(options);
  const xmpObject = parser.parse(buffer.toString('utf8'), true);

Output

Entity expansion limit exceeded: 1088 > 1000

expected data

parse operation succeeds.

Would you like to work on this issue?

• Yes
• No

Bookmark this repository for further updates. Visit SoloThought to know about recent features.

[github-actions]

We're glad you find this project helpful. We'll try to address this issue ASAP. You can vist https://solothought.com to know recent features. Don't forget to star this repo.

[ryanpeggs]

+1

We use this library to parse medical data in the FHIR standard (https://fhir.org/)
Nearly all FHIR resources exceed 1000 expansions!

After 4.5.5 was released (and triggered errors in our app) we overrode the limit from 1000 to 0 (infinite)

Your subsequent commit has broken this override

Please give us back infinite expansions! @amitguptagwl

[amitguptagwl]

Apologies for inconvenience caused. This is the difference between both versions.

      enabled: value.enabled !== false, // default true if not specified
-      maxEntitySize: value.maxEntitySize ?? 10000,
-      maxExpansionDepth: value.maxExpansionDepth ?? 10,
-      maxTotalExpansions: value.maxTotalExpansions ?? 1000,
-      maxExpandedLength: value.maxExpandedLength ?? 100000,
+      enabled: value.enabled !== false,
+      maxEntitySize: Math.max(1, value.maxEntitySize ?? 10000),
+      maxExpansionDepth: Math.max(1, value.maxExpansionDepth ?? 10),
+      maxTotalExpansions: Math.max(1, value.maxTotalExpansions ?? 1000),
+      maxExpandedLength: Math.max(1, value.maxExpandedLength ?? 100000),
+      maxEntityCount: Math.max(1, value.maxEntityCount ?? 100),

infinite expansion is removed to handle a special vulnerability because it was letting attacker by pass the checks. So setting them to something higher like 10000 or 50000 should still work in your case.

[H1Gdev]

@amitguptagwl
Thank you for your response.

I understand that starting with version 4.5.5, package users need to set maxTotalExpansions.

[jgrant95]

It's still not great to have released this as a patch - this is a breaking change.

Think this will cause issues across many apps - this broke one of our pipelines and caught it prior to being deployed anywhere.

I'd advise reviewing this personally, but maybe there's more to this - would be interested to know more. Thanks.

[sgarner]

This caused breaking errors in production for me as well.

In response, at first I raised maxTotalExpansions to 5000, then to 64000, but the numbers in the errors just got bigger as well. So I set it to maxTotalExpansions: Infinity to get around this "feature".

I see v5.5.7 or v5.5.9 made further changes related to this but it's unclear what they were addressing.

[amitguptagwl]

@jgrant95 This was a security vulnerability. So it was supposed to be released as minor version.
@sgarner though I tried to apply most of the security changes to v4.x. Did you find any miss? I believe what you're referring are typings fix which is not applicable to v4.
@H1Gdev Yes if it is out of safe range or the default value.

If you guys feel that security fixes are not needed for your project then you can stick to particular version to avoid anything breaking your pipeline. I'm any way not planning any feature release on v4.x. This way you'll be safe.

If an XML need these many entity replacement, do you think JS based parser is suitable for your project? I believe Java, C++, or Python would be a faster approach.

[sgarner]

To clarify, my experience was after updating from v5.3.8 to v5.5.7 - I'm not using v4.

I've not seen any performance issue with many entities, fast-xml-parser is fast! (The affected documents have some attributes containing encoded XML, so a lot of </>)

[ondrejnedoma]

This is a breaking change and should have been released as a new major version. I use this great library on my website to process XML feeds of products from my suppliers and these XMLs are tens of megabytes and it makes sense to trust my suppliers' XMLs. I will be setting the maxTotalExpansions to Infinity

[amitguptagwl]

I've increased the default limit to following.

maxEntitySize: 10000,
maxExpansionDepth: 10000,
maxTotalExpansions: Infinity,
maxExpandedLength: 100000,
maxEntityCount: 1000,

I hope this helps.

This is very difficult to take optimal decision when working alone. Is there any platform or way where I can announce the changes before release discuss the severity of release so necessary changes can be done instead of breaking the changes. Discord or something for announcing? mails?

In past, I tried to discuss few scenarios through Github issues/discussion but unfortunately received no response.