Apache Camel 4.22.2: OAuth Token Cache, Docling and Saxon XXE CVEs

Apache Camel disclosed eight vulnerabilities on 22 and 23 October 2026, including a High severity XML external entity flaw in camel-saxon and a token cache bug in camel-oauth, the library behind Camel's AI connectors. Every Camel 4.x line still supported is fixed in 4.22.2, 4.23.0 or 4.18.5. Upgrade the whole Camel BOM. No exploitation is reported.

This is a vulnerability disclosure, not a breach. None of the eight issues is in the CISA Known Exploited Vulnerabilities (KEV) catalog as of its 23 October release, the Apache advisories describe no attacks, and we found no public proof of concept. Seven of the eight are rated Medium. Several only matter when an outside caller can set Camel message headers, or when a deployment has a particular configuration such as two OAuth profiles that share a client ID.

The reason to act this week anyway is the shape of the disclosure. The fixes shipped before the advisories (4.18.5 on 11 October, 4.23.0 on 15 October, 4.22.2 on 22 October), and as of the afternoon of 24 October UTC the CVE records for the 23 October batch were not yet visible through the public CVE.org API or the US National Vulnerability Database (NVD). A scanner that relies only on those feeds will not flag them yet. Teams pinning anything from 4.19.0 to 4.22.1 are the exposed band.

What happened

The Apache Camel Project Management Committee published the batch in two places. The Camel security page lists each advisory with its affected and fixed versions, and Andrea Cosentino of the Apache Software Foundation posted seven of them to the oss-security mailing list between 07:27 and 07:42 UTC on Friday 23 October. The eighth, CVE-2026-71569 in camel-a2a, appears on the Camel security page dated 23 October but not in that oss-security run.

Two more Camel advisories from the same week share the same fixed releases and belong in the same upgrade: CVE-2026-88900, a High severity unsafe deserialization bug in camel-jgroups whose CVE record went live on 19 October, and CVE-2026-91858, an XXE in camel-fop. Both were fixed earlier, in 4.22.1 and 4.18.5. They are covered below because anyone moving to 4.22.2 picks them up at the same time.

Several of the new bugs sit in the parts of Camel that connect integration routes to AI services. The camel-oauth token cache issue affects, in Apache's words, "camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a" plus camel-spring-ai-chat and the IBM watsonx components. Two more are in camel-docling, the component that runs the docling document conversion tool, and one is in camel-a2a, the agent to agent protocol component. If your team has been wiring language models into existing Camel routes over the last year, this batch lands squarely on that work.

The batch at a glance

CVSS scores come from the oss-security posts for the 23 October batch and from the published CVE record for CVE-2026-88900. The Camel security pages themselves give a severity word but no score for most entries.

Timeline

Who is affected

You are affected if your application, or a product you run, bundles one of the named Camel components at a version in the affected range, and uses it in the way each advisory describes. Camel is a library, so it rarely shows up as a service with its own name. It sits inside Spring Boot applications, Quarkus services, Karaf containers, integration platforms and vendor products.

Apache states that the 4.14.x and earlier lines, 4.15.x to 4.17.x and 4.19.x to 4.21.x are end of life and will not receive fixes. If you are on one of those, the only supported path is a move to 4.18.5, 4.22.2 or 4.23.0. Camel 3.x does not appear in the affected ranges for these ten advisories. Other 2026 Camel advisories do list 3.x ranges, so check the security page for your exact line.

Two scope notes from the advisories are easy to miss. The 4.18.x line does not include the camel-oauth client credentials resolver at all, so CVE-2026-94386 does not affect it. And CVE-2026-71569 only affects camel-a2a from 4.21.0 onward.

Where Camel hides

• Spring Boot fat jars. Camel components live under BOOT-INF/lib/ as camel-<name>-<version>.jar. The starter version and the core version match when you use camel-spring-boot-bom, but a hand pinned component can drift.
• Quarkus applications. Camel Quarkus has its own version numbers (3.33.x and 3.40.x as of September). Check the resolved org.apache.camel:camel-* versions rather than the Quarkus extension version.
• Integration products. Several commercial integration and data products ship their own Camel build. Their fixed versions come from the vendor, not from Apache, and may arrive later.
• Container images. Base images built for "integration runtime" use often bundle Camel and a set of components whether or not your routes use them. A bundled but unused camel-saxon is still worth upgrading, but it changes your priority.

