Apache Camel's 39 CVEs of 19 October 2026: What They Are and Which Ones Apply to You

Apache published 39 CVEs for Apache Camel on 19 October 2026, one of them rated 10.0. The fixes aren't new: every one is fixed in Camel 4.18.5 (released 6 October) and 4.22.1 (released 13 September), and in 4.23.0. What's new is that scanners will now flag every Camel 4 build older than those, and the 4.14 line and earlier, which Apache says reached end of life before the fixes, won't get one.

This post is for teams running Camel integrations in production. It covers what the 39 CVEs are, grouped by the kind of bug, the handful that deserve attention first and the conditions each one needs, the 4.14 problem, and a script that reads your mvn dependency:list output and lists which of the 39 apply to the Camel components you actually ship.

The short answer

The 39 Apache Camel CVEs published on 19 October 2026 affect Camel up to 4.18.4 and 4.19.0 to 4.22.0. Most start at 4.0.0 or at the component's first release; the camel-spring-redis one goes back to 2.11.0. Upgrade 4.18.x to 4.18.5 and 4.22.x to 4.22.1, or move to 4.23.0. Each CVE is tied to a specific component, so your exposure depends on which camel- artifacts you use. The most serious are Java deserialization in camel-hazelcast (CVE-2026-78162, CVSS 10.0), camel-spring-redis and camel-jgroups, expression injection in camel-dynamic-router, and secret disclosure through URI override headers in the HTTP components. Apache says the 4.14.x line and earlier won't be fixed.*

The 39, by kind of bug

By CVSS base score, as published in the CVE records: one critical, 14 high and 24 medium. Grouped by what went wrong:

Several of these are the same mistake in several places. Four remote-file components trusted file names reported by the server. Four components returned exception details to callers. Two security checks compared paths or header names with a different case rule from the code that dispatched the request. Patterns like that are worth searching for in your own routes, not just in Camel.

The ones to look at first

CVE-2026-78162, camel-hazelcast (10.0). This is an incomplete fix for CVE-2026-43865, which added a Java deserialization filter to the Hazelcast instances Camel creates. Two paths missed it. ReplicatedHazelcastAggregationRepository overrides doStart() without calling super.doStart(), so it kept its own copy of the startup code without the filter. Client-mode endpoints built their own client configuration, also without the filter. Anyone able to publish into the attached Hazelcast cluster can get a chosen serialized object deserialized, which is code execution. Apache's advisory points out that Hazelcast clusters have neither authentication nor TLS enabled by default. We covered a separate pair of Hazelcast authorization bugs in Hazelcast CVE-2026-107726 and CVE-2026-107725.

CVE-2026-78165, camel-spring-redis (8.8). With no serializer configured, the component used Spring's JDK serializer for every read, with no deserialization filter. The consumer deserialized every message published to its subscribed channels before any route logic ran. This one reaches back to Camel 2.11.0.

CVE-2026-88900, camel-jgroups (8.8). The consumer took the message body from JGroups' getObject(), which deserializes the payload on receipt. No filter applied unless the deployment set a JVM-wide one. The vector is adjacent network, so the attacker needs to reach the cluster.

CVE-2026-83531, camel-dynamic-router (8.8). The control endpoint compiled subscription predicates using a language named in the incoming message, from its body or headers. Whoever can send to the control endpoint chooses both the expression and the language that evaluates it.

CVE-2026-78164, HTTP producers (8.2). The HTTP, Netty HTTP, Undertow and Vert.x HTTP producers let a message override the target URI with the CamelHttpUri and CamelRestHttpUri headers, and then resolved property placeholders in that string. Placeholder resolution reaches environment variables, system properties and any registered secrets function, so a message that controls those headers can pull secrets into an outbound request. It matters most where headers from inbound requests flow through to an HTTP producer.

Two medium-to-high ones are worth a quick check because they need no special setup: CVE-2026-80312 (8.2), where camel-oauth guards let the request continue when authentication failed, and CVE-2026-80343 (8.2), where camel-netty-http's security constraint matched the context path case-sensitively while routing didn't.

The 4.14 problem

Camel 4.14.9, released on 9 August 2026, is the latest 4.14 release. Apache's advisory for CVE-2026-78162 says the 4.14.x line and earlier "reached end of life before this issue was resolved and will not receive a fix". The CVE records list 4.14 as affected, so every scanner will flag it, and there's no 4.14 version to move to.

For teams on 4.14, that turns a patch into a minor-version upgrade to 4.18.5, or further. For teams that can't upgrade at once, Apache's advisory for CVE-2026-78162 suggests supplying an explicit Hazelcast configuration that carries a Java serialization filter.

