CVE-2026-78162 · Apache Camel camel-hazelcast Missing Deserialization Filter on Two…

01 · The Real Story

The locksmith changed four of six locks but forgot the back two — and the building has no fence

CVE-2026-78162 is a fix bypass of CVE-2026-43865 in Apache Camel's camel-hazelcast component. The original flaw: Camel-managed Hazelcast instances were created with no JavaSerializationFilterConfig, permitting unrestricted Java deserialization from the Hazelcast cluster wire protocol. The fix applied filters to four of six configuration code paths — but missed ReplicatedHazelcastAggregationRepository.doStart() and HazelcastDefaultComponent.getOrCreateHzClientInstance(). Every organization that upgraded to 4.14.8, 4.18.3, or 4.21.0 believing they were patched remains exposed on those two paths. Affected versions: 4.0.0 – 4.18.4 and 4.19.0 – 4.22.0. Camel Quarkus users on camel-quarkus-hazelcast 3.29.0 (mapping to Camel 4.15.0) are also hit. Fixes land in 4.18.5, 4.22.1, and 4.23.0.

Apache categorized this as MEDIUM in their October 15 bulk advisory alongside 37 other CVEs. That label underweights two realities. First, Hazelcast clusters ship with no authentication and no TLS — the only gate is network reachability, and most enterprise internal networks hand that to any post-initial-access attacker for free. Second, Camel is integration middleware: a single Camel server typically holds JDBC connection strings, JMS broker credentials, REST API tokens, and cloud-service keys for every backend its routes touch. RCE here is not a dead-end host compromise — it is a credential-rich pivot point into databases, queues, and APIs across the environment. Calling an unauthenticated-RCE-once-adjacent bug in a credential-laden middleware hub *MEDIUM* misleads defenders about urgency.

"Incomplete Hazelcast deser fix gives any internal attacker trivial RCE on Camel integration hubs"

02 · The Attack Path

5 steps from start to impact.

STEP 01

Gain internal network position

The attacker needs to reach the Hazelcast cluster port (default TCP/5701). Hazelcast clusters are backend infrastructure and are effectively never internet-facing — Hazelcast's own hardening documentation explicitly warns against deploying members or clients on internet-facing networks. This step requires prior compromise of a host on the same network segment or VLAN, or a misconfigured cloud VPC that allows cross-service connectivity.

Conditions required:

Prior foothold on internal network
Port 5701 (or configured Hazelcast port range 5701–5801) reachable from attacker position

Where this breaks in practice:

Hazelcast clusters are not internet-exposed in any standard deployment topology
Network segmentation or microsegmentation may restrict lateral movement to backend tiers
Cloud VPC security groups and Kubernetes NetworkPolicies often restrict inter-service communication

Detection/coverage: Network IDS alerting on unexpected connections to port 5701 from non-member IPs. Shodan and FOFA show negligible internet-facing Hazelcast instances globally.

STEP 02

Join the Hazelcast cluster without credentials

Hazelcast's default configuration has no authentication and no TLS. Any client connecting to the cluster on port 5701 is silently accepted. The attacker uses the standard Hazelcast Java client library (or a raw socket implementation) pointed at the target IP and port. No brute-forcing, no credential theft — just connect. The oscerd PoC demonstrates this in ~20 lines of Java.

Conditions required:

Hazelcast cluster running default configuration (no auth, no TLS)
Attacker can run a Hazelcast client or equivalent

Where this breaks in practice:

Organizations that followed the Hazelcast Enterprise hardening guide and enabled mutual authentication + TLS block this step entirely
Some Hazelcast Enterprise Edition deployments enable security features — but OSS Hazelcast (dominant in Camel integrations) does not

Detection/coverage: Hazelcast audit logging (if enabled in Enterprise) shows new member/client joins. Default OSS deployments do not log connection events.

STEP 03

Inject malicious serialized Java object into cluster data structure

The attacker publishes a crafted serialized Java object (e.g., a Commons Collections or Spring gadget chain payload) into a Hazelcast data structure — a replicated map backing the ReplicatedHazelcastAggregationRepository, or any map consumed through a client-mode endpoint built by getOrCreateHzClientInstance(). Because these two code paths have no JavaSerializationFilterConfig, any class on the Camel application's classpath can be deserialized. Standard deserialization gadget chains work out of the box against typical Spring Boot or Quarkus fat JARs. The oscerd/CVE-2026-78162 PoC provides complete reproducers for both runtimes.

Conditions required:

Target Camel application uses one of the two affected config paths (ReplicatedHazelcastAggregationRepository or client-mode HazelcastDefaultComponent)
Deserialization gadget classes on the classpath (commons-collections, spring-beans, etc. — near-universal in Camel Spring Boot / Quarkus deployments)