How the issues work

This section explains each bug in plain language. It does not include attack inputs. The point is to help you decide whether your routes match the conditions Apache describes.

CVE-2026-90885: XQuery over a ready made Source skipped parser hardening

Camel already hardens XML parsing when it converts a message body from a String, a byte array or an InputStream. The gap was a body that was already typed as javax.xml.transform.Source before it reached the XQuery step, for example after a convertBodyTo(Source.class) call or when an earlier processor produced one. In that case XQueryBuilder handed the body to Saxon with Saxon's default configuration, which accepted a DOCTYPE declaration and resolved external entities.

According to the advisory, an external sender could use that to read files the Camel process can access and to make the process send requests to hosts named in the document. No special configuration is needed. That is why it is the one High in the 23 October set, scored 7.5 with network access, low complexity, no privileges and high confidentiality impact.

The fix enables disallow-doctype-decl and turns off external-general-entities, external-parameter-entities and load-external-dtd on the default Saxon configuration. A Source body with a DOCTYPE now fails with a parse error. That is a visible behaviour change, and Apache notes it in the 4.23 upgrade guide. A configuration you supply yourself through the endpoint or language configuration option, or through XQueryBuilder.setConfiguration, is used unchanged, so if you set one, check that it is hardened too.

Apache's page also separates this from CVE-2026-85250, an earlier XXE in camel-xpath with documentType=InputSource. That one was fixed in 4.22.1. Version 4.22.1 is still affected by CVE-2026-90885, which needs 4.22.2.

CVE-2026-94386: one OAuth token, several scopes

camel-oauth gives Camel components named OAuth profiles. A route calling a language model service, a document service and an internal API can each have its own profile with its own scope. The client credentials resolver caches tokens in a static cache that lives for the whole JVM, and before the fix the cache key held only the token endpoint and the client ID.

So if two profiles used the same identity provider and the same client ID, but asked for different scopes or used different client secrets, the second profile could receive the first profile's cached token without ever making its own token request. Caching is on by default. The practical effect, as Apache describes it, is that an outbound call can carry a token with more authority than intended, or one meant for a different service. The advisory is clear that profile settings come from trusted deployment configuration, so outside input does not reach the cache. The risk is a receiving service that is hostile or compromised replaying a token that is broader than it should have seen.

The fix adds a SHA-256 fingerprint of the client secret and the requested scope to the key. Blank, empty and missing scopes count as the same value. Profiles with identical settings still share tokens, and Apache warns that upgrading may cause extra token requests where profiles were sharing by accident.

Apache calls this the same class of defect as CVE-2026-85317 in camel-http's own token cache, which is separate code. It is also distinct from CVE-2026-80312 and CVE-2026-84178, which concern camel-oauth's inbound processors. Version 4.22.1 fixes those two but is still affected by this one.

CVE-2026-95628: an incomplete fix for docling custom arguments

camel-docling runs the external docling command line tool and builds its arguments partly from message headers, including a list of custom arguments in the CamelDoclingCustomArguments header. In July, CVE-2026-40047 replaced a flag denylist with an allowlist and added path validation. That validation rejected relative traversal but let an absolute path through unchanged. Apache names --artifacts-path as an affected flag.

Someone who can influence the custom arguments header could point docling at any directory the Camel process can reach. The CVSS vector requires low privileges (PR:L), and the header sits in the Camel namespace, which default header filtering on consumers such as JMS and Kafka normally strips. So the realistic exposure is a route that copies outside values into that header itself, or a consumer whose header filter has been loosened.

CVE-2026-95629: docling output written wherever the header says

The second docling bug is in the CamelDoclingOutputFilePath header, which the producer's CLI mode passed straight to docling's --output flag. This header was not covered by the CVE-2026-40047 validation. A party able to set it could have conversion output written to any directory the Camel process can write to. The docling-serve mode is not affected.