Find out which ones apply to you

This script reads the output of mvn dependency:list, finds every org.apache.camel artifact, and matches it against the 39 CVEs using the affected artifacts and first-affected versions from the CVE records. Standard library only:

#!/usr/bin/env python3
"""Match Camel artifacts in `mvn dependency:list` output against the 39 Apache
Camel CVEs published on 19 October 2026 (fixed in 4.18.5, 4.22.1 and 4.23.0).

Usage: mvn -q dependency:list -DoutputFile=deps.txt && python3 camel_oct2026.py deps.txt"""
import re
import sys

# (CVE, CVSS base score, first affected version, affected artifacts), from the CVE records
CVES = [
    ("CVE-2026-78162", 10, "4.0.0", ["camel-hazelcast"]),
    ("CVE-2026-78165", 8.8, "2.11.0", ["camel-spring-redis"]),
    ("CVE-2026-83531", 8.8, "4.4.0", ["camel-dynamic-router"]),
    ("CVE-2026-88900", 8.8, "4.0.0", ["camel-jgroups"]),
    ("CVE-2026-78164", 8.2, "4.0.0", ["camel-http", "camel-http-common", "camel-netty-http", "camel-undertow", "camel-vertx-http"]),
    ("CVE-2026-80312", 8.2, "4.11.0", ["camel-oauth"]),
    ("CVE-2026-80343", 8.2, "4.0.0", ["camel-netty-http"]),
    ("CVE-2026-80344", 8.2, "4.0.0", ["camel-as2"]),
    ("CVE-2026-88901", 8.2, "4.7.0", ["camel-smooks"]),
    ("CVE-2026-85250", 7.5, "4.0.0", ["camel-xpath"]),
    ("CVE-2026-85251", 7.5, "4.0.0", ["camel-http"]),
    ("CVE-2026-79983", 7.4, "4.0.0", ["camel-ftp"]),
    ("CVE-2026-79984", 7.4, "4.18.0", ["camel-mina-sftp"]),
    ("CVE-2026-79985", 7.4, "4.2.0", ["camel-smb"]),
    ("CVE-2026-79986", 7.4, "4.0.0", ["camel-azure-files"]),
    ("CVE-2026-84176", 6.5, "4.0.0", ["camel-platform-http-vertx"]),
    ("CVE-2026-85249", 6.5, "4.0.0", ["camel-tika"]),
    ("CVE-2026-85254", 6.5, "4.0.0", ["camel-platform-http"]),
    ("CVE-2026-85296", 6.5, "4.0.0", ["camel-as2"]),
    ("CVE-2026-85314", 6.5, "4.0.0", ["camel-mail"]),
    ("CVE-2026-91858", 6.5, "4.0.0", ["camel-fop"]),
    ("CVE-2026-84178", 6.1, "4.11.0", ["camel-oauth"]),
    ("CVE-2026-78163", 5.9, "4.15.0", ["camel-docling"]),
    ("CVE-2026-84181", 5.9, "4.0.0", ["camel-shiro"]),
    ("CVE-2026-85243", 5.9, "4.0.0", ["camel-crypto-pgp"]),
    ("CVE-2026-85245", 5.9, "4.0.0", ["camel-thrift"]),
    ("CVE-2026-85247", 5.9, "4.0.0", ["camel-knative"]),
    ("CVE-2026-85248", 5.9, "4.12.0", ["camel-pqc"]),
    ("CVE-2026-85260", 5.5, "4.0.0", ["camel-mllp"]),
    ("CVE-2026-85300", 5.5, "4.12.0", ["camel-pqc"]),
    ("CVE-2026-84180", 5.3, "4.0.0", ["camel-knative"]),
    ("CVE-2026-85246", 5.3, "4.0.0", ["camel-mina"]),
    ("CVE-2026-85257", 5.3, "4.0.0", ["camel-cxf"]),
    ("CVE-2026-85315", 5.3, "4.0.0", ["camel-grpc"]),
    ("CVE-2026-85301", 4.8, "4.15.0", ["camel-keycloak"]),
    ("CVE-2026-85312", 4.8, "4.0.0", ["camel-core"]),
    ("CVE-2026-85316", 4.8, "4.0.0", ["camel-platform-http"]),
    ("CVE-2026-85317", 4.8, "4.0.0", ["camel-http"]),
    ("CVE-2026-85313", 4.3, "4.0.0", ["camel-jetty"]),
]
LINE = re.compile(r"org\.apache\.camel:([\w.-]+):(?:jar|bundle|pom):([\w.-]+)")


def vt(v):
    return tuple(int(x) for x in re.findall(r"\d+", v)[:3])


