CVE-2026-107726: Unrestricted Deserialization in Hazelcast Zero Config Compact Serialization

Hazelcast combines stream processing with an in-memory data store, presenting a unified real-time data platform. A critical security flaw within the Zero Config Compact Serialization (ZCCS) engine allows unauthenticated network clients to exploit cluster members. This vulnerability affects both the Community and Enterprise Editions, spanning several minor version branches.

At its core, ZCCS facilitates dynamic object serialization by mapping schema declarations to Java classes present on the classpath. However, the system failed to validate the classes specified by the client before attempting reflective instantiation. This lack of validation creates a pathway for attackers to execute arbitrary memory operations and disrupt cluster operations.

By leveraging this flaw, a remote attacker can force a cluster member to load, instantiate, and populate arbitrary classes. This process can leak sensitive data from the JVM heap, corrupt memory structures, or cause the cluster node to crash. The severity of this issue is tracked as CVSS 9.3, signifying a critical vulnerability with severe operational consequences.

The vulnerability stems from the implementation of Hazelcast's dynamic serialization resolver, which processes client-provided schemas without access control or structural verification. When a client transmits a serialized object, the cluster member parses the schema to identify the target class name via the typeName property. In vulnerable versions, the ReflectiveCompactSerializer resolves this name and attempts to reconstruct the class directly.

No restrictions or allowlists were historically applied to this dynamic class resolution pipeline. Consequently, any class available on the application classpath—including standard JDK libraries, third-party libraries, and internal Hazelcast classes—could be instantiated reflectively. This behavior essentially permits arbitrary class instantiation under the control of an untrusted network client.

This lack of restriction becomes critical when combined with classes that manipulate native memory or interact with system resources. If an attacker specifies a class that manages direct byte buffers or utilizes internal APIs like sun.misc.Unsafe, they can manipulate field values to read or write arbitrary memory addresses. This structural design flaw represents a classic case of improper input validation during deserialization, tracked under CWE-20.

The primary remediation of the vulnerability is found in commit 361979da12f18950c24719db832ca6c5e7c0534f. The patch introduces a dedicated security component named ReflectiveClassFilter to intercept dynamic serialization requests. This filter enforces class boundaries before the JVM attempts class loading or instantiation.

Below is the structured implementation of the ReflectiveClassFilter introduced in the patch:

public class ReflectiveClassFilter {
    private static final ClassFilter JDK_LIB_BLOCKLIST = new ClassFilter()
            .addPrefixes("java.", "javax.", "com.sun.", "sun.", "jdk.");
 
    @Nullable
    private final ClassFilter blockList;
    @Nullable
    private final ClassFilter allowList;
 
    public ReflectiveClassFilter(@Nonnull CompactSerializationConfig config,
                                 @Nonnull ExtraReflectiveCompactSerializationRestrictions extraRestrictions) {
        blockList = union(JDK_LIB_BLOCKLIST, defaultBlockList, extraRestrictions.propertyBlockList(), configuredBlockList);
        allowList = union(extraRestrictions.propertyAllowList(), configuredAllowList);
    }
 
    public boolean isRestricted(@Nonnull Class<?> clazz) {
        return clazz.getPackage() == null || isOnBlockList(clazz) || !isOnAllowList(clazz);
    }
}

In addition to checking the class names, the patch integrates this filter directly into the serialization flow within CompactStreamSerializer.java. The canBeSerializedAsCompact method is modified to assess whether a class is restricted before returning its serializer:

    public boolean canBeSerializedAsCompact(Class<?> clazz) {
        Class<? extends SerializerAdapter> assignedSerializerType = lookupSerializerType.apply(clazz);
        return CompactStreamSerializerAdapter.class.isAssignableFrom(assignedSerializerType) && (
                classToRegistrationMap.containsKey(clazz) || !classFilter.isRestricted(clazz));
    }

If the class is found to be restricted, the engine gracefully falls back to using a GenericRecord instead of throwing a severe processing error. This prevents reflective class instantiation while preserving session stability for legitimate interactions.

An exploitation attempt begins with a client establishing a standard TCP connection to the cluster's communication port, usually port 5701. Since the vulnerability resides within the core client-to-member protocol, authentication is not a strictly required barrier if the cluster operates under default or loosely configured security roles. Once connected, the malicious client begins the serialization negotiation phase.

The attacker constructs and transmits a schema payload containing a crafted typeName set to a target class. For example, the attacker might target a class that manages internal JVM resources, off-heap data pointers, or native array lengths. After the schema registration is accepted, the client sends a data operation, such as an IMap insertion or lookup, containing the binary payload mapping to that schema.

Upon receiving the payload, the target Hazelcast member parses the stream and triggers the reflective deserialization sequence. If the target class utilizes native pointers (e.g., off-heap memory addresses) mapped to serializable fields, the client-supplied values overwrite these pointers. When the member attempts to access or serialize this object back, it reads from the manipulated address, resulting in an information leak or a segmentation fault.

The impact of exploiting CVE-2026-107726 depends on the cluster environment and classpath configuration. Under typical conditions, the primary impact is a severe confidentiality leak of JVM heap memory, off-heap data structures, and process address space. Attackers can leverage this leak to extract sensitive information, such as active session data, configuration secrets, or cryptographic keys.

In environments running Hazelcast Enterprise Edition, the impact is further amplified by the platform's intensive use of native off-heap storage. By corrupting internal reference pointers, an attacker can corrupt native memory structures. This memory corruption can lead directly to system instability, triggering abrupt node crashes and resulting in cluster-wide Denial of Service (DoS).

Under specific conditions where dangerous library gadgets exist on the application classpath, this vulnerability can lead to remote code execution (RCE). An attacker can utilize the unrestricted dynamic instantiation to trigger specific gadget chains that execute system commands. The vulnerability has been assigned a CVSS score of 9.3, indicating its potential to compromise confidentiality, integrity, and availability completely.

The primary remediation path requires upgrading Hazelcast to a non-vulnerable version. Organizations should upgrade to version 5.4.5, 5.5.10, 5.6.1, or 5.7.0 and later immediately. These versions contain the complete patch and enforce strict validation on all Zero Config Compact Serialization (ZCCS) requests.

For environments where immediate upgrades are not feasible, administrators must implement workarounds by restricting the ZCCS engine via configuration. A declarative configuration must be added to the Hazelcast XML or YAML settings. This configuration restricts ZCCS to a predefined list of safe classes, packages, or prefixes.

Below is an example of an XML configuration using the zero-config-filter element to limit dynamic serialization:

<serialization>
    <compact-serialization>
        <zero-config-filter defaults-disabled=\"false\">
            <blacklist>
                <class>com.acme.app.BeanComparator</class>
            </blacklist>
            <whitelist>
                <class>example.Foo</class>
                <package>com.acme.app</package>
                <prefix>com.acme.</prefix>
            </whitelist>
        </zero-config-filter>
    </compact-serialization>
</serialization>

In addition to configuration-level mitigations, network segmentations should be enforced. Access to the client communication ports (default 5701) must be strictly restricted to trusted application nodes using stateful firewalls or security groups.