The fix adds an outputBaseDirectory endpoint option. It is unset by default. When you set it, output paths that resolve outside it are rejected with an IOException. Without it, the header is normalised but can still point anywhere. In other words, the upgrade alone narrows the problem; setting outputBaseDirectory closes it.

Both docling issues were found by Zhixi "Jace" Sun, an independent researcher. They sit next to CVE-2026-78163, a docling bug fixed in 4.22.1 in which a String body that looked like a URL or a file path was fetched or read. Version 4.22.1 added allowUrlSource and allowFilePathSource options (both off by default) and an inputBaseDirectory option for that one.

CVE-2026-95663: Keycloak introspection cache outlived the token

With useTokenIntrospection=true, camel-keycloak asks the identity provider whether a token is still active and caches the answer. Both cache implementations, ConcurrentMapTokenCache and CaffeineTokenCache, expired entries a fixed time after insertion, and the processor checked only the "active" flag, never the token's own expiry claim. A token that was valid when cached could be accepted for up to the cache lifetime after it expired, with its original roles. The advisory describes the window as bounded by the introspectionCacheTtl setting, and it only opens for tokens the same process introspected while they were still active.

Apache is specific about the limits: no forgery, no privilege escalation, introspection is off by default, and the local JWT verification path is not affected.

CVE-2026-95664: an S3 object name treated as an expression

Since 4.8.0 the aws2-s3 producer evaluated a key supplied in the CamelAwsS3Key header using Camel's Simple expression language. The aws2-s3 consumer sets that same header to the name of each object it reads. Put the two together in a route that copies objects from one bucket to another, and the producer could evaluate an object name chosen by anyone allowed to upload to the source bucket.

Apache notes that Simple can read JVM system properties, environment variables and configuration properties, and with camel-bean on the classpath it can call bean methods. That is why a Medium score (5.4, PR:L) still deserves attention in routes that move files from partner or customer buckets. Setting keyName on the producer did not help, because the header takes precedence. The advisory's own words: "Configuring keyName alone is not a workaround."

After the fix, only the keyName and bucketName endpoint options are evaluated with Simple. Header values from CamelAwsS3Key and CamelAwsS3OverrideBucketName are used literally. If a route relied on header evaluation, it now has to evaluate explicitly with setHeader and simple().

CVE-2026-101259: CoAP error details sent to clients

When the CoAP consumer failed to build its response after a route finished, for example converting the body to bytes or converting the CamelCoapMaxAge or CamelCoapETag headers, it put the exception message into a 5.00 response. Those messages could include class and package names, values and backend connection details. Unlike Camel's HTTP consumers, it had no option to suppress them. Separately, a failed route was answered with 2.05 Content and whatever body the message held.

The fix adds muteException, on by default, to coap, coaps, coap+tcp and coaps+tcp endpoints, and failed exchanges now get a 5.00 with an empty payload.

CVE-2026-71569: a webhook guard that judged by spelling

camel-a2a lets an A2A caller register a push notification webhook. The validator checked an IPv6 literal against prefixes covering the unique local range fc00::/7, but checked a host name by resolving it and using JDK predicates that do not cover that range. A name that resolved into fc00::/7 could pass a check that rejected the same address typed as a literal. The dispatcher then sent its request there, including any Authorization header the caller supplied. The caller never sees the response, so Apache calls it blind server side request forgery, and it also depends on an HTTPS service listening at that address with a successful TLS handshake.

A side effect of the same logic refused any host name beginning with "fc" or "fd", which Apache notes would block fcm.googleapis.com. The fix uses one classifier for literals and resolved names, and the 4.23 upgrade guide lists the additional ranges now rejected, including 100.64.0.0/10, NAT64 64:ff9b::/96 and 6to4 2002::/16.

CVE-2026-88900 and CVE-2026-91858: the two from earlier in the week

CVE-2026-88900 is the most severe Camel issue of October. The camel-jgroups consumer deserialized incoming cluster messages without a class filter, and its default JGroups UDP stack has no authentication or encryption. A host that can reach the multicast group or bind port could join and send a crafted serialized object. The CVE record scores it 8.8 with an adjacent network attack vector, and Apache explains it chose High over Critical because exploitation needs network adjacency and a usable gadget chain on the classpath. camel-jgroups-raft is not affected.