Where this breaks in practice:

If the Camel application uses only the four *patched* Hazelcast config paths, this specific CVE does not fire
JVM-wide serialization filters (-Djdk.serialFilter) would block gadget classes if configured — but almost no one sets this manually

Detection/coverage: RASP agents (Contrast, Hdiv) or deserialization-aware EDR can detect gadget chain execution. Runtime SBOM tools (JFrog Xray) may flag the vulnerable JAR.

STEP 04

Achieve remote code execution as the Camel service account

The gadget chain fires inside Hazelcast's own serialization layer — before Camel processes the exchange. Arbitrary code runs with the full privileges of the Camel JVM process. On typical production deployments, this process holds active connections to databases, message brokers, REST APIs, file systems, and cloud services, all authenticated with stored credentials.

Conditions required:

Successful gadget chain deserialization
Camel process running with useful service-account permissions

Where this breaks in practice:

Container-based deployments may limit filesystem access and lateral network reach
Least-privilege service accounts reduce the value of the foothold — but integration middleware *by design* needs broad access

Detection/coverage: EDR detecting anomalous child process spawns from the Java process (e.g., /bin/sh from PID running camel). SIEM correlation of unexpected outbound connections from integration-tier hosts.

STEP 05

Harvest integration credentials and pivot to connected backends

Post-RCE, the attacker reads application.properties, application.yml, environment variables, and mounted Kubernetes secrets to extract JDBC strings, JMS credentials, API tokens, SMTP auth, and cloud IAM keys. The integration tier is a credential goldmine by architecture — it *must* hold credentials for every system it connects to. The attacker pivots laterally using these credentials to access databases, queues, and APIs directly.

Conditions required:

Credentials stored in accessible application configuration, environment variables, or mounted secrets
Connected backends accept the harvested credentials without source-IP binding or mTLS

Where this breaks in practice:

Vault-integrated deployments with short-lived dynamic credentials limit the window of credential reuse
mTLS between services prevents credential replay from a different source host

Detection/coverage: UEBA detecting credential use from unexpected source IPs. Database audit logs showing queries from the compromised host. Cloud IAM anomaly detection for API calls from new source addresses.

03 · Compensating Control

HIGH 7.8→LOW 3.1

SEVERITY REDUCED

Enable Hazelcast cluster authentication and TLS immediately — Configure hazelcast.security with member-to-member and client-to-member authentication, and enable TLS on all cluster communication. This breaks attack-path step 2 — an unauthenticated attacker can no longer join the cluster even with network reachability. Hazelcast Enterprise includes native security features; OSS users should configure TLS with mutual certificate authentication. Deploy within 30 days per noisgate mitigation SLA for HIGH severity. This is the single highest-impact compensating control.

HIGH 7.8→MEDIUM 5.3

SEVERITY REDUCED

Apply JVM-wide serialization filter to all Camel processes — Add -Djdk.serialFilter=!java.net.;java.;javax.;org.apache.camel.;!* to each Camel application's JVM startup arguments. This enforces a process-wide deserialization allowlist that blocks standard gadget chain classes regardless of whether the Camel-level code fix is applied. Breaks attack-path step 3 — injected gadgets are rejected during deserialization. Deploy within 30 days per noisgate mitigation SLA. Note: test thoroughly in staging, as overly restrictive filters may break legitimate Hazelcast operations.

HIGH 7.8→MEDIUM 4.6

SEVERITY REDUCED

Network-segment Hazelcast ports with explicit allow-lists — Restrict TCP/5701–5801 access to only known Camel application hosts and Hazelcast member IPs using host firewall rules, cloud security groups, or microsegmentation policy. This breaks attack-path step 1 — even an attacker on a different internal VLAN cannot reach the cluster. Deploy within 30 days per noisgate mitigation SLA.

HIGH 7.8→IGNORE 0.0

SEVERITY REDUCED

Upgrade to Apache Camel 4.18.5, 4.22.1, or 4.23.0 — The definitive remediation. Applies JavaSerializationFilterConfig to the two remaining configuration paths. Deploy within 180 days per noisgate remediation SLA for HIGH. Accelerate if your deployment explicitly uses ReplicatedHazelcastAggregationRepository or client-mode Hazelcast endpoints — these are the directly affected paths.

What doesn't work

