CVE-2025-26467: Apache Cassandra Privilege Escalation Flaw

CVE-2025-26467 Overview

CVE-2025-26467 is a privilege escalation vulnerability in Apache Cassandra 4.0.16. A user holding MODIFY permission ON ALL KEYSPACES can escalate to superuser privileges within a targeted Cassandra cluster by performing unsafe actions against a system resource. The flaw exists because the fix for CVE-2025-23015 was incorrectly applied to the 4.0.16 release, leaving that version exposed. The vulnerability is classified under [CWE-267] (Privilege Defined With Unsafe Actions) and carries a CVSS score of 8.8.

Critical Impact

An authenticated low-privilege Cassandra user with broad MODIFY rights can obtain superuser control over the cluster, compromising confidentiality, integrity, and availability of all stored data.

Affected Products

• Apache Cassandra 4.0.16
• Apache Cassandra 3.0.30, 3.11.17, 4.1.7, and 5.0.2 (covered separately by CVE-2025-23015)
• Clusters granting data MODIFY permission on all keyspaces to non-administrative users

Discovery Timeline

• 2025-08-25 - CVE-2025-26467 published to NVD
• 2025-08-26 - Last updated in NVD database

Technical Details for CVE-2025-26467

Vulnerability Analysis

The vulnerability arises from Cassandra's permission model around system resources. When an operator grants MODIFY ON ALL KEYSPACES to a role, that grant unintentionally extends to internal system keyspaces that store authentication and authorization metadata. An attacker holding this permission can modify entries that govern role membership and privileges, including the superuser flag.

Apache addressed this class of issue in CVE-2025-23015 across multiple release branches. However, the patch was applied incorrectly in version 4.0.16, leaving the 4.0 series exposed. Cassandra 4.0.17 contains the corrected fix.

Exploitation requires network access to the Cassandra cluster and valid credentials with MODIFY permission on all keyspaces. No user interaction is required, and the attacker fully compromises confidentiality, integrity, and availability of the database.

Root Cause

The root cause is improper enforcement of permission scope on system tables. Granting MODIFY ALL KEYSPACES should not implicitly authorize writes against internal authorization tables, but in Cassandra 4.0.16 the access control check fails to exclude system resources whose modification leads to privilege change. This matches the [CWE-267] pattern, where a privilege is defined to permit actions whose security implications exceed the intended scope.

Attack Vector

An authenticated attacker connects to the Cassandra cluster over its native protocol using credentials with MODIFY ON ALL KEYSPACES. The attacker issues Cassandra Query Language (CQL) statements that alter rows in system authorization keyspaces. By updating role metadata, the attacker grants their own account superuser status. The attacker then performs any administrative action, including reading, modifying, or deleting any data in any keyspace.

The vulnerability mechanism is documented in the Apache project advisory. See the Apache Mailing List Thread for the official disclosure and remediation guidance.

Detection Methods for CVE-2025-26467

Indicators of Compromise

• Unexpected changes to roles, role memberships, or the is_superuser attribute in system authorization tables
• CQL statements from non-administrative users targeting system_auth or other internal keyspaces
• New or modified superuser accounts appearing in system_auth.roles without an authorized administrative change
• Authentication events from accounts that recently gained elevated privileges followed by bulk data access

Detection Strategies

• Audit Cassandra logs for ALTER ROLE, GRANT, and UPDATE statements issued by accounts that should not modify role data
• Review which roles currently hold MODIFY ON ALL KEYSPACES and treat each as a potential privilege escalation path on 4.0.16
• Correlate CQL audit events with privilege changes to identify unauthorized escalation sequences
• Validate the running Cassandra version across all nodes and flag any node still on 4.0.16

Monitoring Recommendations

• Enable Cassandra audit logging and forward events to a centralized analytics platform for retention and search
• Alert on any write activity directed at system_auth keyspace from non-administrative principals
• Track changes to the superuser population in system_auth.roles on a continuous basis
• Monitor for anomalous query patterns from service accounts granted broad keyspace permissions

How to Mitigate CVE-2025-26467

Immediate Actions Required

• Upgrade Apache Cassandra 4.0.16 deployments to version 4.0.17, which contains the corrected fix
• Inventory all roles granted MODIFY ON ALL KEYSPACES and revoke the permission where not strictly required
• Audit system_auth.roles for unexpected superuser accounts and remove any that cannot be attributed to authorized changes
• Rotate credentials for any account that may have exercised elevated access while running 4.0.16

Patch Information

Apache Cassandra 4.0.17 fixes CVE-2025-26467 by correctly applying the access control logic introduced for CVE-2025-23015. Users running 3.0, 3.11, 4.1, or 5.0 series should follow the remediation guidance published for CVE-2025-23015. Patch details and download links are available in the Apache Mailing List Thread.

Workarounds

• Restrict the granting of MODIFY ON ALL KEYSPACES to administrative roles only; use keyspace-scoped grants for application service accounts
• Enforce least privilege by issuing MODIFY permissions only on specific keyspaces required by each role
• Enable and review CQL audit logging so unauthorized writes against authorization tables generate alerts
• Isolate Cassandra cluster network access so only trusted application hosts can authenticate to the cluster

# Review roles with broad MODIFY permission and revoke where unnecessary
cqlsh> LIST ALL PERMISSIONS OF '<role_name>';
cqlsh> REVOKE MODIFY ON ALL KEYSPACES FROM '<role_name>';
cqlsh> GRANT MODIFY ON KEYSPACE <specific_keyspace> TO '<role_name>';

# Identify superuser accounts for review
cqlsh> SELECT role, is_superuser FROM system_auth.roles;