CVE-2026-91858 is an XXE in camel-fop. The producer enabled only secure processing on its TransformerFactory. With the JDK's built in transformer that was enough, but when a third party factory such as Saxon-HE was on the classpath, external DTDs and entities in incoming XSL-FO could resolve. Apache's page credits an automated AI security scanning tool with the finding.

Technical details

All values below were read from the Apache Camel security pages, the oss-security posts, the Camel release notes, the CVE.org API and Maven Central. Where sources differ, we say so.

CVSS vectors per CVE

Weakness classes

Fix commits and pull requests

Every Camel advisory page also links a PGP signed copy of the advisory text (for example CVE-2026-94386.txt.asc), which you can verify against the Apache Camel KEYS file.

Credits

Release facts

Maven Central lists camel-core 4.18.5, 4.22.2 and 4.23.0, and org.apache.camel.springboot:camel-spring-boot-bom 4.18.5, 4.22.2 and 4.23.0, so Spring Boot users can move today.

The 4.22.2 release notes do not list CVE numbers, but they include the matching JIRA items: CAMEL-24691 (camel-saxon secure parsing defaults), CAMEL-24872 (camel-oauth token caching), CAMEL-24893 and CAMEL-24894 (camel-docling path constraints), CAMEL-24901 (camel-aws2-s3 Simple restriction), CAMEL-24902 (camel-keycloak token expiry), CAMEL-25087 (camel-coap muteException) and CAMEL-24371 (camel-a2a webhook address classification). The same release carries other hardening without CVEs so far, including TLS hostname verification for camel-mllp, camel-mina and camel-smpp (CAMEL-25604, CAMEL-25605, CAMEL-25622), symbolic link resolution for jailStartingDirectory in camel-file (CAMEL-25412) and zip and tar decompression limits in camel-util (CAMEL-25023).

Configuration options introduced or changed by the fixes

Indicators of compromise

None. Apache published no indicators, no exploitation is reported, and none of the ten CVEs is in KEV. CISA's enrichment of the CVE-2026-88900 record says "Exploitation: none" and "Automatable: no". The other records were not yet retrievable from CVE.org when we checked, so they carry no CISA enrichment yet.

What to do now

1. Find every Camel you run

Start from build files, then confirm against what is actually deployed.

# Maven: show every resolved Camel artifact and version
mvn -q dependency:tree -Dincludes=org.apache.camel

# Gradle: same for the runtime classpath
./gradlew dependencies --configuration runtimeClasspath | grep 'org.apache.camel'

# Spring Boot fat jar already built
unzip -l target/app.jar | grep -E 'BOOT-INF/lib/camel-(core|saxon|oauth|docling|keycloak|aws2-s3|coap|a2a|jgroups|fop)-'

# Running container
docker run --rm --entrypoint sh your-image:tag -c "find / -name 'camel-*.jar' 2>/dev/null" | sort

If you keep SBOMs, search them for pkg:maven/org.apache.camel/ and the component names above. If you use Safeguard, safeguard scan --dir . on a repository or safeguard scan --image your-image:tag on a built image writes JSON results under ./output, and the platform shows which projects carry a given component and version.

2. Decide which issues apply to your routes

Version alone tells you whether you are inside an affected range. Your route definitions tell you whether you meet the conditions. A quick search across route code and configuration narrows it fast.

# XQuery on Source bodies (CVE-2026-90885)
grep -rnE 'xquery|XQueryBuilder|convertBodyTo\(\s*(javax\.xml\.transform\.)?Source' src/

# OAuth profiles and token caching (CVE-2026-94386)
grep -rnE 'camel\.oauth\.[A-Za-z0-9_-]+\.(client-id|scope|cache-tokens)' src/ config/

# Docling endpoints and headers (CVE-2026-95628, CVE-2026-95629)
grep -rnE 'docling:|CamelDocling(CustomArguments|OutputFilePath)' src/

# Keycloak introspection (CVE-2026-95663)
grep -rnE 'useTokenIntrospection|introspectionCache' src/ config/

# S3 bucket to bucket copies (CVE-2026-95664)
grep -rnE 'aws2-s3:' src/

