CVE-2026-78162: Apache Camel Hazelcast Fixes and Exposure

CVE-2026-78162 is an incomplete fix in Apache Camel’s Hazelcast integration: two paths that create managed Hazelcast configurations missed a Java deserialization filter. An attacker able to publish into the connected cluster can reach deserialization before the Camel exchange is processed. The immediate task is to identify the configuration path your application actually uses, upgrade to a fixed release, and verify any configuration you supply yourself. The Apache advisory lists 4.18.5, 4.22.1, and 4.23.0 as fixed releases.

The deployment condition matters. This is not evidence that any website running Camel can be compromised by an arbitrary HTTP request. Determine which application creates or connects to Hazelcast, who can publish into that cluster, and what restricts object reconstruction. A public frontend and a cluster-facing integration can have very different exposure, even when they share the same application inventory entry.

The version check is necessary, but not the whole assessment

について Apache advisory’s affected ranges are 4.0.0 before 4.18.5 and 4.19.0 before 4.22.1. Treat these as maintenance-line ranges. Do not compare version strings lexicographically or infer that an older fix for a related CVE covers this one. Inventory both the library used to build the application and the artifact deployed to the running environment.

Apache’s October security release summary says the 4.14.x line reached end of life after 4.14.9 and does not receive this set of fixes. It also warns that some fixes change default behavior. A move to a supported line therefore needs an application regression plan, rather than a ticket that records only a new dependency declaration.

A build file can be correct while an old container remains in service. A deployment can be current while a separately maintained worker still uses an older artifact. Record the image digest or equivalent immutable artifact identity available in your environment, the deployment time, and the application role. Check each relevant replica or workload through the deployment system you control.

Why the severity labels differ

について Apache advisory labels the issue Medium.その Apache CNA record in the CVE repository, published October 19 and updated October 20, contains a CVSS 4.0 base score of 10.0, Critical. Apache’s advisory page is dated October 15. These are different source fields and publication dates, not interchangeable descriptions of a single newly discovered event.

Use the discrepancy as a reason to read the prerequisites. A severity label does not establish that your application runs either affected creation path, that an attacker can publish into its cluster, or that your custom filter is effective. Conversely, an internal-only cluster should not be treated as unreachable without checking its real membership and publishing boundaries. A route with privileged application credentials can make a middleware compromise consequential even when the external network path is narrow.

The retrieved CVE record includes a CISA ADP assessment with exploitation marked poc. That is not a report of a confirmed attack campaign. This article does not establish real-world exploitation from that field, and it does not independently reproduce an exploit. Keep public proof-of-concept status, exposure in your deployment, and evidence of intrusion as separate findings.

Two bootstrap paths missed the earlier protection

The original CVE-2026-43865 advisory addressed unfiltered deserialization in configurations created by Camel, with fixes in 4.14.8, 4.18.3, and 4.21.0. CVE-2026-78162 follows that work because two creation paths remained uncovered. Those earlier target versions should not be reused as closure criteria for the follow-on issue.

について 4.18.x backport explanation identifies the two omissions. ReplicatedHazelcastAggregationRepository overrides doStart without invoking the parent’s startup method, retaining a separate bootstrap block. The client path constructs a ClientConfig for hazelcastMode=client when no referenced ClientConfig or configuration URI is provided. The patch applies the shared filtering helper to both paths and adds support for ClientConfig. User-supplied configurations and instances remain untouched.

That last detail changes the meaning of a successful upgrade. A fixed version can supply a safer default only on the configurations the framework creates and controls. When your application supplies its own configuration or instance, you own the security properties of that object. Passing a dependency version check does not demonstrate that an externally provided instance has a deserialization filter.

This is a useful code-review pattern beyond Camel. A security change in a common helper is complete only if every relevant construction path reaches that helper or provides an equally reviewed control. Inheritance, client-versus-member modes, fallback configuration, and externally injected objects deserve separate tests because they can create different effective policy from similar-looking application settings.

Find the boundary before the exchange handler

The advisory places the dangerous object reconstruction inside Hazelcast’s serialization layer, before Camel processes the exchange. Consequently, an application check that runs only after an exchange arrives cannot be assumed to protect that earlier step. Review where the bytes first become objects, not just the authorization performed in the business route.

For your deployment, draw a small inventory of the cluster’s legitimate members and clients, their network access, their credentials or authentication method, and the data they can publish. Include scheduled jobs, recovery workers, test tools, and administrative access that may not appear in a web application’s request diagram. The review should name actual workloads and owners rather than a broad trusted-network label.

