CVE-2025-66516

What it actually does

The flaw is an XML External Entity (XXE) vulnerability in Apache Tika’s PDF/XFA parsing path. A crafted PDF containing an XFA form can cause vulnerable Tika components to parse attacker-controlled XML with external entity resolution enabled. Depending on deployment and parser behavior, this can allow server-side file disclosure, outbound network requests from the Tika runtime, blind data exfiltration through attacker-controlled URLs, server-side request forgery to internal services, and denial-of-service through malicious XML constructs. The issue affects Tika 1.x and 2.x/3.x packaging paths: tika-core versions 1.13 through 3.2.1, tika-pdf-module versions 2.0.0 through 3.2.1, and tika-parsers versions 1.13 through 1.28.5. Upgrading only the PDF parser module is insufficient if the vulnerable tika-core dependency remains below the fixed level.

Why it matters to the business

Systems that use Apache Tika to extract text or metadata from uploaded, emailed, crawled, or otherwise untrusted PDFs may expose sensitive files, internal network services, credentials, tokens, or operational metadata to an attacker. Because Tika is commonly embedded inside search, document-management, e-discovery, DLP, content-scanning, and ingestion pipelines, exploitation can occur indirectly through normal document processing workflows rather than an obvious public endpoint. The vulnerability has a critical severity, high EPSS probability, and weaponized exploit maturity, so externally reachable or automated document-processing services should be treated as high-priority remediation targets even though it is not currently listed in CISA KEV and is not marked as ransomware-associated.

How an attack unfolds

An attacker first identifies an application or service that accepts PDFs and processes them with a vulnerable Apache Tika component. The attacker then creates a PDF containing an XFA form whose embedded XML includes a document type definition and external entity references. When the vulnerable Tika PDF parser extracts and processes the XFA content, the XML parser resolves those external entities. The resolved entity may point to a local file such as operating-system metadata, application configuration, credentials, or a cloud metadata endpoint or internal HTTP service. In a direct-response scenario, the resolved content may be included in parsed text, extracted metadata, logs, or downstream indexing results that the attacker can access. In a blind scenario, the attacker points entities to an attacker-controlled URL and observes DNS or HTTP callbacks from the Tika host, potentially using parameterized URLs to exfiltrate data. The same primitive may also be used to map internal network reachability or disrupt parsing through malicious XML input.

How to fix it

Upgrade all Apache Tika components that can participate in PDF parsing, not only the PDF parser module. Ensure tika-core is upgraded to a fixed version, specifically 3.2.2 or later for the 3.x line, or to a vendor release that contains commit c5c9d00e475d48226dfe3f80a2891bfa5426043a. For deployments using Tika 1.x, treat tika-parsers versions 1.13 through 1.28.5 as affected and upgrade to a fixed/vendor-supported release or migrate to a supported fixed Tika line. For deployments using tika-pdf-module versions 2.0.0 through 3.2.1, upgrade the module and verify the resolved tika-core dependency is also fixed. Regenerate dependency lockfiles, rebuild container images, and redeploy services so transitive dependencies are not left vulnerable. As compensating controls, restrict processing of untrusted PDFs, disable or sandbox XFA processing where feasible, run Tika with least-privilege filesystem access, block unnecessary outbound egress from Tika workers, deny access to cloud metadata endpoints, and isolate document-processing workloads from sensitive internal services.

How to confirm the fix worked

Confirm the effective runtime dependency graph, not just declared top-level package versions. Use build tooling such as Maven dependency:tree, Gradle dependencies, SBOM scanners, container image scanners, or runtime classpath inspection to verify that org.apache.tika:tika-core is 3.2.2 or later, or otherwise contains the fixed commit c5c9d00e475d48226dfe3f80a2891bfa5426043a. Verify that org.apache.tika:tika-pdf-module is not in the affected 2.0.0 through 3.2.1 range and that org.apache.tika:tika-parsers is not in the affected 1.13 through 1.28.5 range. Re-scan deployed artifacts and containers after redeployment to ensure stale libraries were removed. If safe testing is permitted, process a benign XFA PDF containing a non-sensitive external entity callback to a controlled internal canary service and confirm that the fixed parser does not perform DNS or HTTP resolution. Also validate that egress controls prevent document-processing services from reaching arbitrary external hosts and cloud metadata IPs.