# CoAP consumers (CVE-2026-101259) and A2A push notifications (CVE-2026-71569)
grep -rnE 'coap(s)?(\+tcp)?:|a2a' src/

# JGroups consumers (CVE-2026-88900)
grep -rnE 'jgroups:' src/

For CVE-2026-94386 specifically, list every profile with its client-id and scope. Any client ID that appears in more than one profile with different scopes or secrets is the vulnerable pattern.

3. Upgrade through the BOM

Upgrade the BOM rather than individual components, so that every Camel artifact moves together.

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.apache.camel</groupId>
      <artifactId>camel-bom</artifactId>
      <version>4.22.2</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

For Spring Boot, import org.apache.camel.springboot:camel-spring-boot-bom at 4.22.2 (or 4.18.5 on the 4.18 line), then remove any explicit <version> on individual camel-* dependencies. For Gradle:

dependencies {
    implementation platform('org.apache.camel:camel-bom:4.22.2')
    implementation 'org.apache.camel:camel-saxon'
}

Which target to choose:

4. Read the behaviour changes before you deploy

Several fixes change visible behaviour, and a quiet upgrade can break a route that relied on the old behaviour.

• camel-saxon: a Source body with a DOCTYPE now fails to parse. If a partner legitimately sends DOCTYPE declarations, you will see errors where there were none.
• camel-aws2-s3: CamelAwsS3Key values are now literal. A route that put an expression in that header on purpose must evaluate it with simple() in setHeader, or move it into keyName.
• camel-oauth: expect more token requests where profiles were sharing tokens. Check rate limits at your identity provider.
• camel-coap: clients that parsed error text from 5.00 responses will now get an empty payload.
• camel-jgroups on 4.23.0: the consumer will not start without jdk.serialFilter, a secured channel, or jgroups.deserialization.filter.

5. Apply the extra settings the upgrade does not turn on for you

# camel-docling: confine output (CVE-2026-95629), set per endpoint
# docling:convert?outputBaseDirectory=/srv/docling/out

# camel-keycloak: if you rely on introspection and want no expiry window at all
# (each request then calls the introspection endpoint)
# introspectionCacheEnabled=false on the KeycloakSecurityPolicy

For camel-docling, set outputBaseDirectory on every endpoint whose output path header could be influenced from outside. Also check whether allowUrlSource or allowFilePathSource were turned on after the 4.22.1 change, and if so, whether inputBaseDirectory is set.

6. Interim mitigations if you cannot upgrade today

These come straight from the advisories.

The header workarounds look like this in the Java DSL. They are defensive: they remove values before the vulnerable component reads them.

// Bucket to bucket copy: let the endpoint's keyName decide the target key
from("aws2-s3://incoming-bucket")
    .removeHeader("CamelAwsS3Key")
    .to("aws2-s3://archive-bucket?keyName=archive/${date:now:yyyyMMdd}/${exchangeId}");

// Anything arriving from HTTP, Kafka or JMS that feeds docling
from("platform-http:/convert")
    .removeHeaders("CamelDocling*")
    .to("docling:convert?outputBaseDirectory=/srv/docling/out");

Review your HeaderFilterStrategy on every consumer that accepts outside traffic. The docling advisory notes that default header filtering on consumers such as JMS and Kafka normally strips the Camel namespace; the danger is a route that copies outside values into those headers itself, a consumer configured to pass headers through, or a custom strategy.

7. Verify

# Confirm resolved versions after the upgrade
mvn -q dependency:tree -Dincludes=org.apache.camel | grep -vE ':(4\.18\.5|4\.22\.2|4\.23\.0)'

# Confirm what the built artifact actually contains
unzip -l target/app.jar | grep -oE 'camel-[a-z0-9-]+-4\.[0-9]+\.[0-9]+\.jar' | sort -u

The first command should print nothing except the header lines. Then run your route tests, especially any that send XML with a DOCTYPE through XQuery, S3 copies with unusual object names, or CoAP error paths, and confirm the new behaviour is what you expect.

8. Review logs where it is cheap to do so

There are no published indicators, so treat this as hygiene rather than a hunt. Useful places to look:

