Improper Protection of Alternate Path vulnerability in Apache Tika.
This issue affects Apache Tika: from 4.0.0-alpha-1 before 4.0.0-beta-1.
Users are recommended to upgrade to version 4.0.0-beta-1, which fixes the issue.
Last updated 4 September 2026
Critical XXE in Apache Tika tika-core (1.13-3.2.1), tika-pdf-module (2.0.0-3.2.1) and tika-parsers (1.13-1.28.5) modules on all platforms allows an attacker to carry out XML External Entity injection via a crafted XFA file inside of a PDF.
This CVE covers the same vulnerability as in CVE-2025-54988. However, this CVE expands the scope of affected packages in two ways.
First, while the entrypoint for the vulnerability was the tika-parser-pdf-module as reported in CVE-2025-54988, the vulnerability and its fix were in tika-core. Users who upgraded the tika-parser-pdf-module but did not upgrade tika-core to >= 3.2.2 would still be vulnerable.
Second, the original report failed to mention that in the 1.x Tika releases, the PDFParser was in the "org.apache.tika:tika-parsers" module.
Critical XXE in Apache Tika tika-core (1.13-3.2.1), tika-pdf-module (2.0.0-3.2.1) and tika-parsers (1.13-1.28.5) modules on all platforms allows an attacker to carry out XML External Entity injection via a crafted XFA file inside of a PDF.
Critical XXE in Apache Tika (tika-parser-pdf-module) in Apache Tika 1.13 through and including 3.2.1 on all platforms allows an attacker to carry out XML External Entity injection via a crafted XFA file inside of a PDF. An attacker may be able to read sensitive data or trigger malicious requests to internal resources or third-party servers. Note that the tika-parser-pdf-module is used as a dependency in several Tika packages including at least: tika-parsers-standard-modules, tika-parsers-standard-package, tika-app, tika-grpc and tika-server-standard.
All, FYI:
DARPA and ARPA-H are running a research competition called the "AI Cyber Challenge" (AIxCC). Its goal is to create automated tools that find and fix vulnerabilities in software. General information is here: <https://aicyberchallenge.com/>
The AIxCC semifinal competition was last week at DEF CON 32 (2024). All competitors were given an identical set of Challenge Projects, which were real-world OSS projects seeded with synthetic vulnerabilities. The projects were Jenkins, Linux kernel, Nginx, SQLite3, and Apache Tika. There were 7 winners; each winner received $2 million US as a reward, and those teams will be allowed to compete in the finals at next year's DEF CON.
An official summary is here: <https://www.darpa.mil/news-events/2024-08-11>. Some other interesting links related to the semifinals include: <https://blog.trailofbits.com/2024/08/09/trail-of-bits-buttercup-heads-to-darpas-aixcc/> <https://www.youtube.com/watch?v=sQKGWZvuLko>
One of the competing teams, Team Atlanta, even found a real-world bug in SQLite3. This was reported to SQLite through their usual process; it's fixed in trunk. More info about that specifically is here: - <https://x.com/TeamAtlanta24/status/1822739301463130271> - <https://sqlite.org/forum/forumpost/81670d1056>
The tools must be released by next year as open source software, with an OSI-approved license, as a condition for accepting prize money or competing in the final competition. Exact text is in the "Open-Source Requirement" section in its rules <https://aicyberchallenge.com/rules/>. The challenge problems were all based on real-world OSS, and the hope is that in the long term such tools can automatically find & fix vulnerabilities in all software including OSS.
Full disclosure: I work for the Open Source Security Foundation (OpenSSF) and I have been working with DARPA & ARPA-H supporting this. That said, I thought others in this mailing list would want to know about it. No research is guaranteed to produce something leading to useful results, but I think this is a promising approach. We definitely could use tools that automatically find & fix vulnerabilities, if they're good enough!!
--- David A. Wheeler
The initial fixes in CVE-2022-30126 and CVE-2022-30973 for regexes in the StandardsExtractingContentHandler were insufficient, and we found a separate, new regex DoS in a different regex in the StandardsExtractingContentHandler. These are now fixed in 1.28.4 and 2.4.1.
We failed to apply the fix for CVE-2022-30126 to the 1.x branch in the 1.28.2 release. In Apache Tika, a regular expression in the StandardsText class, used by the StandardsExtractingContentHandler could lead to a denial of service caused by backtracking on a specially crafted file.
Reference:
https://www.openwall.com/lists/oss-security/2022/05/31/2
We failed to apply the fix for CVE-2022-30126 to the 1.x branch in the 1.28.2 release. In Apache Tika, a regular expression in the StandardsText class, used by the StandardsExtractingContentHandler could lead to a denial of service caused by backtracking on a specially crafted file. This only affects users who are running the StandardsExtractingContentHandler, which is a non-standard handler. This is fixed in 1.28.3.
The BPG parser in versions of Apache Tika before 1.28.2 and 2.4.0 may allocate an unreasonable amount of memory on carefully crafted files.
In Apache Tika, a regular expression in our StandardsText class, used by the StandardsExtractingContentHandler could lead to a denial of service caused by backtracking on a specially crafted file. This only affects users who are running the StandardsExtractingContentHandler, which is a non-standard handler.
Reference:
http://www.openwall.com/lists/oss-security/2022/05/16/3
An XXE issue in SAXBuilder in JDOM through 2.0.6 allows attackers to cause a denial of service via a crafted HTTP request.
A carefully crafted or corrupt file may trigger an infinite loop in Tika's MP3Parser up to and including Tika 1.25. Apache Tika users should upgrade to 1.26 or later.
A carefully crafted or corrupt file may trigger a System.exit in Tika's OneNote Parser. Crafted or corrupted files can also cause out of memory errors and/or infinite loops in Tika's ICNSParser, MP3Parser, MP4Parser, SAS7BDATParser, OneNoteParser and ImageParser.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-9489 http://seclists.org/oss-sec/2020/q2/69 https://lists.apache.org/thread.html/r4d943777e36ca3aa6305a45da5acccc54ad894f2d5a07186cfa2442c%40%3Cdev.tika.apache.org%3E
A carefully crafted or corrupt file may trigger a System.exit in Tika's OneNote Parser. Crafted or corrupted files can also cause out of memory errors and/or infinite loops in Tika's ICNSParser, MP3Parser, MP4Parser, SAS7BDATParser, OneNoteParser and ImageParser.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-9489 http://seclists.org/oss-sec/2020/q2/69 https://lists.apache.org/thread.html/r4d943777e36ca3aa6305a45da5acccc54ad894f2d5a07186cfa2442c%40%3Cdev.tika.apache.org%3E
A carefully crafted or corrupt PSD file can cause an infinite loop in Apache Tika's PSDParser in versions 1.0-1.23.
A carefully crafted or corrupt PSD file can cause excessive memory usage in Apache Tika's PSDParser in versions 1.0-1.23.
A carefully crafted or corrupt zip file can cause an OOM in Apache Tika's RecursiveParserWrapper in versions 1.7-1.21. Users should upgrade to 1.22 or later.
A carefully crafted package/compressed file that, when unzipped/uncompressed yields the same file (a quine), causes a StackOverflowError in Apache Tika's RecursiveParserWrapper in versions 1.7-1.21. Apache Tika users should upgrade to 1.22 or later.
In Apache Tika 1.19 to 1.21, a carefully crafted 2003ml or 2006ml file could consume all available SAXParsers in the pool and lead to very long hangs. Apache Tika users should upgrade to 1.22 or later.
A carefully crafted or corrupt sqlite file can cause an infinite loop in Apache Tika's SQLite3Parser in versions 1.8-1.19.1 of Apache Tika.