Typical attack path

1. Find an application, API, file-ingestion pipeline, or Tika Server deployment that accepts or processes PDF files.
2. Confirm or infer that PDF content is parsed with vulnerable Apache Tika versions, especially tika-core before 3.2.2 or affected 1.x tika-parsers versions.
3. Build a PDF containing an XFA form with XML external entity declarations that reference local files, internal URLs, cloud metadata services, or attacker-controlled callback infrastructure.
4. Submit the crafted PDF through an upload, email, crawler, queue, document import, or content-analysis workflow.
5. Trigger Tika parsing of the PDF, causing the vulnerable XML parser to resolve external entities during XFA processing.
6. Collect leaked content from the application response, search index, extracted metadata, logs, or out-of-band DNS/HTTP callbacks.
7. Optionally iterate with additional entity targets to enumerate internal services, retrieve sensitive files, or cause parser/resource exhaustion.

How to detect it

Investigate both input artifacts and runtime behavior. Review application access logs, upload records, message-ingestion logs, Tika Server logs, document-processing job logs, parser exception logs, proxy logs, DNS logs, firewall logs, EDR telemetry, and cloud metadata access logs. Look for PDFs processed shortly before unusual outbound DNS or HTTP requests from Tika or document-ingestion hosts, especially to unfamiliar domains, IP literals, collaborator-style callback domains, or internal services that the document processor normally should not contact. Search stored PDFs, quarantines, temporary upload directories, and message attachments for XFA content containing XML DOCTYPE and ENTITY declarations. In application and Tika logs, look for XML parser errors, DTD-related messages, entity-resolution failures, references to XFA processing, or unexpected inclusion of local file contents in extracted text or metadata. For blind XXE attempts, correlate PDF parse timestamps with outbound requests to attacker-controlled infrastructure, cloud metadata endpoints, loopback addresses, RFC1918 addresses, link-local addresses, or unusual protocols. For successful direct exfiltration, review downstream search indexes, extracted-text stores, metadata databases, and logs for strings resembling sensitive local files, environment variables, service credentials, private keys, or internal HTTP responses.

• /XFA
• <xdp:xdp
• <!DOCTYPE
• <!ENTITY
• SYSTEM "file://
• SYSTEM 'file://
• SYSTEM "http://
• SYSTEM 'http://
• SYSTEM "https://
• SYSTEM 'https://
• 169.254.169.254
• http://169.254.169.254
• https://169.254.169.254
• file:///etc/passwd
• file:///etc/hosts
• file:///proc/self/environ
• file:///proc/self/cmdline
• file:///c:/windows/win.ini
• file:///C:/Windows/win.ini
• org.apache.tika.parser.pdf.PDFParser
• org.apache.tika.exception.TikaException
• SAXParseException
• DOCTYPE is disallowed
• External Entity
• Connection refused resolving external entity
• metadata.google.internal
• latest/meta-data
• /latest/meta-data/iam/security-credentials/

What your security team should do

• Immediately inventory applications, services, containers, and batch jobs that embed Apache Tika or run Tika Server for PDF processing.
• Prioritize internet-facing, partner-facing, email-ingestion, file-upload, search-indexing, and automated document-processing workflows for emergency upgrade or temporary isolation.
• Upgrade all affected Tika components together and verify the resolved tika-core version is fixed; do not rely on upgrading only tika-pdf-module.
• Add temporary network egress restrictions for Tika workers, including blocks for arbitrary outbound HTTP/HTTPS, DNS where not required, and cloud metadata addresses such as 169.254.169.254.
• Hunt historical logs for suspicious XFA PDFs, XML DTD/entity markers, and outbound DNS/HTTP callbacks from document-processing hosts around PDF parsing events.
• Review parsed-output stores, search indexes, application logs, and error logs for evidence that local file contents or internal URL responses were captured during extraction.
• Run Tika workloads under least-privilege accounts with minimal filesystem access and isolated network access to reduce impact from future parser vulnerabilities.
• Create detection content for PDFs containing XFA plus DOCTYPE or ENTITY declarations and for document-processing services making unexpected outbound connections.
• Where business workflows allow, reject or quarantine PDFs containing XFA forms until all processing paths are confirmed fixed.