The Apache Software Foundation has released a cluster of security fixes for Apache Camel, the widely used open-source integration framework, addressing six distinct vulnerabilities across several of its components. The issues range from unsafe XML parsing that can expose local files, to a deserialization bug capable of remote code execution, to a credential-leaking flaw triggered by something as routine as following an HTTP redirect.

Because Camel is modular — organizations typically only pull in the specific components their integration pipelines need — exposure varies significantly from one deployment to the next. Apache’s advisories list patched versions for each affected component separately, and the project is explicit that teams should check their actual dependency tree rather than assume a blanket risk applies.

Two Separate XXE Flaws, Two Different Entry Points

The most notable issues are a pair of XML External Entity (XXE) vulnerabilities that, while related in impact, stem from entirely separate code paths:

• CVE-2026-90885 (Camel-Saxon): The component’s XQueryBuilder processes message bodies that are already wrapped as javax.xml.transform.Source objects using Saxon’s default parser settings — settings that allow an externally declared entity inside the XML body to be resolved rather than blocked.
• CVE-2026-85250 (Camel-XPath): A separate weakness appears when documentType=InputSource is used, causing the payload to be handed to an engine that builds its own parser using default JDK settings — settings that don’t carry the same entity-blocking protections applied elsewhere in Camel.

Apache is careful to note in its advisories that these are independent issues rather than two manifestations of the same root cause, meaning patching one does not automatically close the other.

A Third XXE Issue — and a Deserialization Bug With RCE Potential

A third high-severity flaw, CVE-2026-88901, hits Camel-Smooks: its default XML reader resolves external general and parameter entities and loads external document type definitions by default. In practice, that means an attacker who controls an incoming XML message could use it to read arbitrary local files or make the server reach out to internal network hosts it shouldn’t be able to touch — a classic XXE outcome, but through yet another component. A related, lower-severity XXE issue was also patched in Camel-FOP, affecting setups using certain third-party XML transformer implementations.

Separately, and arguably more serious on paper, CVE-2026-88900 addresses unsafe Java deserialization in Camel-JGroups — a flaw class that can escalate all the way to remote code execution when an attacker can influence the data being deserialized.

Rounding Out the Patch: Redis, HTTP Redirects, and Auth

The update also closes:

• CVE-2026-78165 (Camel-Spring-Redis): A high-severity issue where an attacker able to publish to a subscribed Redis channel could exploit the component’s default deserializer, which lacks an object input filter
• CVE-2026-85251 (Camel-HTTP): A credential-disclosure bug where, if followRedirects is enabled, the component keeps attaching the original Authorization header to whatever destination a redirect response points to — meaning a malicious or compromised remote server could redirect a request and harvest the credentials sent along with it
• Additional fixes addressing an OAuth authentication bypass and weaknesses in Keycloak token validation

None of these newly disclosed issues appear to be connected to previously reported Camel vulnerabilities, including past header-injection bugs and attacks chaining Camel with Tomcat — those were older, separate flaws and shouldn’t be read as evidence that the newly patched issues are already being exploited.

Patch Guidance

Fixed versions differ slightly by component. The Camel-Saxon fix lands in 4.18.5, 4.22.2, and 4.23.0, while the XPath and Smooks fixes are available starting at 4.18.5, 4.22.1, and 4.23.0. That one-point difference matters: organizations planning to upgrade primarily for the Saxon fix need to target 4.22.2, not 4.22.1, or they’ll remain exposed to that specific issue.

Security teams reviewing their Camel deployments should inventory which components are actually in use, check redirect-following behavior on any HTTP-based routes, and confirm which XML processing libraries are packaged into each integration pipeline before assuming a single version bump covers every flaw in this release.