Security Model
Tika's risks come in two kinds: untrusted data, which applies however you run Tika, and untrusted callers, which applies only when you expose tika-server or tika-grpc. Both rest on trusted configuration, covered last.
Untrusted data
Parsing untrusted data is dangerous. Our Security page documents fixed vulnerabilities in Tika and its dependencies: Denial of Service (policy below), XML external entity injection and server-side request forgery, command injection, and deserialization of untrusted objects.
Tika is routinely used on untrusted data, and the project invests heavily in handling it safely. Tika is not, however, a security boundary: it draws on many third-party format libraries, any of which may harbor undiscovered flaws. Assume a hostile file may crash, hang, or take over the parsing process, and run Tika with sandboxing, network isolation, resource limits, and least privilege appropriate to your threat model. See the Robustness of Apache Tika.
Mime detection and content extraction are error-prone, and files can be crafted to defeat both. Do not trust either without verification in high-risk applications such as cross-domain filtering or search.
Tika does not identify or render safe files crafted to trigger vulnerabilities or to create parser differentials (polyglots, chimeras, schizophrenic files, and the like).
Untrusted data: Denial of Service
Denial of Service is not a security issue when files are parsed in-process rather than in the built-in sandbox. Without sandboxing, untrusted data can exhaust memory or CPU or crash the process; containing that is the caller's responsibility. In 4.x the sandbox is tika-pipes, which parses each document in its own JVM with configurable timeouts and memory limits so that one malformed file cannot crash or hang your application; 3.x also offered ForkParser and tika-server's auto-restart.
An uncaught RuntimeException, StackOverflowError or OutOfMemoryError from an in-process parse is a bug -- please report it in JIRA -- not a vulnerability. We fix such bugs as we find them; we cannot promise there are none.
A document that defeats tika-pipes' own limits, however, is a security issue.
We welcome reports and pull requests that harden Tika against Denial of Service.
Untrusted data: extracted output
Tika's output is an extraction, not a sanitized rendering. The XHTML, text, and metadata Tika produces carry whatever the document contained: hyperlinks with any URI scheme, including javascript: and data:, formula-like cell values, control characters, and markup fragments.
Treat Tika's output as untrusted data. Sanitize it before rendering it in a browser, loading it into a spreadsheet, or interpolating it into another document. Hostile content in extracted output is the consumer's responsibility, not a vulnerability in Tika.
Untrusted callers
Expose tika-server and tika-grpc only on a trusted, access-controlled network, never to untrusted users or the public internet.
tika-server's most powerful capabilities -- per-request parser configuration and fetching/emitting via tika-pipes -- are off by default. A caller who reaches them can read and write as the server's user, defeat memory and timeout limits, and choose which components load and how documents parse. Keeping them off is defense in depth, not a substitute for restricting access: isolate the endpoints, use two-way TLS, and run with least privilege.
tika-grpc warrants more caution still: its RPCs can reconfigure the server at runtime and return pipes component credentials.
Securing access is the operator's responsibility, not the project's.
Trusted configuration
Configuration is trusted input. The tika-config.json and command line that start the process come from the operator, and a setting that enables a capability does what it was asked. A finding that requires the operator to have enabled an off-by-default capability -- per-request parser configuration or the /pipes endpoint -- is a hardening suggestion, not a vulnerability. The same access reached from a default configuration is a vulnerability.
The exception is configuration that does not do what it says. Tika rejects unknown keys at load time, so a typo fails loudly. A setting that is accepted and then silently has no effect -- a limit parsed but never enforced, a referenced file missing without an error -- leaves the operator believing they are protected when they are not. That is a security issue.