Vulnerabilities

Hazelcast Management Center through 6.0 allows remote code execution via a JndiLoginModule user.provider.url in a hazelcast-client XML document (aka a client configuration file), which can be uploaded at the /cluster-connections URI.

In Hazelcast through 4.1.10, 4.2 through 4.2.8, 5.0 through 5.0.5, 5.1 through 5.1.7, 5.2 through 5.2.4, and 5.3 through 5.3.2, some client operations don't check permissions properly, allowing authenticated users to access data stored in the cluster.

In Hazelcast Platform through 5.3.4, a security issue exists within the SQL mapping for the CSV File Source connector. This issue arises from inadequate permission checking, which could enable unauthorized clients to access data from files stored on a member's filesystem.

In Hazelcast through 5.0.4, 5.1 through 5.1.6, and 5.2 through 5.2.3, executor services don't check client permissions properly, allowing authenticated users to execute tasks on members without the required permissions granted.

In Hazelcast through 5.0.4, 5.1 through 5.1.6, and 5.2 through 5.2.3, configuration routines don't mask passwords in the member configuration properly. This allows Hazelcast Management Center users to view some of the secrets.

The Connection handler in Hazelcast and Hazelcast Jet allows a remote unauthenticated attacker to access and manipulate data in the cluster with the identity of another already authenticated connection. The affected Hazelcast versions are through 4.0.6, 4.1.9, 4.2.5, 5.0.3, and 5.1.2. The affected Hazelcast Jet versions are through 4.5.3.

Improper Restriction of XML External Entity Reference in GitHub repository hazelcast/hazelcast in 5.1-BETA-1.

The LDAP authentication method in LdapLoginModule in Hazelcast IMDG Enterprise 4.x before 4.0.3, and Jet Enterprise 4.x through 4.2, doesn't verify properly the password in some system-user-dn scenarios. As a result, users (clients/members) can be authenticated even if they provide invalid passwords.

In Hazelcast before 3.11, the cluster join procedure is vulnerable to remote code execution via Java deserialization. If an attacker can reach a listening Hazelcast instance with a crafted JoinRequest, and vulnerable classes exist in the classpath, the attacker can run arbitrary code.