WAF or reverse proxy in front of the Camel REST/HTTP endpoints — The attack vector is the Hazelcast binary cluster protocol on port 5701, not HTTP traffic. A WAF protecting Camel's REST API is completely irrelevant to this chain.
Upgrading to the CVE-2026-43865 fix versions (4.14.8 / 4.18.3 / 4.21.0) — These contain the *incomplete* fix that CVE-2026-78162 bypasses. You must reach 4.18.5, 4.22.1, or 4.23.0.
Camel-level type converters, data format restrictions, or route-level interceptors — The deserialization fires inside Hazelcast's own serialization layer *before* Camel ever sees the exchange. Camel-level controls do not intercept it.
Java Security Manager — Deprecated since JDK 17, removed in JDK 24. Not a viable control on any modern runtime.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	No confirmed exploitation. Not listed on CISA KEV. No GreyNoise, Shadowserver, or Proofpoint campaign tags observed as of 2026-10-19. CVE is 4 days old — exploitation window is early but the internal-network prerequisite limits drive-by scanning.
Proof of Concept	Public PoC available — day-one quality. oscerd/CVE-2026-78162 published 2026-10-16 with complete working reproducers for Camel Spring Boot (4.22.0) and Camel Quarkus (3.29.0). Same researcher published the original CVE-2026-43865 PoC. Listed on Sploitus. Not yet indexed on pocindex.io.
EPSS Score	Not yet scored. FIRST EPSS API returns empty — CVE is too new (disclosed Oct 15). Expect scoring within 1–2 weeks. Given public PoC, low-complexity exploitation, and CWE-502 base rate, anticipate a score in the 0.15–0.40 range (75th–90th percentile).
CISA KEV Status	Not listed. No evidence of active exploitation to trigger KEV inclusion at this time.
CVSS Vector	No official vendor CVSS vector or score. Strix.ai auto-generated `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H` (10.0) — this wildly overstates reachability by modeling AV:N without accounting for the Hazelcast-internal-network prerequisite. A realistic CVSS 3.1 estimate using AV:A (Adjacent): `CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` → 8.8. Apache's blog categorizes severity as MEDIUM but provides no numeric score.
Affected Versions	Apache Camel 4.0.0 – 4.18.4 and 4.19.0 – 4.22.0. Camel Quarkus `camel-quarkus-hazelcast` 3.29.0 (maps to Camel 4.15.0). Only deployments using the `camel-hazelcast` component are affected — vanilla Camel without Hazelcast integration is not vulnerable.
Fixed Versions	4.18.5 (LTS), 4.22.1, 4.23.0. Camel Quarkus users must update to the platform release shipping Camel ≥4.22.1. Note: the prior fix versions (4.14.8, 4.18.3, 4.21.0 for CVE-2026-43865) are still vulnerable to this bypass.
Fix Bypass Context	Incomplete fix of CVE-2026-43865. The original patch introduced `HazelcastSerializationFilterHelper` and applied it to 4 of 6 Camel-managed Hazelcast configuration sites. CVE-2026-78162 covers the remaining two: `ReplicatedHazelcastAggregationRepository.doStart()` and `HazelcastDefaultComponent.getOrCreateHzClientInstance()`.
Exposure Surface	Apache Camel is used by ~4,000–8,600 companies globally per Enlyft and reo.dev, including Fortune 500, banks, airlines, and healthcare providers. The subset actively using `camel-hazelcast` is significantly smaller. Hazelcast port 5701 is virtually absent from Shodan — the attack surface is internal-network-only in practice.
Credited Researchers	Discovered by cattier (TCBS) and Leon Zlobecki. PoC published by oscerd (Andrea Cosentino, Apache Camel PMC member/committer).

Sources.

05 · The Call

Final Verdict

↑ UPGRADED to HIGH (7.8/10)

Why this verdict

Internal-network-only, but zero-friction once there: Hazelcast clusters ship with no authentication and no TLS by default. The sole real gate is network reachability to port 5701 — an internal-network prerequisite. But within that boundary, exploitation is trivially weaponizable with the public oscerd PoC. This is one hop from internal foothold to RCE, not a complex multi-stage chain.
Fix bypass creates dangerous false confidence: Organizations that patched CVE-2026-43865 by upgrading to 4.14.8, 4.18.3, or 4.21.0 believe they are protected. They are not. The two missed configuration paths re-expose the original vulnerability on these 'patched' versions. This false sense of security is a real-world risk amplifier that warrants urgency beyond a typical MEDIUM.
Public PoC with day-one maturity: oscerd's GitHub repository provides complete, tested exploits for both Camel Spring Boot and Camel Quarkus, published one day after disclosure. The researcher is an Apache Camel PMC committer — the PoC is authoritative and immediately reproducible by any internal threat or red team.
Role multiplier: Apache Camel's canonical deployment role is integration middleware — a data-routing hub connecting databases, message queues, REST APIs, and cloud services. RCE on a Camel server yields access to credentials and live sessions for every backend the routes touch. In financial services and healthcare (documented heavy Camel adopters), this means access to regulated data stores and transaction systems. The blast radius is host → multiple connected backends → potential mass data egress of regulated data. This multi-system lateral-movement outcome is plausible in ≥30% of production Camel-Hazelcast deployments, establishing a HIGH floor.
Narrowing factors that prevent CRITICAL: The chain requires prior internal network compromise — this is a post-access escalation vector, not internet-facing initial access. The installed base specifically using camel-hazelcast is a fraction of all Camel deployments. No confirmed in-the-wild exploitation exists.

