Apache Camel Tika CVE-2026-85249

Requires a Camel route that uses the camel-tika producer (tika:parse) to parse attacker-supplied documents AND a downstream component in that same route that acts on a Camel-namespace header such as CamelFileName (e.g. a file producer choosing a write path). The attacker must be able to deliver a crafted document into the route and chooses the metadata keys the file carries. Limiting factors: impact is bounded to routes whose logic trusts metadata-derived internal headers - routes that never read such headers are unaffected; the mitigation removeHeaders("Camel*") after the Tika producer neutralizes it without upgrading. No authentication to Camel itself is implied by the CVSS (PR:N), but exploitation is contingent on this non-universal route configuration.

This is a genuine but moderate-severity integration-logic flaw, not a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N, 6.5 MEDIUM) describes an unauthenticated network-reachable issue with low confidentiality and low integrity impact and no availability impact - consistent with header injection rather than direct code execution. No EPSS score, no CISA KEV listing, and no public exploit were provided in the input, so the exploitation-probability signals are all absent/negative, pointing away from mass exploitation. The one practical caveat is that CVSS rates this AC:L, but the real attack only works if the victim's Camel route both uses the camel-tika producer AND has a downstream component that trusts a Camel-namespace header (e.g. CamelFileName) - a deployment-specific precondition that in practice makes exploitation conditional rather than universal. Treat this as a dependency-patching priority for teams actually running camel-tika routes, not a drop-everything internet-wide threat. No conflicting severity signals were present; the main uncertainty is deployment-specific route configuration, which the raw CVSS cannot capture.

An attacker submits a crafted document (e.g. an HTML file with a <meta name="CamelFileName" content="../../pwned"/> tag) into a Camel route that parses it with the tika:parse producer. Because every parsed metadata key was mapped onto the Exchange as a header without filtering, the attacker-chosen metadata becomes a trusted Camel-internal header, letting a downstream file component write content to an attacker-chosen path. No public exploit was identified at time of analysis, though the vendor's fix PR includes a unit test demonstrating the header-injection behavior.