Authentication and transport protection constrain who can reach or participate in a cluster; an object filter constrains what an admitted data path can reconstruct. These controls serve different purposes. An authenticated application can still send an unexpected object, and a carefully filtered application can still expose data if unrelated access controls are weak. Verify each boundary instead of treating one setting as a substitute for the others.

Do not infer compromise from a dependency finding alone. Equally, do not infer safety from a lack of internet-facing Hazelcast ports alone. The relevant question is whether an actor in your threat model can reach the publishing path, directly or through another application. That assessment can be completed through configuration and network policy review without publishing an exploit object to a live cluster.

Safe inventory checks for an owned codebase

Start with the application’s resolved dependency graph and the configuration that actually reaches the deployed workload. The following commands are inventory examples for a Maven project you control. They do not contact a Hazelcast target or test exploitation. Maven may contact your configured artifact repositories when resolving plugins or dependencies; follow your normal build-environment policy.

# Run in the root of an owned Maven project.
mvn dependency:tree -Dincludes=org.apache.camel:camel-hazelcast

# Review relevant references in your owned repository.
# Matches are leads, not a complete configuration analysis.
rg -n 'ReplicatedHazelcastAggregationRepository|hazelcastMode|hazelcastConfigUri|JavaSerializationFilterConfig' .

A matching source reference does not tell you which profile is active. Trace the value through dependency injection, environment-specific configuration, and the workload’s startup path. A missing match does not prove the component is absent: generated configuration, dependencies, external files, or library code can supply it. Keep the resolved artifact and the running environment in the same assessment record.

For each relevant application, record whether the instance is Camel-created or supplied by your code, whether it operates as a member or client, and where its filter configuration comes from. Do not paste production credentials or full private configuration into a shared ticket. Use protected evidence references and a redacted summary sufficient to explain the decision.

The inventory should produce a short decision, not just a scan transcript. Examples include affected version with an affected managed path, fixed version with custom filtering still under review, or component present but no relevant path found within the reviewed scope. The third outcome needs its scope and evidence; it should not become a universal claim about every deployment of the application.

A harmless regression model for an incomplete fix

This offline Python example demonstrates why testing only a shared path can miss an override or alternate factory. It does not use Java serialization, create network listeners, load a gadget chain, or reproduce the Camel vulnerability. All objects are inert Python data, and the names are simplified labels. It tests a control-coverage property rather than an exploit outcome.

from dataclasses import dataclass

@dataclass(frozen=True)
class Config:
    filter_installed: bool

PATHS = (
    "node_endpoint", "aggregation_repository", "idempotent_repository",
    "other_managed_path", "replicated_repository", "client_endpoint",
)

def earlier_factory(path):
    if path not in PATHS:
        raise ValueError("Unknown synthetic path")
    return Config(filter_installed=path not in {
        "replicated_repository", "client_endpoint"
    })

def reviewed_factory(path, supplied=None):
    if path not in PATHS:
        raise ValueError("Unknown synthetic path")
    if supplied is not None:
        return supplied  # Caller policy is preserved; review it separately.
    return Config(filter_installed=True)

missed = [p for p in PATHS if not earlier_factory(p).filter_installed]
assert missed == ["replicated_repository", "client_endpoint"]
for path in PATHS:
    assert reviewed_factory(path).filter_installed
custom = Config(filter_installed=False)
assert reviewed_factory("client_endpoint", supplied=custom) is custom
assert not custom.filter_installed
print("Earlier factory missed:", ", ".join(missed))
print("All six managed paths covered; supplied configuration still needs review.")

Run this with Python 3 after saving it as filter_coverage_demo.py. The expected output names the two missed synthetic paths and confirms coverage of the six managed paths in the revised model. The supplied configuration deliberately remains unfiltered. This is the point of the final assertion: preserving caller policy must not be mistaken for validating that policy.

The model cannot tell you whether a real Java filter accepts a dangerous class graph, enforces resource limits, or permits every legitimate application object. It also cannot establish whether a running JVM uses the configuration you reviewed. Those are separate integration and deployment checks. A passing toy demonstration supports understanding of the failure pattern, not a security certification.

Upgrade without silently breaking application data

について Camel 4.23 upgrade guide’s Hazelcast section describes the default class-prefix policy and warns that applications using classes outside it may need explicit configuration. It also says user-supplied configurations are preserved and describes a startup warning for missing filter configuration unless a JVM-wide filter is set. Interpret that warning within its documented conditions; absence of a warning is not a universal proof of safe deserialization.