def affected(version, intro):
    v = vt(version)
    return vt(intro) <= v < (4, 18, 5) or (4, 19, 0) <= v < (4, 22, 1)


def main(path):
    found = {}
    for line in open(path, encoding="utf-8"):
        m = LINE.search(line)
        if m:
            found[m.group(1)] = m.group(2)
    if not found:
        print("no org.apache.camel artifacts found")
        return 0
    versions = sorted(set(found.values()), key=vt)
    print(f"Camel artifacts: {len(found)}, versions: {', '.join(versions)}")
    hits = 0
    for cve, score, intro, arts in CVES:
        for art in arts:
            if art in found and affected(found[art], intro):
                hits += 1
                print(f"  {cve}  {score:>4}  {art} {found[art]}")
    low = [v for v in versions if vt(v) < (4, 18, 0)]
    if low:
        print(f"note: {', '.join(low)} is on a line Apache says is end of life (4.14.x and earlier); "
              "move to 4.18.5, 4.22.1 or 4.23.0")
    elif hits:
        print("fix: 4.18.x to 4.18.5, 4.22.x to 4.22.1, anything else to 4.23.0")
    print(f"{hits} CVE matches")
    return 1 if hits else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1] if len(sys.argv) > 1 else "deps.txt"))

Run against three dependency lists: an integration service on 4.18.2, a legacy service on 4.14.9, and one already on 4.22.1:

$ python3 camel_oct2026.py deps-integration.txt
Camel artifacts: 5, versions: 4.18.2
  CVE-2026-78164   8.2  camel-http 4.18.2
  CVE-2026-85251   7.5  camel-http 4.18.2
  CVE-2026-79983   7.4  camel-ftp 4.18.2
  CVE-2026-84176   6.5  camel-platform-http-vertx 4.18.2
  CVE-2026-85312   4.8  camel-core 4.18.2
  CVE-2026-85317   4.8  camel-http 4.18.2
fix: 4.18.x to 4.18.5, 4.22.x to 4.22.1, anything else to 4.23.0
6 CVE matches
exit=1
$ python3 camel_oct2026.py deps-legacy.txt
Camel artifacts: 3, versions: 4.14.9
  CVE-2026-78162    10  camel-hazelcast 4.14.9
  CVE-2026-78165   8.8  camel-spring-redis 4.14.9
  CVE-2026-85312   4.8  camel-core 4.14.9
note: 4.14.9 is on a line Apache says is end of life (4.14.x and earlier); move to 4.18.5, 4.22.1 or 4.23.0
3 CVE matches
exit=1
$ python3 camel_oct2026.py deps-patched.txt
Camel artifacts: 3, versions: 4.22.1
0 CVE matches
exit=0

The match is by artifact, so it tells you which CVEs are in your build, not which ones your routes can reach. For that, check each one's conditions: whether you use the Hazelcast aggregation repository or client mode, whether inbound headers reach an HTTP producer, whether the dynamic-router control endpoint is reachable.

Knowing which Camel components each service actually ships is the inventory question underneath all of this. Here's Safeguard's interactive walkthrough of building a dependency inventory:

What to do

1. Run mvn dependency:list for every service that uses Camel, and check it with the script above or your scanner.
2. Upgrade within your line. 4.18.x to 4.18.5 and 4.22.x to 4.22.1. Anything else goes to 4.23.0.
3. Plan the 4.14 move now. If you're on 4.14 or older, there's no patch coming. Read Apache's advisory for each CVE on a component you use, and apply any workaround it gives while you upgrade.
4. Check the conditions for the top five. Hazelcast clusters without authentication, Redis channels others can publish to, JGroups clusters on shared networks, reachable dynamic-router control endpoints, and HTTP headers passed through from callers.
5. Look for the repeated patterns in your own routes. Paths built from remote listings, case-sensitive security checks, exception details returned to callers.

The fair view

Camel's handling of this is good practice. The fixes shipped in releases days or weeks before the CVEs were published, the advisories explain each mechanism in detail, and the reporters are credited: 27 of the 39 records credit "Claude Security" as finder, and others credit Leon Zlobecki (three), h1ei1 (two), cattier from TCBS, Li Zhiyao (BUPT) and the Dilrevx team from NSSL at SJTU, among others. Andrea Cosentino is credited with the fixes.

The cost lands on teams that weren't tracking Camel releases. Thirty-nine CVEs in one day will light up dashboards, most of them medium and tied to components a given service doesn't use. The fixed releases have been out for days or weeks, which makes this a quick fix on current lines. On 4.14 it's a real project, and the CVE records are what will start that conversation.

Check yourself