Security

The model states that Tika is used on untrusted data every day and that the project invests in handling it safely, but that Tika itself is not a security boundary. It depends on many third-party format libraries (PDFBox, POI, Commons Compress, metadata-extractor, and many more), any of which can contain an undiscovered flaw. The working assumption is that a hostile file may crash the parsing process, hang it or take it over. The defences are yours: sandboxing, network isolation, resource limits and least privilege, sized to your threat model.

Two further statements matter for an intake service:

This is the rule most people get wrong. When you call AutoDetectParser (or the Tika facade, or any parser) directly, the parse runs on your thread and in your heap. The model says that denial of service is then not a security issue: an OutOfMemoryError, a StackOverflowError, an endless loop or a crash caused by a malformed file is a bug to report in JIRA, and containing it is the caller’s responsibility. The 4.1.x security page adds that the limits (output-limits.writeLimit, embedded-limits.maxCount, the metadata limiter) bound what a parse produces, not the work it does to produce it.

Process isolation changes this, and it is a mechanism rather than advice. Tika Pipes, PipesForkParser, tika-server and tika-grpc parse each document in a forked JVM. A parse that runs out of memory, hangs or crashes kills the fork, not your process: the fork is restarted and the caller gets a status (OOM, TIMEOUT or UNSPECIFIED_CRASH, HTTP 503 from tika-server) instead of a dead JVM.

The boundary is conditional. A document that defeats the limits of Pipes itself (escaping the heap ceiling, the timeout or the process boundary) is a bug in Tika that the project treats as a security issue.

Source: Apache Tika, Security Model and Apache Tika 4.1.x, Security (In-Process Parsing and Denial of Service).

Tika’s output is an extraction, not a sanitised rendering. The XHTML, Markdown, text and metadata carry whatever the file contained: hyperlinks with any URI scheme (including javascript: and data:), cell values that look like formulas, control characters and fragments of markup. The security model makes hostile content in the output the consumer’s responsibility. For Bookshelf that means:

The tika-config.json file and the command line that start the process come from the operator. Tika rejects unknown keys at load time, so a typo fails loudly, and per-request configuration is off by default. The consequences:

Report a suspected vulnerability privately to security@apache.org, following the Apache Software Foundation security process. Do not open a public JIRA issue or a GitHub pull request for it. Ordinary robustness bugs (an in-process OOM, a parser exception) go to the Tika JIRA as usual.

tika-server binds to localhost unless told otherwise. -h (or --host, or server.host in the JSON) changes it, and -h * is translated to 0.0.0.0, all interfaces. Started from the zip with only a port:

Output:

The official Docker image is different: its entry point already passes -h 0.0.0.0, so inside the container the server listens on every interface, and the documentation says not to pass -h again. What reaches it is then decided by how you publish the port. Publish it on the host’s loopback only, or not at all when the caller runs in the same Docker network or Kubernetes namespace:

A plain -p 9998:9998 publishes the port on every host interface, and Docker’s own firewall rules can bypass a host firewall such as ufw. That is the most common way a Tika instance ends up on the internet.

Source: Apache Tika 4.1.x, Tika Server (Command Line Options) and Apache Tika 4.1.x, Running Tika in Docker. The Docker commands were not run for this page; the image facts come from the 4.1.x Docker page.

The image also runs as UID/GID 35002, not root, and keeps the distribution in a root-owned /opt/tika-server. Keep it that way: do not add --user root, and mount configuration read-only (:ro). The Docker & Kubernetes Deployment page covers resource limits and health checks; Docker: Security covers container hardening in general.

tika-server has no built-in token, API-key, JWT or OAuth2 support. The TLS page of the 4.1.x documentation recommends the common shape: a reverse proxy (nginx, Apache httpd, Traefik) or an API gateway terminates TLS and authenticates callers, and Tika runs on plain HTTP on loopback or a private network behind it. The proxy is also the natural place for a path allow-list (so /config, /pipes and /async are unreachable even if a flag is turned on by mistake), a body size limit, timeouts and rate limits.

An nginx sketch for the Bookshelf intake service: only PUT to /tika, /rmeta and /detect, after an authentication sub-request to the application’s own auth service. The names auth.internal and tika are placeholders for your services.

Source: Apache Tika 4.1.x, TLS/SSL Configuration (Should you configure TLS here at all?), nginx, ngx_http_auth_request_module and nginx, client_max_body_size. This configuration was not run for this page; validate it with nginx -t and a test request for every blocked path.

Two details matter. First, the proxy’s body limit should be at or below tika-server’s maxRequestSizeBytes, so oversize uploads are refused at the edge. Second, a path allow-list must match the 4.x endpoint shapes: 4.x names the output format in the path (/tika/text, /rmeta/md) instead of the 3.x Accept header, and per-request configuration lives under /config path segments, which the regular expression above never matches.

The flags below limit what a caller who reaches Tika can do. The documentation is explicit that they are defence in depth, not security boundaries: they do not make it safe to expose the service to untrusted callers. All default to off.

There is no command-line flag for any of these: -h, -p, -i and --metricsPort are the only options that override the JSON, and everything else (the flags, CORS, TLS, timeouts) is JSON-only. That is deliberate: enabling a dangerous capability is a visible line in a reviewed file.

The behaviour, observed on the tika-server 4.1.0 started above with the default configuration:

