Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
13 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.
Recommended action: Upgrade to 3.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.28.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. This was originally fixed in 1.28.2 and 2.4.0. While the fix in version 2.4.0 was complete, the fix for the 1.x branch wasn't incorporated until version 1.28.3. Please see GHSA-qw3f-w4pf-jh5f for more information.
Recommended action: Upgrade to 2.4.0 or 1.28.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.22 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 1.22 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A carefully crafted (or fuzzed) file can trigger an infinite loop in Apache Tika's BPGParser in versions of Apache Tika before 1.18.
Recommended action: Upgrade to 1.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Tika 1.2 to 1.18, a carefully crafted file can trigger an infinite loop in the IptcAnpaParser.
Recommended action: Upgrade to 1.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Tika 0.9 to 1.18, in a rare edge case where a user does not specify an extract directory on the commandline (--extract-dir=) and the input file has an embedded file with an absolute path, such as "C:/evil.bat", tika-app would overwrite that file.
Recommended action: Upgrade to 1.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Tika 0.1 to 1.18, the XML parsers were not configured to limit entity expansion. They were therefore vulnerable to an entity expansion vulnerability which can lead to a denial of service attack.
Recommended action: Upgrade to 1.19.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Tika before 1.14 allows Java code execution for serialized objects embedded in MATLAB files. The issue exists because Tika invokes JMatIO to do native deserialization.
Recommended action: Upgrade to 1.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Apache Tika before 1.13 does not properly initialize the XML parser or choose handlers, which might allow remote attackers to conduct XML External Entity (XXE) attacks via vectors involving (1) spreadsheets in OOXML files and (2) XMP metadata in PDF and other file formats, a related issue to CVE-2016-2175.
Recommended action: Upgrade to 1.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
From Apache Tika versions 1.7 to 1.17, clients could send carefully crafted headers to tika-server that could be used to inject commands into the command line of the server running tika-server. This vulnerability only affects those running tika-server on a server that is open to untrusted clients. The mitigation is to upgrade to Tika 1.18.
Recommended action: Upgrade to 1.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Apache Tika 1.19 (CVE-2018-11761), we added an entity expansion limit for XML parsing. However, Tika reuses SAXParsers and calls reset() after each parse, which, for Xerces2 parsers, as per the documentation, removes the user-specified SecurityManager and thus removes entity expansion limits after the first parse. Apache Tika versions from 0.1 to 1.19 are therefore still vulnerable to entity expansions which can lead to a denial of service attack. Users should upgrade to 1.19.1 or later.
Recommended action: Upgrade to 1.19.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.