Skip to content
TrustList
Security advisories

Apache Camel 4.22.1 users need 4.22.2 for seven more flaws

Editorial

By TrustList Editorial

A week after 38 advisories, Camel published seven more on 22 October, led by a High-rated XXE in camel-saxon. On the 4.22 LTS line only 4.22.2 fixes them; 4.18.5 and 4.23.0 already do.

About Apache Camel 4.22.1 users need 4.22.2 for seven more flaws

Apache Camel 4.22.1 users need 4.22.2 for seven more flaws

22 October 2026: Apache Camel published seven further security advisories on 22 October, one rated High and six Medium, and on the 4.22 long-term-support line they are fixed only in 4.22.2, so teams that upgraded to 4.22.1 for the 38 advisories of 15 October are still exposed. Camel 4.18.5 and 4.23.0 already carry all seven fixes, and 4.22.2 has been on Maven Central since 17 October.

Not yet independently verified. Apache rates these issues only High or Medium and gives no CVSS scores, and no exploitation has been reported; we found no independent write-up of this second batch yet. We will update this when it can be confirmed, and remove this note.

Versions that fix the second batch

You run Upgrade to
4.22.0 or 4.22.1 (LTS) 4.22.2
4.18.x (LTS) 4.18.5, if not already there
4.23.0 nothing to do
4.14.x or earlier, 4.15 to 4.17, 4.19 to 4.21 a supported release; these lines get no fix

The project explains the gap in the advisory for CVE-2026-90885: the fix was backported to the 4.22 branch after 4.22.1 had been cut, so 4.22.1 is affected and 4.22.2 is the first fixed release of that line. The same applies to the other six. The end-of-life list is also wider than many readers will assume. Besides 4.14 and earlier, the 4.15 to 4.17 and 4.19 to 4.21 lines reached end of life before these fixes and will not receive them.

The High-rated XXE in camel-saxon

CVE-2026-90885 affects every release from 4.0.0. When an XQuery expression ran over a message body that was already a javax.xml.transform.Source, camel-saxon parsed it with Saxon's default parser settings, so an external entity declared in that body was resolved. A sender able to supply XML to such a route could read local files or make the server issue requests. Apache stresses that this is a separate bug from CVE-2026-85250 in camel-xpath, fixed in the first batch, and that 4.22.1 fixes that one but not this. For deployments that cannot upgrade at once, it advises against evaluating XQuery over a Source body carrying untrusted XML, or configuring Saxon to refuse a DOCTYPE and disable external entities and DTD loading, which is what the fixed releases now do by default.

Tokens, object names and error messages

The Medium items are narrower but touch common integrations:

  • CVE-2026-95663, camel-keycloak from 4.16.0: with token introspection enabled, cached introspection results were kept for their full time-to-live, 60 seconds by default, without regard to the token's own expiry, so an expired access token could still be admitted with its old roles.
  • CVE-2026-94386, from 4.19.0: the OAuth client credentials token cache used by camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat and the IBM watsonx components was keyed only on the token endpoint and client ID, so a profile could be handed a token minted for a different scope or secret.
  • CVE-2026-95664, camel-aws2-s3 from 4.8.0: a route copying objects between buckets evaluated object names containing ${ or $simple{ as Simple expressions, so anyone able to name an object in the source bucket could inject one.
  • CVE-2026-95628 and CVE-2026-95629, camel-docling from 4.15.0: an incomplete earlier fix still accepted absolute paths in custom CLI arguments, and an unvalidated header let conversion output be written to any directory.
  • CVE-2026-101259, camel-coap from 4.0.0: when the consumer failed to build its response, the exception message, which can include class names, file paths and backend host details, went back to the CoAP client.

The AI connector cache flaw is the one most likely to sit unnoticed, since a team running two OAuth profiles against the same identity provider client would see no error, only calls made with the wrong scope. Our integration software category lists 18 products.

Related on TrustList:

Sources

Categories & features

TrustList Weekly

The week in software and IT, in one email

The news that matters to buyers, new rankings and our own research. Every Thursday, free, and easy to leave.

We will email you to confirm. Unsubscribe with one click in any issue. Privacy policy