And with { "server": { "port": 19825, "endpoints": ["tika", "rmeta", "pipes"] } }, the server stops at start-up (the message as logged, stack trace omitted):

Source: Apache Tika 4.1.x, Tika Server (Security, Configuration) and Apache Tika 4.1.x, Tika gRPC (Capability flags).

The configuration the Bookshelf intake service runs with: loopback only, the four endpoints it uses, a 50 MiB request limit, TLS with the keystore password from the environment, redacted exception messages, and both capability flags at their default (off), which is why they are not in the file.

Started with a self-signed PKCS12 keystore made by keytool and the password exported from the shell (never written to a file), then probed:

Output (log lines abridged):

The plain-HTTP request gets a TLS record back, which curl refuses to read as HTTP. /unpack is not listed under endpoints, so it does not exist (404), and the 60 MiB body is refused before any parse starts. The keystore used for this page was a throwaway self-signed file.

Source: Apache Tika 4.1.x, Tika Server (Configuration) and Apache Tika 4.1.x, TLS/SSL Configuration.

tika-server’s TLS lives in server.tlsConfig (active, keyStoreType, keyStoreFile, keyStorePassword, the trustStore* trio, clientAuthenticationWanted, clientAuthenticationRequired, includedProtocols defaulting to TLS 1.2 and 1.3, cipher-suite lists and certExpirationWarningDays). With clientAuthenticationRequired and a truststore it becomes two-way TLS, which is real caller authentication: only holders of a client certificate the truststore trusts can connect. That is the one form of authentication Tika can do by itself, and the server logs that its TLS configuration is still beta.

For most deployments a proxy or mesh terminating TLS is simpler (certificate rotation, metrics, rate limiting). Use tika-server’s own TLS when there is no proxy, when you want client certificates end to end, or as a second layer behind the proxy. The Tika Server (REST API) page has the full key table.

tika-grpc configures TLS only on the command line (--secure, --cert-chain, --private-key, --private-key-password, --trust-cert-collection, --client-auth-required); there is no JSON for it, and its default is plaintext and unauthenticated, including the apache/tika-grpc Docker image, whose entry point does not pass --secure. The gRPC page states that it is more exposed than tika-server by default, because its FetchAndParse RPC is always on: anyone who reaches the port can fetch and parse whatever the configured fetchers reach.

Source: Apache Tika 4.1.x, Tika gRPC (Transport security). Not run for this page; the Tika gRPC page covers the service in full.

Pod networking in Kubernetes is flat by default: any pod can reach any other pod’s port, unencrypted and unauthenticated. The gRPC page makes the distinction that also applies to tika-server: a service mesh with mTLS authenticates who opened the connection, it does not authorise what that caller may do. Because Tika has no per-caller authorisation, the set of pods that can reach the port is the set of pods that can use it. A NetworkPolicy that admits only the intake service is therefore required, not optional:

Source: Apache Tika 4.1.x, Tika gRPC (Kubernetes and service meshes) and Kubernetes, Network Policies. Not applied to a cluster for this page. A policy only takes effect with a CNI plugin that enforces it; see Kubernetes: Network Policies. An empty egress list also blocks DNS, which is what you want for a Tika that only receives bytes.

By default Tika reports exceptions in full: stack traces, and messages that can contain the spooled file’s path, the original file name, host names and fragments of the document. They appear in the tk:exception:* metadata of successful parses, in tika-server error bodies (422, 500), in the *.metadata.json entries of an /unpack zip and in /pipes and /async result messages. The exception-reporting block of the parse-context section controls all of them at once:

The same broken manuscript.docx (a zip whose [Content_Types].xml does not cover _rels/.rels), sent to /rmeta/text on the default server and on the hardened one, gives this tk:exception:container-exception (frames omitted):

The setting is operator-only. With allowPerRequestConfig switched on, a request that tries to turn it back to FULL is refused:

Set MESSAGE_REDACTED (or REDACTED) whenever the callers are less trusted than the operator, and prefer it to a metadata filter that drops tk:exception:*: a filter supplied in a per-request configuration replaces the operator’s filter instead of adding to it. A third-party parser still calling the deprecated two-argument EmbeddedDocumentUtil.recordException reports FULL whatever the policy says.

Source: Apache Tika 4.1.x, Setting Limits (Exception reporting) and Apache Tika 4.1.x, Tika Server (Error Responses).

The history explains the caution. CVE-2015-3271 (Tika 1.9) let a remote caller read arbitrary files through the fileUrl header, and CVE-2018-1335 (1.7 to 1.17) let crafted headers inject commands into the command line of the server; both only affected servers open to untrusted clients, which is exactly the deployment this page forbids. In 2026, CVE-2026-66756 showed that /unpack on 4.0.0-alpha-1 could be configured past the secure defaults; it was fixed in 4.0.0-beta-1, before the first stable 4.x release.

Source: Apache Tika 4.1.x, Migrating tika-server to 4.x and the CVE records linked in the CVE history.

The most important Tika vulnerability of recent years is an XXE in the handling of XFA (XML Forms Architecture) forms inside PDF files:

At the baseline date Tika’s own security page lists CVE-2025-54988 but not CVE-2025-66516.

What to do:

Source: the CVE records above and Apache Tika, Security. The XFA parsing itself, with the ifXFAExtractOnlyXFA option and a real XFA sample, is in PDF Parsing.