Cassandra's broad data permission crossed into system keyspaces

A permission intended to let a user modify application data should not let that user change the authority governing the database. CVE-2025-23015, published on 4 February, identifies that failure in Apache Cassandra. A user with MODIFY permission on ALL KEYSPACES can escalate to superuser through unsafe actions against a system resource.

The condition is more specific than merely having a Cassandra account. The Apache disclosure, sent by Paulo Motta on 3 February, identifies the broad data grant as the prerequisite. Administrators need to examine the actual scope of granted authority when deciding which accounts were exposed to this path.

Cassandra interests me for its ability to support demanding distributed availability requirements. That does not reduce the need to distinguish application data from administrative state. This disclosure shows why a convenient permission hierarchy needs special rules around the system's own resources.

Permission inheritance included an administrative boundary

The CASSANDRA-20090 patch explains the mechanism through its changes to resource authorization. The patch tightens system-keyspace grants and changes how authorization walks a resource's parents.

A resource hierarchy makes broad permissions useful. A grant at an ancestor can authorize operations on descendants without requiring an entry for every table. That arrangement becomes unsafe when a descendant contains state that controls the user's privileges and the broad grant reaches it.

The old permission-check helper walked the resource chain. The changed code makes the chain selectable through a predicate. That lets the authorization path omit the root resource when it evaluates a system-keyspace resource for an ordinary user.

The distinction is operationally significant. Removing one broad grant at evaluation time is different from relying on administrators never to issue it. The fix changes what that grant means when the requested operation concerns system data.

The advisory does not require a separate network exploit or a new unauthenticated entry point to explain the escalation. Its premise is an already authorized user whose permitted actions reach too far. The failed boundary lies within the authorization model itself.

System keyspaces get an explicit classification

The patch adds a helper that recognizes system keyspaces using both the local-system and replicated-system keyspace sets. It normalizes the supplied name to lowercase before testing membership. Classification therefore follows defined system-keyspace categories rather than a caller's arbitrary idea of which names look administrative.

This is a useful implementation detail because authorization changes need a stable definition of their protected resources. A special case that recognizes only one authentication table can leave other system resources under the old inheritance rules. Here, the check operates at the keyspace classification layer.

The change is also distinct from hiding system objects in a user interface. A table can remain visible for legitimate inspection while write authority follows a stricter path. The permission check needs to enforce that difference when an operation is requested.

The patch's treatment of readable system resources illustrates this separation. It adds tracing resources to the always-readable set while tightening other grants. Observability and data modification do not have to share one permission rule merely because they refer to the same broad family of system keyspaces.

Grant validation and request authorization both change

The patch introduces a set of permissions invalid for system keyspaces. Its comment identifies SELECT, DESCRIBE and ALTER as the only permissions that may be granted there. The set contains the complement of those allowed permissions.

Grant-statement validation examines a data resource that is below the root level. If the resource belongs to a system keyspace and the requested permissions intersect the invalid set, it rejects the operation. This applies when a caller tries to create an explicitly invalid grant.

That validation addresses new grants. It does not by itself establish how a previously recorded broad grant behaves during a later request. The second part of the patch therefore changes the request-time permission chain.

For a non-root data resource in a system keyspace, an ordinary user's permission check constructs a resource chain excluding the root. It then checks the remaining resources. Superusers and system users retain their separately handled status in this path.

Together, those changes address two different ways authority can arrive. Invalid direct grants are rejected, and an ancestor grant on all keyspaces cannot supply ordinary-user permission through the excluded root. Treating either change alone as the entire repair would miss part of the implementation.

The patch comments still allow appropriate explicit or transitive permissions on system resources within the restricted grant set. Excluding root inheritance does not mean every legitimate system-keyspace operation becomes impossible. It requires authority to come through the allowed resource path.

The affected branches have separate update targets

The disclosure lists affected versions through 3.0.30 on the 3.0 line, through 3.11.17 on the later 3.x line, through 4.0.15, through 4.1.7 and through 5.0.2. Its recommended update targets are 3.0.31, 3.11.18, 4.0.16, 4.1.8 and 5.0.3 respectively.

Those are the versions named in the February disclosure. They should be read as branch-specific remediation guidance published with this advisory. A list spanning several release families is not an instruction to move every cluster immediately to a new major version.

The older 3.x targets are relevant because the vulnerable authorization condition is not confined to the newest database series. An inventory that checks only the most recent release family would omit affected installations described by the source.

The CVE record's machine-readable data records the Apache affected ranges and publication time. The security description and the Apache mailing-list text supply the same broad-grant condition. Neither source supports treating all authenticated users as equally able to exploit this particular flaw.

Reviewing grants is different from installing the patch

Apache asks operators who granted MODIFY on all keyspaces to review data-access rules for possible breaches. That recommendation concerns authority that may already have been exercised. Updating the permission-check implementation prevents the described path going forward, but does not prove that existing role state is the state an administrator intended.

An access review therefore has a different question from a version check. Version inspection identifies which software rules a node runs. Grant and role inspection identifies who currently holds authority. A complete incident assessment cannot replace one with the other.

This distinction also changes the meaning of a broad application role. Such a role may have been created for convenience across many application keyspaces. The administrator's intention does not narrow the server's actual interpretation on affected versions. Exposure follows the implemented scope.

My preference is to give application roles the specific keyspace authority they require. That is a design judgment supported by this failure mode, rather than a claim that narrow grants cure every authorization defect. Reducing inherited scope makes the application's intended authority easier to compare with its recorded permissions.

The tests exercise real authorization decisions

The patch adds grant-and-revoke tests and prepares a test environment with password authentication, the Cassandra role manager and Cassandra authorization. It disables permission-cache validity in that setup so the tests can examine authorization behavior without waiting for cached entries to expire.

This setup matters because a test that merely constructs the invalid permission set cannot establish that a client request reaches the new checks. The added test infrastructure includes a native server and authenticated driver sessions. It can exercise the grant model through the interface used by clients.

The patch also changes the resource-chain helper to accept a filter while retaining its unfiltered convenience form. That limits the special system-keyspace behavior to callers that request it. Ordinary permission inheritance remains represented by the existing unfiltered operation.

The regression is therefore a lesson about the placement of authorization policy. Grant storage, resource classification and request-time inheritance each contribute to the final decision. A correct data grant requires all of them to agree on where administrative state stops being ordinary data.

The public advisory defines the immediate response

The disclosure credits Adam Pond, Ali Mirheidari, Terry Thibault and Will Brattain of Apple Services Engineering Security. Apache classifies the issue as moderate in its announcement. Its concrete remediation guidance is to install the named branch update and review broad data-access rules where the prerequisite grant existed.

For an operator assessing the cluster on this publication date, the decisive facts are its release branch and the accounts that hold MODIFY on ALL KEYSPACES. The fix changes system-resource grant validation and prevents that root-level data authority from automatically authorizing ordinary-user actions within system keyspaces.