Authenticated DoS over CQL in Apache Cassandra 4.0, 4.1, 5.0 allows authenticated user to raise query latencies via repeated password changes. Users are recommended to upgrade to version 4.0.20, 4.1.11, 5.0.7, which fixes this issue.
Sensitive Information Leak in cqlsh in Apache Cassandra 4.0 allows access to sensitive information, like passwords, from previously executed cqlsh command via ~/.cassandra/cqlshhistory local file access.
Users are recommended to upgrade to version 4.0.20, which fixes this issue.
-- Description: Cassandra's command-line tool, cqlsh, provides a command history feature that allows users to recall previously executed commands using the up/down arrow keys. These history records are saved in the ~/.cassandra/cqlshhistory file in the user's home directory.
However, cqlsh does not redact sensitive information when saving command history. This means that if a user executes operations involving passwords (such as logging in or creating users) within cqlsh, these passwords are permanently stored in cleartext in the history file on the disk.
Privilege escalation in Apache Cassandra 5.0 on an mTLS environment using MutualTlsAuthenticator allows a user with only CREATE permission to associate their own certificate identity with an arbitrary role, including a superuser role, and authenticate as that role via ADD IDENTITY.
Users are recommended to upgrade to version 5.0.7+, which fixes this issue.
Severity: low
Affected versions:
- Apache Cassandra (apache-cassandra) 4.0 through 4.0.19
Description:
Sensitive Information Leak in cqlsh in Apache Cassandra 4.0 allows access to sensitive information, like passwords, from previously executed cqlsh command via ~/.cassandra/cqlshhistory local file access.
Users are recommended to upgrade to version 4.0.20, which fixes this issue.
-- Description: Cassandra's command-line tool, cqlsh, provides a command history feature that allows users to recall previously executed commands using the up/down arrow keys. These history records are saved in the ~/.cassandra/cqlshhistory file in the user's home directory.
However, cqlsh does not redact sensitive information when saving command history. This means that if a user executes operations involving passwords (such as logging in or creating users) within cqlsh, these passwords are permanently stored in cleartext in the history file on the disk.
This issue is being tracked as CASSANDRA-21180
Credit:
Youlong Chen, Institute of Computing Technology, Chinese Academy of Sciences (reporter)
References:
https://issues.apache.org/jira/browse/CASSANDRA-21180 https://cassandra.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-27315 https://issues.apache.org/jira/browse/CASSANDRA-21180
Summary / Details Systems running the Instaclustr fork of Stratio's Cassandra-Lucene-Index plugin versions 4.0-rc1-1.0.0 through 4.0.16-1.0.0 and 4.1.0-1.0.0 through 4.1.8-1.0.0, installed into Apache Cassandra version 4.x, are susceptible to a vulnerability which when successfully exploited could allow authenticated Cassandra users to remotely bypass RBAC to access data and and escalate their privileges.
Affected Versions - Cassandra-Lucene-Index plugin versions 4.0-rc1-1.0.0 through 4.0.16-1.0.0 - versions 4.1.0-1.0.0 through 4.1.8-1.0.0 when installed into Apache Cassandra version 4.x.
Required Configuration for Exploit These are the conditions required to enable exploit: 1. Cassandra 4.x 2. Vulnerable version of the Cassandra-Lucene-Index plugin configured for use 3. Data added to tables 4. Lucene index created 5. Cassandra flush has run
Mitigation/Prevention Mitigation requires dropping all Lucene indexes and stopping use of the plugin. Exploit will be possible any time the required conditions are met.
Solution Upgrade to a fixed version of the Cassandra-Lucene-Index plugin. Review users in Cassandra to validate all superuser privileges.
Privilege Defined With Unsafe Actions vulnerability in Apache Cassandra. An user with MODIFY permission ON ALL KEYSPACES can escalate privileges to superuser within a targeted Cassandra cluster via unsafe actions to a system resource. Operators granting data MODIFY permission on all keyspaces on affected versions should review data access rules for potential breaches.
This issue affects Apache Cassandra 3.0.30, 3.11.17, 4.0.16, 4.1.7, 5.0.2, but this advisory is only for 4.0.16 because the fix to CVE-2025-23015 was incorrectly applied to 4.0.16, so that version is still affected.
Users in the 4.0 series are recommended to upgrade to version 4.0.17 which fixes the issue. Users from 3.0, 3.11, 4.1 and 5.0 series should follow recommendation from CVE-2025-23015.
Incorrect Authorization vulnerability in Apache Cassandra allowing users to access a datacenter or IP/CIDR groups they should not be able to when using CassandraNetworkAuthorizer or CassandraCIDRAuthorizer.
Users with restricted data center access can update their own permissions via data control language (DCL) statements on affected versions.
This issue affects Apache Cassandra: from 4.0.0 through 4.0.15 and from 4.1.0 through 4.1.7 for CassandraNetworkAuthorizer, and from 5.0.0 through 5.0.2 for both CassandraNetworkAuthorizer and CassandraCIDRAuthorizer.
Operators using CassandraNetworkAuthorizer or CassandraCIDRAuthorizer on affected versions should review data access rules for potential breaches. Users are recommended to upgrade to versions 4.0.16, 4.1.8, 5.0.3, which fixes the issue.
Privilege Defined With Unsafe Actions vulnerability in Apache Cassandra. An user with MODIFY permission ON ALL KEYSPACES can escalate privileges to superuser within a targeted Cassandra cluster via unsafe actions to a system resource. Operators granting data MODIFY permission on all keyspaces on affected versions should review data access rules for potential breaches.
This issue affects Apache Cassandra through 3.0.30, 3.11.17, 4.0.15, 4.1.7, 5.0.2.
Users are recommended to upgrade to versions 3.0.31, 3.11.18, 4.0.16, 4.1.8, 5.0.3, which fixes the issue.
In Apache Cassandra it is possible for a local attacker without access to the Apache Cassandra process or configuration files to manipulate the RMI registry to perform a man-in-the-middle attack and capture user names and passwords used to access the JMX interface. The attacker can then use these credentials to access the JMX interface and perform unauthorized operations.
This is same vulnerability that CVE-2020-13946 was issued for, but the Java option was changed in JDK10.
This issue affects Apache Cassandra from 4.0.2 through 5.0.2 running Java 11.
Operators are recommended to upgrade to a release equal to or later than 4.0.15, 4.1.8, or 5.0.3 which fixes the issue.
An improper access control vulnerability in the Azure Managed Instance for Apache Cassandra allows an authenticated attacker to elevate privileges over a network.
Privilege escalation when enabling FQL/Audit logs allows user with JMX access to run arbitrary commands as the user running Apache Cassandra This issue affects Apache Cassandra: from 4.0.0 through 4.0.9, from 4.1.0 through 4.1.1.
WORKAROUND The vulnerability requires nodetool/JMX access to be exploitable, disable access for any non-trusted users.
MITIGATION Upgrade to 4.0.10 or 4.1.2 and leave the new FQL/Auditlog configuration property allownodetoolarchivecommand as false.
Severity: important
Affected versions:
- Apache Cassandra 4.0.0 through 4.0.9 - Apache Cassandra 4.1.0 through 4.1.1
Description:
Privilege escalation when enabling FQL/Audit logs allows user with JMX access to run arbitrary commands as the user running Apache Cassandra This issue affects Apache Cassandra: from 4.0.0 through 4.0.9, from 4.1.0 through 4.1.1.
WORKAROUND The vulnerability requires nodetool/JMX access to be exploitable, disable access for any non-trusted users.
MITIGATION Upgrade to 4.0.10 or 4.1.2 and leave the new FQL/Auditlog configuration property allownodetoolarchivecommand as false.
This issue is being tracked as CASSANDRA-18550
Credit:
Gal Elbaz at Oligo (finder)
References:
https://cassandra.apache.org/ https://www.cve.org/CVERecord?id=CVE-2023-30601 https://issues.apache.org/jira/browse/CASSANDRA-18550
When running Apache Cassandra with the following configuration: enableuserdefinedfunctions: true enablescripteduserdefinedfunctions: true enableuserdefinedfunctionsthreads: false it is possible for an attacker to execute arbitrary code on the host. The attacker would need to have enough permissions to create user defined functions in the cluster to be able to exploit this. Note that this configuration is documented as unsafe, and will continue to be considered unsafe after this CVE.
Apache Cassandra versions 2.1.0 to 2.1.22, 2.2.0 to 2.2.19, 3.0.0 to 3.0.23, and 3.11.0 to 3.11.9, when using 'dc' or 'rack' internodeencryption setting, allows both encrypted and unencrypted internode connections. A misconfigured node or a malicious user can use the unencrypted connection despite not being in the same rack or dc, and bypass mutual TLS requirement.
In Apache Cassandra, all versions prior to 2.1.22, 2.2.18, 3.0.22, 3.11.8 and 4.0-beta2, it is possible for a local attacker without access to the Apache Cassandra process or configuration files to manipulate the RMI registry to perform a man-in-the-middle attack and capture user names and passwords used to access the JMX interface. The attacker can then use these credentials to access the JMX interface and perform unauthorised operations. Users should also be aware of CVE-2019-2684, a JRE vulnerability that enables this issue to be exploited remotely.
Reference: https://lists.apache.org/thread.html/rcd7544b24d8fc32b7950ec4c117052410b661babaa857fb1fc641152%40%3Cuser.cassandra.apache.org%3E
A flaw was found in cassandra in versions prior to 2.1.22, 2.2.18, 3.0.22, 3.11.8 and 4.0-beta2. A local attacker without access to the Apache Cassandra process or configuration files can manipulate the RMI registry to perform a man-in-the-middle attack and capture user names and passwords used to access the JMX interface. A JRE vulnerability (CVE-2019-2684) enables this issue to be exploited remotely. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
A flaw was found in the RMI registry implementation in the RMI component of OpenJDK. Incorrect handling of the server-side dispatch could lead to selection of an incorrect skeleton class.
The default configuration in Apache Cassandra 3.8 through 3.11.1 binds an unauthenticated JMX/RMI interface to all network interfaces, which allows remote attackers to execute arbitrary Java code via an RMI request. This issue is a regression of CVE-2015-0225. The regression was introduced in https://issues.apache.org/jira/browse/CASSANDRA-12109. The fix for the regression is implemented in https://issues.apache.org/jira/browse/CASSANDRA-14173. This fix is contained in the 3.11.2 release of Apache Cassandra.
End of life: 9/5/2024, Latest version: 3.11.19
End of life: 9/5/2024, Latest version: 3.11.19
Due to a bug in handling return code from openssl native calls, the SslHandler that uses OpenSslEngine can end up in an infinite loop and eat up all CPU cycles, which may lead to DoS of the system.
This can only happen if the server has renegotiation enabled (which is set as default). Only systems using SslProvider.OpenSsl are affected, that will be true if netty-tcnative is in the classpath and openssl is installed.
If netty-tcnative is linked against boringssl, the problem does not exist, since renegotiation is not supported in boringssl.
Versions affected: Netty 4.0.0.Final - 4.0.36.Final and 4.1.0.Final
Workaround:
Users can use -Djdk.tls.rejectClientInitiatedRenegotiation=true to disable renegotiation and avoid this issue.
It was discovered that the RMI (Java Remote Method Invocation) server implementation in the JMX (Java Management Extensions) component of OpenJDK did not restrict which classes can be deserialized when deserializing authentication credentials. A remote unauthenticated attacker able to connect to a JMX port could possibly use this flaw trigger deserialization flaws.
End of life: 9/5/2024, Latest version: 3.0.32
End of life: 9/5/2024, Latest version: 3.0.32
The default configuration in Apache Cassandra 1.2.0 through 1.2.19, 2.0.0 through 2.0.13, and 2.1.0 through 2.1.3 binds an unauthenticated JMX/RMI interface to all network interfaces, which allows remote attackers to execute arbitrary Java code via an RMI request.