CVE-2025-26467: Apache Cassandra: User with MODIFY permission on ALL KEYSPACES can escalate privileges to superuser via unsafe actions (4.0.16 only)
8.8
Basic Information
Technical Details
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| org.apache.cassandra:cassandra-all | maven | = 4.0.16 | 4.0.17 |
Vulnerability Intelligence
Miggo AI
Root Cause Analysis
The vulnerability allows a user with MODIFY permission on ALL KEYSPACES to escalate their privileges to a superuser. This is because Apache Cassandra version 4.0.16 incorrectly applied permissions granted on ALL KEYSPACES to system keyspaces, which contain sensitive data and configuration.
The analysis of the patch between version 4.0.16 and the fixed version 4.0.17 reveals two key changes that address this issue:
-
ClientState.ensurePermissionModification: The core of the vulnerability lies in this function, which is central to all authorization checks. The patch introduces logic to specifically check if a resource belongs to a system keyspace. If it does, it ignores any permissions granted onALL KEYSPACESand requires an explicit permission grant on the system keyspace itself. This is the primary fix that prevents the privilege escalation. -
GrantPermissionsStatementValidation: As a defense-in-depth measure, the patch also introduces validation to theGRANTstatement execution path. A newvalidatemethod prevents the granting of a denylist of powerful permissions (e.g.,CREATE,DROP,MODIFY) directly on system keyspaces. This hardens the system against misconfiguration.
Therefore, during exploitation, two functions would be involved. First, GrantPermissionsStatement.execute would be used (by an admin) to set up the vulnerable state (GRANT MODIFY ON ALL KEYSPACES). Second, and more critically, ClientState.ensurePermission would be on the runtime stack when the non-privileged user performs a malicious action on a system table, as this function would incorrectly authorize the action in the vulnerable version.