There have been several CVE fixed in libexpat (at this time 2.7.3) since the 2.7.1 version that in tDOM 0.9.6:

https://nvd.nist.gov/vuln/detail/CVE-2025-59375 https://nvd.nist.gov/vuln/detail/CVE-2024-8176

Detail:

Release 2.7.3 Wed September 24 2025 Security fixes: #1046 #1048 Fix alignment of internal allocations for some non-amd64 architectures (e.g. sparc32); fixes up on the fix to CVE-2025-59375 from #1034 (of Expat 2.7.2 and related backports) #1059 Fix a class of false positives where input should have been rejected with error XML_ERROR_ASYNC_ENTITY; regression from CVE-2024-8176 fix pull request #973 (of Expat 2.7.0 and related backports). Please check the added unit tests for example documents.

Release 2.7.2 Tue September 16 2025 Security fixes: #1018 #1034 CVE-2025-59375 -- Disallow use of disproportional amounts of dynamic memory from within an Expat parser (e.g. previously a ~250 KiB sized document was able to cause allocation of ~800 MiB from the heap, i.e. an "amplification" of factor ~3,300); once a threshold (that defaults to 64 MiB) is reached, a maximum amplification factor (that defaults to 100.0) is enforced, and violating documents are rejected with an out-of-memory error. There are two new API functions to fine-tune this new behavior: - XML_SetAllocTrackerActivationThreshold - XML_SetAllocTrackerMaximumAmplification . If you ever need to increase these defaults for non-attack XML payload, please file a bug report with libexpat. There is also a new environment variable EXPAT_MALLOC_DEBUG=(0|1|2) to control the verbosity of allocations debugging at runtime, disabled by default. Known impact is (reliable and easy) denial of service: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:H/RL:O/RC:C (Base Score: 7.5, Temporal Score: 7.2) Please note that a layer of compression around XML can significantly reduce the minimum attack payload size. Distributors intending to backport (or cherry-pick) the fix need to copy 99% of the related pull request, not just the "lib: Implement tracking of dynamic memory allocations" commit, to not end up with a state that literally does both too much and too little at the same time. Appending ".diff" to the pull request URL could be of help.

Any plan to update to 2.7.3 (or higher) in next tDOM version to come?

Since [7000c5173b] (two month ago) the bundled expat is 2.7.3. Feel invited to use trunk. The next release will include it (or its successor). 

Since the tdom build system easily allows to build tDOM with the system expat you don't need a new tDOM release, for every expat CVE you are concerned about. If you have concerns about expat CVEs just build yourself.

Thanks, rolf. Here I'm on a corporate process: we only build from the sources of releases and avoid as much as possible dependencies to system stuff. Next time I'll read the changelog from trunk!

By the way, I could not find any CPE for tDOM, that would allow people to report/track CVEs bound to tDOM versions, if any, do you know why there is not such CPE (that's not expat-related here).

Not sure what you ask for with CPE here, though from the context perhaps Common Platform Enumeration. If yes then no, I'm also not aware of a CPE for tDOM.