• Identity provider logs for token requests by client ID. Profiles that share a client ID and never requested their own token are the pattern CVE-2026-94386 describes.
• Object storage access logs for keys containing expression syntax in buckets that feed an aws2-s3 route.
• Filesystem changes in directories outside your docling output directory.
• Outbound connections from Camel hosts to fc00::/7 addresses if you run camel-a2a.

What changed since first reports

• Publication dates differ by source. The Camel pages for CVE-2026-90885 and CVE-2026-94386 are dated 22 October, while the oss-security posts went out on 23 October. CVE-2026-91858 is dated 15 October on its page; the scout notes we started from had it as 19 October, which is the CVE record date for CVE-2026-88900.
• The 4.22.1 versus 4.22.2 split is now explicit. Apache's pages say 4.22.1 is still affected by CVE-2026-90885 and CVE-2026-94386, even though it fixed the related CVE-2026-85250 and CVE-2026-80312 and CVE-2026-84178.
• CVE records lag the advisories. As of about 16:26 UTC on 24 October, the CVE.org API returned "record does not exist" for the 23 October CVEs we tried, and NVD returned no result. CVE-2026-88900 and the July CVE-2026-40047 were retrievable. Expect the records to appear, and scanner coverage to follow.

Open questions

• Exact CVSS for CVE-2026-71569 and CVE-2026-91858. The Camel pages give Medium without a score.
• Camel Quarkus and vendor builds. No October Camel Quarkus release is listed on the Camel releases page as of 24 October. We could not confirm which Camel core version the latest Camel Quarkus releases carry, so check the resolved org.apache.camel versions in your build. Commercial products with their own Camel build will publish their own fixed versions.
• Whether 4.23.0 is an LTS line. Its release note says "New LTS release" while the releases table shows no LTS marker. 4.22.x is marked LTS throughout.
• Further advisories. The 4.22.2 notes list several security fixes that have no CVE so far, and the 4.22 upgrade guide already has a 4.22.3 section mentioning camel-a2a token introspection changes. More advisories may follow.

What would have helped

Practices any team can use

• Follow upstream releases, not only CVE feeds. Every fix in this batch shipped between 11 and 22 October. Teams that track Camel LTS releases and move within a week were already covered when the advisories landed, and many scanners still cannot see the 23 October CVEs.
• Upgrade through a BOM. A single camel-bom or camel-spring-boot-bom version keeps every component in step. Hand pinned component versions are how a fixed core and a vulnerable camel-saxon end up in the same jar.
• Stay on a supported line. Most of the affected ranges end in "end of life, no fix". Moving from a short lived release such as 4.20 or 4.21 to an LTS line before you need a security fix makes the next one a patch bump instead of a migration.
• Filter headers at every trust boundary. Two of the eight bugs are reachable only when outside callers can set Camel* headers. Keep default header filter strategies on consumers that accept outside traffic, and strip component headers explicitly before sensitive producers.
• One OAuth client per scope. Giving each scope its own client registration at the identity provider removes the CVE-2026-94386 pattern regardless of library behaviour, and makes token audit logs much easier to read.
• Harden XML parsing in your own configuration too. If you pass a custom Saxon or JAXP configuration anywhere, the library's new safe defaults do not apply to it.
• Restrict egress from integration hosts. SSRF bugs like CVE-2026-71569 and the docling URL issue matter far less when the Camel process cannot reach internal ranges it has no reason to call.
• Keep an SBOM per build. When ten advisories land across ten components, a searchable SBOM turns "are we affected?" into a query rather than a week of asking teams. Our guide to SBOM driven incident response walks through the process, and the dependency incident playbook covers the response steps.

Where Safeguard fits

Safeguard helps with finding Camel and doing the upgrade, not with Camel's code or your route design.

