The Bottom Line

Hazelcast has patched a flaw that lets a low-privileged client read arbitrary memory from any cluster member. The bug affects both Hazelcast Enterprise Edition and Community Edition. It exposes Java heap memory, off-heap data, and the JVM process address space to attackers who already hold valid client credentials.

In some Enterprise Edition configurations, the same flaw can corrupt memory. That corruption can escalate to remote code execution. Both slim and full distributions carry the vulnerability, so deployment packaging offers no protection.

Hazelcast published fixed versions and a security advisory on October 8, 2026. Organizations running affected clusters should treat this as an urgent patching priority, especially if clients run on networks outside strict trust boundaries.

What Happened

Hazelcast disclosed the vulnerability through a GitHub Security Advisory. The advisory describes a flaw that lets a malicious client with low privileges access memory it should never see. A client that can connect to a cluster member can pull data from that member's Java heap.

The exposure goes further than application data. Attackers can reach off-heap memory regions and the broader JVM process address space. That means credentials, session data, or other sensitive runtime state could leak to an authenticated but otherwise unprivileged client.

The flaw also creates an availability risk. A malicious client can trigger crashes in one or more cluster members. In certain Enterprise Edition configurations, the same access path allows memory corruption rather than just disclosure or crashes.

Memory corruption bugs in a clustering engine carry serious weight. Hazelcast's advisory states this corruption can potentially lead to remote code execution in affected Enterprise configurations. That turns a read primitive into a full compromise path for cluster infrastructure.

Hazelcast did not attribute discovery to a named external researcher in the advisory text. The company released fixed builds alongside the disclosure rather than after a separate embargo period. This is a coordinated patch-and-disclose release, typical for vendor-reported memory safety issues in clustering software.

Who Is Affected

Both Hazelcast Enterprise Edition and Community Edition contain the flaw. Enterprise customers need to upgrade to one of four fixed versions: 5.7.0, 5.6.1, 5.5.10, or 5.4.5. Community Edition users have a single fixed target: version 5.7.0.

Both slim and full distributions are affected, so trimmed-down deployments get no exemption. Customers running older Enterprise releases under extended support contracts are not covered by the listed fixed versions. Hazelcast directs those customers to contact support directly for patch information.

Any environment running Hazelcast as a distributed data grid or caching layer falls in scope. That includes in-memory computing deployments, session stores, and event-streaming backends built on Hazelcast clusters. The risk concentrates wherever clients connect from less-trusted networks or hosts.

By the Numbers

Four fixed Enterprise Edition versions address the flaw: 5.7.0, 5.6.1, 5.5.10, and 5.4.5. Community Edition has one fixed version: 5.7.0. Both affected distribution types, slim and full, appear in the advisory. The advisory was published October 8, 2026, at 17:42:51 -0400. Hazelcast lists five specific hardening recommendations in its guidance alongside the patch.

Why It Matters

Distributed in-memory data grids sit at the center of modern application architectures. They hold session state, cache layers, and often sensitive application data in shared cluster memory. A flaw that lets any authenticated client read arbitrary member memory undermines the core trust model of these systems.

This advisory fits a recurring pattern in clustering and caching software: authorization checks that stop at the client connection layer but fail to constrain what an authenticated client can request from cluster internals. Once a client is in, the system assumes good behavior rather than enforcing strict memory boundaries.

The potential for remote code execution in Enterprise configurations raises the stakes beyond data exposure. Organizations that treat Hazelcast clusters as internal, trusted infrastructure may have under-invested in client-side hardening and network segmentation around these deployments.

What To Do Now

First, identify every Hazelcast cluster in your environment and confirm the edition and version running in production. Second, upgrade Enterprise Edition clusters to 5.7.0, 5.6.1, 5.5.10, or 5.4.5 depending on your current branch. Third, upgrade Community Edition clusters to 5.7.0 without delay.

Fourth, if you run an older Enterprise version under extended support, contact Hazelcast Support directly for a patch rather than waiting for a public fixed build. Fifth, if immediate patching is not possible, restrict cluster access to trusted clients only and harden those clients against compromise, as Hazelcast recommends in its workaround guidance.

Sixth, enable Hazelcast Security and enforce client authorization on every cluster, per the vendor's hardening guide. Seventh, define an explicit allowlist for zero-config Compact serialization rather than relying on default behavior. Eighth, avoid deploying Hazelcast clients on internet-facing or non-secure networks and hosts. Ninth, confirm firewall rules properly scope cluster access, and disable any Hazelcast features your deployment does not actively use. Treat this as a priority patch cycle given the remote code execution potential in Enterprise configurations.

Read the source →