Tim Allison

**Name of the Vulnerable Software and Affected Versions** tika-core versions 1.13 through 3.2.1 tika-parser-pdf-module versions 2.0.0 through 3.2.1 tika-parsers versions 1.13 through 1.28.5 **Description** Apache Tika incorrectly handles XML external entities when parsing XFA (XML Forms Architecture) content embedded in PDF files. This allows a remote attacker to perform XML External Entity (XXE) injection by using a crafted XFA file inside a PDF. The issue stems from the XML parser in `tika-core` failing to restrict external XML references. Successful exploitation can lead to local file disclosure, Server-Side Request Forgery (SSRF), Denial of Service (DoS), or remote code execution in certain exploit chains. The vulnerability affects embedded Tika deployments using the default JDK StAX parser. Approximately 200 hosts in the RuNet segment are identified as using Apache Tika, with an estimated 95% being vulnerable. **Recommendations** Update tika-core, tika-parser-pdf-module, and tika-parsers to version 3.2.2. As a temporary workaround, disable or restrict the processing of XFA-PDF files. Isolate Tika processes using a sandbox, restrict file system access permissions, and prohibit outgoing network requests.

**Name of the Vulnerable Software and Affected Versions** Apache Tika versions 0.9 through 1.18 **Description** The issue arises in a rare edge case where a user does not specify an extract directory on the command line and the input file has an embedded file with an absolute path. For example, if the input file contains "C:/evil.bat", tika-app would overwrite that file. **Recommendations** For Apache Tika versions 0.9 through 1.18, consider specifying an extract directory on the command line using the --extract-dir option to avoid potential file overwrites. As a temporary workaround, restrict the use of absolute paths in embedded files to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Apache Tika server (aka tika-server) version 1.9 **Description** The issue allows remote attackers to read arbitrary files via the HTTP `fileUrl` header. This is possible when Apache Tika is used as a web service, enabling a 3rd party to pass a `fileUrl` header to the Apache Tika Server. The header lets a remote client request that the server fetches content from the URL provided, including files from the server's local filesystem. Depending on the file permissions set on the local filesystem, this could be used to return sensitive content from the server machine. **Recommendations** For Apache Tika server version 1.9, consider updating to version 1.10 or later to resolve the issue. As a temporary workaround, restrict access to the tika-server URL to prevent un-trusted access. Additionally, consider disabling the `fileUrl` header functionality until a patch is applied.