Apache Tika is a powerful open-source content analysis toolkit used by enterprise applications to extract metadata and text from a wide range of file types, including PDFs, Microsoft Office documents, and others. Its widespread use as a backend library means that a vulnerability in Tika can have a cascading impact on countless applications that rely on it for file processing and data ingestion.

This vulnerability is particularly severe because it allows for unauthenticated information disclosure and network pivoting (SSRF). Any publicly exposed application that uses a vulnerable version of Tika to process user-uploaded files is at high risk. An attacker can simply upload a specially crafted PDF to read sensitive server-side files, such as credential files and source code, or to perform scans and attacks against internal network services not directly exposed to the Internet.

Critical: A public exploit is available, and reports indicate active exploitation in real-world environments. The complexity of the affected components (tika-core, tika-pdf-module, tika-parsers) increases the likelihood that patches may be applied incompletely, leaving systems exposed. Organizations must treat this issue as a critical and urgent threat.

Product	Apache Tika
Date	2025-12-06 00:33:00

Technical Summary

The technical cause of this vulnerability is CWE-611: Improper Restriction of XML External Entity Reference, commonly known as XXE injection. The flaw exists within the core Apache Tika library (tika-core) during the parsing of XML Forms Architecture (XFA) data that can be embedded in PDF files. The XML parser responsible for handling XFA forms does not disable the resolution of external entities.

The attack chain is as follows:

1. An attacker creates a malicious PDF file containing an embedded XFA form. Within the XML data of this form, the attacker includes a malicious DTD (Document Type Definition) with an external entity declaration.
2. This entity points to a local file resource (e.g., file:///etc/passwd) or an internal network resource.
3. The attacker uploads this PDF to a server-side application that uses a vulnerable version of Apache Tika for processing.
4. When Tika’s PDF parser processes the file, it encounters the malicious XFA data, resolves the external entity, and embeds the content of the requested resource (e.g., the content of /etc/passwd) into the parsed XML output, which can then be exfiltrated by the attacker.

A conceptual example of a malicious entity within XFA data is:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
   <!ENTITY % xxe SYSTEM "file:///etc/shadow">
   %xxe;
]>
<root/>

Note: This is a conceptual example, not a functional payload.

Affected versions:

• tika-core: Versions 1.13 through 3.2.1
• tika-pdf-module: Versions 2.0.0 through 3.2.1
• tika-parsers: Versions 1.13 through 1.28.5

The vulnerability is fixed in subsequent versions. Due to the complex dependency chain, it is critical to ensure that the underlying tika-core library is updated.

Recommendations

• Apply the patch immediately: Update all affected Apache Tika components to the latest available versions. Ensure that the underlying tika-core library is updated beyond version 3.2.1 and that tika-parsers is updated beyond version 1.28.5. Verify dependencies in your project build files (pom.xml, build.gradle, etc.) to confirm that the correct versions are deployed.

• Mitigations:

  • If you cannot apply the patch immediately, consider implementing a temporary check to reject PDF file uploads or route them through a sandbox environment for processing.
  • If the application allows it, programmatically configure the XML parser used by Tika to explicitly disable external entity resolution. This acts as a robust secondary defense.
  • Use a Web Application Firewall (WAF) with rules designed to inspect file contents, although detecting XXE within complex binary formats like PDFs can be unreliable.

• Investigation and Monitoring:

  • Monitor application logs for XML parsing error messages, particularly those containing keywords such as DOCTYPE, ENTITY, or SYSTEM.
  • Examine network traffic originating from application servers for any unusual requests to internal IP addresses or external URLs that are not part of normal operations, as this could indicate SSRF activity.
  • Audit file upload directories to identify suspicious PDFs, especially those that are small in size but cause processing errors.

• Incident Response:

  • If a compromise is suspected, immediately isolate the host from the network to prevent further data exfiltration or lateral movement.
  • Assume that all secrets, credentials, and API keys stored or accessible on the compromised server have been compromised and initiate rotation procedures.
  • Conduct a forensic analysis of the isolated system to determine the extent of the breach and identify any files that were accessed.

• Defense in Depth:

  • Run your web application with the lowest possible user privileges to limit the impact of arbitrary file reads.
  • Implement strict network segmentation and firewall rules to prevent web servers from establishing arbitrary connections to internal database servers, administrative consoles, and other sensitive resources.