Apache Camel Thrift CVE-2026-85245

Exploitation requires a deployment that uses the camel-thrift Thrift data format's unmarshal operation on a route shared across more than one tenant or user, where the same data format instance (and its shared defaultInstance of the target type) processes messages from different parties. The leak surfaces specifically through optional/absent fields: a later message that omits a field inherits the previous message's value, and concurrent exchanges can observe each other's partially written state. Limiting factors that reduce real-world risk: single-tenant deployments, routes not using the Thrift data format, or deployments already on fixed releases (4.18.5, 4.22.1, 4.23.0) are unaffected; high attack complexity means the attacker must influence message sequencing/timing rather than deterministically forcing the disclosure. No authentication is required of the sender (PR:N).

This is a genuine but moderate-priority data-confidentiality flaw whose real-world risk is tightly bounded by its exploitation preconditions. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, base 5.9 Medium) reflects a network-reachable, unauthenticated issue with high attack complexity and confidentiality-only impact - no integrity or availability effect. The AC:H rating is the dominant discriminator: exploitation depends on a specific deployment shape (one Camel route with the Thrift data format serving multiple tenants/users) plus the timing/sequencing of messages through the shared defaultInstance, which an attacker cannot reliably force. No EPSS score was supplied, so exploitation probability cannot be quantified from the input. KEV status is not present, so this is not confirmed actively exploited; there is no public exploit code either - the GitHub artifacts are the vendor patch and an isolation unit test, not a weaponized POC. The signals are internally consistent rather than conflicting: a Medium CVSS driven by high complexity, no KEV, and no POC all point to a real correctness/leakage bug that matters for multi-tenant operators but is not a drop-everything mass-exploitation threat. The practical consequence - one tenant reading another tenant's message fields - is serious in shared SaaS/multi-tenant integration contexts but irrelevant in single-tenant deployments or routes not using the Thrift data format.

In a multi-tenant Apache Camel integration that unmarshals inbound Thrift messages on a shared route, tenant B sends a Thrift payload that omits one or more optional fields; because the data format deserializes into a process-wide shared defaultInstance, those omitted fields still carry the values left behind by tenant A's prior message, and tenant B receives A's data in the returned exchange body. Concurrent exchanges can similarly observe each other's partially written state. No public exploit code exists; triggering the leak reliably requires the attacker to influence message timing/sequencing on the shared route, consistent with the high attack complexity.