Build a regression set from the object types your application legitimately stores and retrieves. Include normal traffic, restart and recovery, replicated aggregation, and whichever member or client mode the deployment actually uses. A test that covers only an ordinary request may miss a background repository operation. Keep production records and secrets out of a portable test fixture; construct representative synthetic data instead.

For a negative test, use a harmless class that the intended policy must reject and verify rejection before application processing. Coordinate it in an isolated environment with the application owner. There is no need to use a command-executing payload to show that a filter denies an out-of-policy type. Ensure the denial does not turn into an endless retry loop or leave a recovery queue unable to make progress.

If a new default rejects a legitimate business type, identify the narrowest reviewed policy change that permits the intended data. Avoid resolving the incident by allowing every class. Record why a type is required, where it originates, and what regression demonstrates the intended behavior. Any explicit policy remains application configuration that future upgrades may preserve rather than repair.

Apache also lists mitigation options for deployments that cannot upgrade immediately. A supplied configuration or instance is useful only if it actually carries the required protection. JVM-wide and Hazelcast-specific filters are different mechanisms: verify syntax, effective scope, precedence, and application compatibility before introducing a filter expression. This article intentionally does not present an unreviewed copy-and-paste JVM expression as a universal safe fix.

Detection and incident review need their own evidence

The sources reviewed here do not provide a complete campaign-specific indicator set for confirmed exploitation. Build monitoring around the deployment’s own boundaries: unexpected cluster participants, changes to publishing access, relevant deserialization errors, unusual Java process behavior, and activity involving application credentials. Treat each as an investigation lead and correlate it with the actual configuration and timeframe.

A rejected object may indicate that a control worked for that object; it does not establish that every object was rejected or that earlier activity was benign. A process crash can have many causes. An empty exception log can mean that logging was unavailable or that no exception was raised. Preserve these limits in the ticket so a narrow observation does not become a clean bill of health.

If an affected application had untrusted publishing exposure, investigate the interval before remediation. Preserve workload logs, deployment history, relevant cluster membership records, and changes to credentials or reachable services according to your incident process. Do not clear the cluster or overwrite the application merely to make a scanner turn green before the evidence owner decides what must be retained.

Keep these outcomes separate. The dependency upgrade may be complete while custom filtering or incident review remains open. That is a more useful status than one combined fixed label, which hides which part of the risk has actually been addressed. Assign an owner and next decision to every remaining uncertainty.

For an authorized application-security assessment, use the same standard when evaluating an automated testing workflow: require a finding to identify its prerequisites, evidence, and remediation test. A black-box web result alone cannot establish internal Hazelcast configuration. Penligent or another assessment tool should be evaluated against the scope and evidence it can actually inspect, without assuming access to middleware state it has not been given.

Questions application owners ask

Is upgrading Hazelcast alone the same as fixing CVE-2026-78162?

No. This finding concerns Camel’s application of Hazelcast filtering on managed configuration paths. Follow the Camel fixed-release guidance and review supplied configurations. A library update or network restriction may be valuable, but it needs its own evidence rather than being treated as an equivalent patch.

Does every application containing camel-hazelcast have a reachable exploit path?

A dependency match establishes a review target. Determine the active instance-creation path, effective filtering, and cluster publishing access before drawing a deployment-specific conclusion. Record unknown conditions instead of inventing an internet exposure.

Was the earlier CVE-2026-43865 upgrade sufficient?

Not for the two paths identified in the follow-on advisory. Review the current fixed-release targets and the configuration used by the running application. An old remediation ticket can be accurate for its original scope while still requiring this additional work.

Can I solve compatibility problems by disabling the filter?

That would remove the protection you are trying to verify. Use a reviewed explicit policy for required business types and test permitted and rejected cases in isolation. Keep the application owner involved in both the data contract and the security decision.

Does a proof of concept mean attackers are exploiting my system?

No. Public exploitability information, deployment exposure, and evidence of compromise are separate questions. Prioritize a potentially reachable affected configuration promptly, while preserving a clear distinction between a preventive fix and an incident finding.

The durable lesson is to test security policy where objects are created and reconstructed. A shared helper, a fixed dependency, and a successful application request each provide useful evidence, but none substitutes for verifying every relevant path. Close the missed path, verify the running configuration, and retain the evidence that explains the decision.