| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| org.apache.cassandra:cassandra-all | maven | = 4.0.16 | 4.0.17 |
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.ensurePermission Modification: 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 on ALL KEYSPACES and requires an explicit permission grant on the system keyspace itself. This is the primary fix that prevents the privilege escalation.
GrantPermissionsStatement Validation: As a defense-in-depth measure, the patch also introduces validation to the GRANT statement execution path. A new validate method 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.
Ongoing coverage of React2Shell