• Finding affected builds. safeguard scan --dir ., safeguard scan --image <name> and safeguard scan --sbom <file> write JSON results under ./output, and the platform shows which projects contain a given component and version, matched against vulnerability databases. For this batch, matching depends on the CVE records being available to those databases; until then, searching for component versions below 4.18.5 or 4.22.2 is the reliable check.
• Reachability analysis helps rank whether the vulnerable code paths in a component are ones your application calls, which is useful here because most of the ten need a specific component and usage.
• Policies and gates can stop a build with a Camel component below the fixed versions from being promoted, so a stale pin does not return next sprint.
• Doing the edit. The Safeguard CLI's assistant can change the BOM version, remove hand pinned component versions and run your tests, asking before each command under the default permission mode; safeguard exec runs the same work in CI. Autonomous remediation can open fix pull requests and ships off by default. Read more about the Safeguard CLI as a security aware coding assistant.

Where Safeguard does not help: it will not tell you whether an outside caller can set a CamelDocling header on your route, whether two OAuth profiles share a client ID in your configuration, or whether your network lets a Camel host reach fc00::/7. Those are route and configuration reviews. It also cannot patch a commercial product's embedded Camel; that fix comes from the vendor. For the wider set of incidents this month, see October 2026 security incidents and what would have helped.

Common mistakes and troubleshooting

• Upgrading the Spring Boot starter but not the BOM. If a camel-saxon or camel-aws2-s3 dependency has its own <version>, it stays behind. Check the resolved tree, not the POM.
• Stopping at 4.22.1. It fixes CVE-2026-88900, CVE-2026-91858 and CVE-2026-78163, but not the 23 October batch. You need 4.22.2.
• Assuming keyName protects the S3 route. The header takes precedence on affected versions. Remove the header.
• Assuming the docling upgrade alone confines output. It normalises the path; outputBaseDirectory is what confines it.
• Lowering introspectionCacheTtl and calling it fixed. Apache says that narrows the window but does not close it.
• Treating "not in NVD" as "not affected". The records were not yet published there when we checked.
• XQuery routes failing after the upgrade. That is the DOCTYPE rejection working. Decide whether the sender truly needs DOCTYPE; if so, parse with a hardened parser before the XQuery step rather than reverting the protection.
• JGroups consumers failing to start on 4.23.0. Configure jdk.serialFilter, a secured channel or jgroups.deserialization.filter. Avoid acceptAllObjects=true on any cluster an untrusted host can reach.
• Identity provider rate limits after the oauth fix. More token requests are expected where profiles used to share. Give each scope its own client or adjust limits.

FAQ

What is CVE-2026-90885 in Apache Camel?

It is an XML external entity flaw in camel-saxon's XQueryBuilder. When a message body was already a javax.xml.transform.Source, Saxon's defaults resolved external entities, which could let an outside sender read files the Camel process can access or trigger outbound requests. It is rated 7.5 High and fixed in 4.18.5, 4.22.2 and 4.23.0.

Which Camel version fixes the October 2026 vulnerabilities?

Use 4.22.2 on the 4.22 LTS line, 4.18.5 on the 4.18 LTS line, or 4.23.0. All ten advisories covered here are fixed in those releases. Version 4.22.1 is not enough for the 23 October batch.

Is anyone exploiting these Camel vulnerabilities?

Not that anyone has reported. None is in the CISA KEV catalog as of its 23 October release, Apache describes no attacks, CISA's enrichment of CVE-2026-88900 says exploitation "none", and we found no public proof of concept.

Does CVE-2026-94386 affect me if I use only one OAuth profile?

No. It needs at least two profiles that share a token endpoint and client ID but differ in scope or client secret. A single profile, or profiles with separate client IDs, are not affected. Upgrading is still the simplest fix.

Why do the AI components keep appearing in Camel advisories?

They are newer code that handles outside content and credentials: documents fetched or converted by docling, tokens for model providers, webhooks for agents. This batch includes camel-oauth (used by camel-openai, camel-langchain4j-agent, camel-huggingface and others), camel-docling and camel-a2a. That is a reason to give AI routes the same header filtering, egress control and per scope credentials as any other integration.

My scanner shows nothing for these CVEs. Am I safe?

Not necessarily. As of 24 October the CVE.org API and NVD did not yet return records for the 23 October CVEs, so scanners that depend on them may not match yet. Check your Camel component versions directly against 4.18.5, 4.22.2 and 4.23.0.

I am on Camel 4.20 or 4.21. Will there be a patch for my line?

