File extraction is a trust boundary that most teams never draw. A service accepts an upload, identifies the type, parses it and returns text. Tika does exactly that, and it does it for PDF, Office, email and a long list of formats. CVE-2025-66516 is what happens when the PDF parser follows a reference out of the document instead of staying inside it.
The vulnerability in one paragraph
Tika's PDF module handled XFA payloads in a way that permitted XML external entity processing. An uploaded PDF carrying a crafted XFA block caused the parser to resolve an external entity, which can read local files or make outbound requests from the parsing host, and in the right configuration can be escalated further. The score is a clean ten. The vendor advisory is GHSA-f58c-gq56-vjjf, and the issue supersedes an earlier, narrower report tracked as CVE-2025-54988.
The affected surface is version-dependent in a way that catches people out. In the tika-core line the range runs from old releases through versions before the fix. The PDF module moved between artefacts across major versions, so a deployment can be affected in the parsers jar while the core jar is clean. Checking a single dependency version is not sufficient; the check has to cover the module that actually parses PDFs.
Why an unauthenticated ten matters here
A CVSS score describes the flaw, not the deployment. What makes this rating realistic is the position Tika usually occupies. It is a library inside a service that accepts files from users, and the whole point of that service is to accept files from users. There is no authentication gate between the upload and the parser in the normal architecture, because extraction happens before any decision about the file is made.
So the practical question is not whether the parser is reachable. It is what the parsing process can read. In a containerised deployment the answer is often smaller than people fear and larger than it should be: the application's own configuration, its database credentials, and any mounted secret. In a deployment where Tika runs beside the application on a virtual machine, the answer includes the application's files and whatever the service account can reach.
The follow-on issue
A second record, CVE-2026-66755, covers Tika releases below the later fix line in the core and alpha branches. Whether it is exploitable in a given deployment depends on the same question as the first: which module parses the input, and what the parser is allowed to resolve. Treating the two as a single upgrade task is the practical approach, because the fix releases overlap and the module boundaries are confusing enough that partial patching is likely.
What to change
- 1.
Identify every place the PDF parser runs, including legacy pipelines, batch jobs and extraction functions embedded in a larger service. The version that matters is the one in the jar that parses the file.
- 2.
Upgrade to a fixed release across core, parsers and the PDF module rather than one artefact at a time.
- 3.
Disable external entity resolution and remote schema loading at the parser level, and confirm the setting applies to XFA handling rather than only to plain XML input.
- 4.
Run extraction in a sandbox with no network egress and a read-only filesystem apart from a scratch directory. A parser that cannot make outbound requests converts file read into a much smaller problem.
- 5.
Strip or reject XFA payloads before parsing if the business process does not need them, since most document workflows read the rendered page rather than the interactive form definition.
The general lesson
Document extraction is a parser exposed to hostile input by design, which makes it an unusual case: the vulnerability class is inherent to the feature, not a mistake in the implementation. That argues for containment rather than for vigilance alone. Assume the parser will be exploited at some point, and arrange matters so that a successful exploit yields a scratch directory rather than a credential store.
References
GitHub Security Advisory GHSA-f58c-gq56-vjjf, Apache Tika XXE through PDF XFA, fixed in 3.2.2.
NVD record for CVE-2025-66516, CVSS 10.0, affected core, parsers and PDF module ranges.
NVD record for CVE-2025-54988, the earlier narrower report superseded by the above.
NVD record for CVE-2026-66755, additional Tika fix line.