Why not higher?

CRITICAL would require either internet-facing exploitability or the affected component being canonically identity/infrastructure-defining (DC, hypervisor, IdP, CA, network edge). Hazelcast clusters are never internet-exposed in standard deployments, and Apache Camel is middleware — not an identity or infrastructure control plane. The chain demands prior internal network compromise, which is a material prerequisite that disqualifies unauthenticated-remote-initial-access status. The specific component (camel-hazelcast) is also a subset of all Camel installations, further narrowing the reachable population.

Why not lower?

MEDIUM would underweight the zero-friction exploitation once internal (no auth, no TLS, authoritative public PoC on day one) and the blast radius of compromising an integration hub. A Camel server with RCE is not a dead-end host — it is a credential-rich pivot point into databases, queues, and APIs across the enterprise. The fix-bypass dimension means defenders who patched CVE-2026-43865 carry a false sense of security, which is an operational risk multiplier. Apache's own MEDIUM categorization does not account for the default-insecure Hazelcast cluster topology or the integration-tier credential exposure.

06 · Verification

Crowdsourced verification payload.

Run on each host where Apache Camel applications are deployed. Scans for camel-hazelcast JARs and checks versions against patched releases. Execute as any user with read access to application lib directories: bash check_cve_2026_78162.sh /opt/myapp/lib. No elevated privileges required.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_78162.sh - Detect CVE-2026-78162 vulnerable camel-hazelcast JARs
# Usage: bash check_cve_2026_78162.sh [search_directory]
# Exit codes: 0=PATCHED  1=VULNERABLE  2=UNKNOWN (no JARs found)
set -euo pipefail

SEARCH_DIR="${1:-/}"
FOUND=0
VULN=0

echo "[*] CVE-2026-78162 checker — scanning for camel-hazelcast JARs under ${SEARCH_DIR}"

while IFS= read -r -d '' jar; do
  FOUND=1
  VERSION=$(basename "$jar" | sed -n 's/^camel-hazelcast-\([0-9][0-9.]*\).*/\1/p')
  if [ -z "$VERSION" ]; then
    VERSION=$(unzip -p "$jar" META-INF/MANIFEST.MF 2>/dev/null \
      | grep -iE 'Bundle-Version|Implementation-Version' \
      | head -1 | sed 's/.*: *//' | tr -d '\r')
  fi
  if [ -z "$VERSION" ]; then
    echo "[?] UNKNOWN version: $jar"
    continue
  fi
  IFS='.' read -r MAJ MIN PAT <<< "$VERSION"
  PAT=${PAT%%[^0-9]*}; MAJ=${MAJ:-0}; MIN=${MIN:-0}; PAT=${PAT:-0}
  STATUS="PATCHED"
  if [ "$MAJ" -eq 4 ]; then
    if [ "$MIN" -le 17 ]; then
      STATUS="VULNERABLE"
    elif [ "$MIN" -eq 18 ] && [ "$PAT" -le 4 ]; then
      STATUS="VULNERABLE"
    elif [ "$MIN" -ge 19 ] && [ "$MIN" -le 21 ]; then
      STATUS="VULNERABLE"
    elif [ "$MIN" -eq 22 ] && [ "$PAT" -eq 0 ]; then
      STATUS="VULNERABLE"
    fi
  elif [ "$MAJ" -lt 4 ]; then
    STATUS="PATCHED"  # pre-4.x not affected
  fi
  if [ "$STATUS" = "VULNERABLE" ]; then
    echo "[!] VULNERABLE - $jar ($VERSION)"
    VULN=1
  else
    echo "[+] PATCHED   - $jar ($VERSION)"
  fi
done < <(find "$SEARCH_DIR" -name 'camel-hazelcast-*.jar' -print0 2>/dev/null)

if [ "$FOUND" -eq 0 ]; then
  echo "[*] No camel-hazelcast JARs found. Component may not be in use."
  echo "UNKNOWN"
  exit 2
elif [ "$VULN" -eq 1 ]; then
  echo "VULNERABLE"
  exit 1
else
  echo "PATCHED"
  exit 0
fi