No. Apache says 4.19.x to 4.21.x are end of life and will not receive fixes. Move to 4.22.2, which is an LTS release.

Do I need to rotate credentials after upgrading?

The advisories do not ask for it. If your deployment matched the CVE-2026-94386 pattern and a receiving service is outside your trust, rotating the affected client secret and reviewing that service's access is a reasonable precaution. For CVE-2026-95663, expired tokens were only accepted for the cache lifetime, so no rotation is implied.

Does upgrading Camel fix Camel K or Camel Quarkus?

Camel K and Camel Quarkus have their own releases and their own advisories on the Camel security page. Check the resolved org.apache.camel core and component versions in those builds, and follow their own release notes.

Is camel-jgroups-raft affected by CVE-2026-88900?

No. Apache's page says only the camel-jgroups consumer is affected.

Apache shipped every fix in this batch before the advisories went out. The gaps that remain are the time between 4.22.2 existing and 4.22.2 running in every service and image you own, and, for teams on a vendor's bundled Camel build, the time until that vendor ships. The first gap is one most teams can close themselves.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Apache Camel; each shows a real flow that maps onto this upgrade. The first is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For Camel you would ask it to move camel-bom or camel-spring-boot-bom to 4.22.2, remove hand pinned component versions, and approve each mvn build and test run.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. That is how you would scan local repositories and built images to list which ones still carry camel-saxon, camel-oauth or camel-docling below the fixed versions.

Click through it at your own pace, or open it full screen.

The third demo is a real desktop app session. The CLI session appears in the conversation list, you ask for work on your computer, pick the folder, and Approve or Deny each command and file edit; it ends with an upgrade done and tests passing. Here you would point it at your integration service, let it propose the BOM change plus the outputBaseDirectory setting on docling endpoints, and approve each edit and test run yourself.

Click through it at your own pace, or open it full screen.

Get the CLI at safeguard.sh/download, and read the CLI documentation for the scan and permission options.

Quick check

Sources

• Apache Camel security advisories index (camel.apache.org)
• oss-security: CVE-2026-90885, Camel-Saxon XXE in XQueryBuilder (openwall.com)
• oss-security: CVE-2026-94386, Camel-OAuth token cache (openwall.com)
• oss-security: CVE-2026-95628, Camel-Docling absolute paths in custom arguments (openwall.com)
• oss-security: CVE-2026-95629, Camel-Docling output path header (openwall.com)
• oss-security: CVE-2026-95663, Camel-Keycloak expired tokens via introspection cache (openwall.com)
• oss-security: CVE-2026-95664, Camel-AWS2-S3 key header evaluated as Simple (openwall.com)
• oss-security: CVE-2026-101259, Camel-CoAP exception disclosure (openwall.com)
• CVE-2026-90885 advisory (camel.apache.org)
• CVE-2026-94386 advisory (camel.apache.org)
• CVE-2026-71569 advisory, Camel-A2A webhook SSRF (camel.apache.org)
• CVE-2026-88900 advisory, Camel-JGroups deserialization (camel.apache.org)
• CVE-2026-91858 advisory, Camel-FOP XXE (camel.apache.org)
• CVE-2026-40047 advisory, original Camel-Docling fix (camel.apache.org)
• CVE-2026-78163 advisory, Camel-Docling body input source (camel.apache.org)
• Apache Camel releases list (camel.apache.org)
• Apache Camel 4.22.2 release notes (camel.apache.org)
• Camel 4.22 upgrade guide, 4.22.1 and 4.22.2 sections (camel.apache.org)
• Camel 4.23 upgrade guide (camel.apache.org)
• CVE-2026-88900 record via the CVE.org API (cveawg.mitre.org)
• CVE-2026-90885 lookup via the CVE.org API, no record as of 24 Oct (cveawg.mitre.org)
• CISA Known Exploited Vulnerabilities catalog feed (cisa.gov)
• NVD API query for CVE-2026-90885 (nvd.nist.gov)
• camel-core versions on Maven Central (repo1.maven.org)
• camel-spring-boot-bom versions on Maven Central (repo1.maven.org)
• camel-quarkus-bom versions on Maven Central (repo1.maven.org)

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.