Cassandra restricts archive commands supplied through JMX

A log archive command executes with the authority of the process that runs it. If a management caller can choose that command, permission to configure logging can become permission to execute a program on the host. CVE-2023-30601, published on May 30, identifies this privilege escalation in Cassandra's full-query and audit logging configuration.

The affected versions are 4.0.0 through 4.0.9 and 4.1.0 through 4.1.1. The advisory requires JMX or nodetool access for exploitation. Cassandra 4.0.10 and 4.1.2 add the allow_nodetool_archive_command setting, and the mitigation is to leave that setting false. The vulnerability is consequently a management-authority problem with a specific route to host execution.

I find Cassandra compelling for applications that need its distributed availability. That does not make every management capability interchangeable. Permission to inspect or configure a database needs a deliberate relationship to permission to run commands as its operating-system account.

The archive command is executable configuration

The 4.1.2 configuration file describes an archive command as a script invocation in which %path is replaced with the file being rolled. This is a useful facility for moving or processing completed log files. It also means the configured value identifies an action for the host to execute.

A logging option may look like ordinary operational metadata when viewed beside a roll cycle or queue size. Its authority is different. A size setting constrains resource use, while an archive command selects executable behavior. The security review has to follow what the value does after configuration, rather than classify every logging field alike.

The advisory says a user with JMX access can run arbitrary commands as the user running Cassandra. It does not say that ordinary CQL access alone is sufficient. Keeping that precondition visible is essential when identifying the relevant access path and deciding which accounts need review.

The operating-system identity also limits the claim. The command runs as Cassandra's user, not automatically as an unrelated privileged account. That user still has access to the files and resources its service requires, so crossing into its authority is consequential even without claiming additional host privileges.

The fix checks caller-supplied commands

The 4.1.2 StorageService implementation shows how the new gate works. When enabling audit logging, it reads the configured audit options. If a caller supplies an archive command and allow_nodetool_archive_command is false, the method throws a configuration exception.

The condition tests whether a command was supplied through that management operation. It does not remove archive support from Cassandra. A command established in the node's configuration belongs to a different administrative route. The change makes the ability to override executable behavior through nodetool explicit.

The full-query logger has a corresponding check. It obtains its configured logging options, rejects a supplied archive command when the gate is false, and otherwise selects between the supplied value and the configured value. The parallel behavior matters because the advisory covers both logging facilities.

These checks occur before the logger is enabled with the requested options. The implementation therefore rejects the command at the configuration boundary. It does not depend on inspecting an attempted command after an external archiver has begun processing a file.

A gate is appropriate here because arbitrary archive scripts are an intended capability for a trusted configuration owner. The problem is allowing another form of administrative access to select them without an explicit decision that it should have that authority.

The new default belongs to each logging facility

For full-query logging, the relevant part of cassandra.yaml can be expressed as follows.

full_query_logging_options:
  allow_nodetool_archive_command: false

This fragment concerns the permission to supply an archive command through nodetool. It does not by itself enable full-query logging, select a log directory, or define an archive script. Those settings have their own meanings and should not be inferred from the permission flag.

Audit logging has its own audit_logging_options section and the same gate name. The code's exception names the audit configuration key when it rejects a supplied command. An operator reviewing the mitigation needs to consider which logging facility the management call can reach.

The configuration comments are explicit about the consequence of setting the flag true. Doing so allows anyone with JMX or nodetool access to run local shell commands as the Cassandra user. That is a statement of delegated authority, not a harmless compatibility toggle.

My preference is to make that delegation visible in the node's configuration. A deployment may have a legitimate archive workflow, but preserving a workflow does not require treating every management caller as its owner. The default provides a way to retain configured archiving while withholding caller-selected commands.

The distinction between a configured command and a supplied override also matters when interpreting a failed request. Rejection does not establish that the database has no archive command at all. The full-query path can use the command already present in its configuration when no override arrives. An operator can consequently investigate a rejected management request without assuming that the configured archival process must be disabled. The policy controls who selects the executable action through this interface, while the existing configuration still describes the node's intended logging behavior.

Access restrictions remain part of the mitigation

The Apache advisory recommends disabling nodetool and JMX access for untrusted users as a workaround. Its long-term mitigation combines an upgrade with leaving the new property false. The two measures address different parts of the route.

Restricting management access reduces who can reach the affected operation. The code change prevents a caller who reaches it from supplying an archive command unless the node explicitly permits that behavior. Upgrading while enabling the permission restores the very authority that the default is intended to withhold.

This does not imply that all other JMX operations are suitable for every user. The advisory addresses this command-execution route. A deployment still needs an access model for its management interface, but the source does not justify turning this disclosure into a claim about every available management method.

It is also inaccurate to describe the fix as sanitizing a command string. The visible implementation checks whether an override is allowed. That distinction matters because a system designed to execute a chosen script cannot generally infer whether the script is appropriate for a particular operational role.

Read the advisory as a capability chain

The relevant sequence begins with management access. A caller uses a logging enablement operation and supplies an archive command. The logging machinery can then execute that command with the Cassandra process identity. The new gate interrupts the sequence at the point where the caller attempts to choose executable behavior.

This explanation helps separate the vulnerability from unrelated application queries. Audit and full-query logs describe database activity, but the flaw lies in management configuration of those logs. A statement appearing in a query log is not itself evidence that the statement can select an archive program.

The distinction also clarifies what to look for in a configuration review. A deployed version establishes whether the new check exists. The logging settings establish whether caller-selected commands remain allowed. The management access policy establishes which users could invoke the operation.

No performance result or topology condition is needed for the advisory's mechanism. The relevant resource is host command execution, and the relevant authority is the account under which the database runs. This makes the problem applicable to the administrative design even though Cassandra's primary purpose is distributed data storage.

Publication and release evidence

The CVE record's publication date is May 30. Apache's linked mailing-list advisory is dated May 29 and gives the same affected ranges and mitigation. The dates describe related public records, so using the CVE publication date allows the post to discuss both without introducing later information.

The advisory credits Gal Elbaz at Oligo with finding the issue and identifies CASSANDRA-18550 as its tracker. Those references provide a path to the project's own account of the defect. They are more appropriate evidence than inferring exposure from a generic label such as remote code execution.

For an existing deployment, the concrete behavior after the fix is straightforward. A management request that supplies an archive command fails unless the corresponding configuration explicitly grants that ability. Configured log archiving remains an administrative choice, and the Cassandra service account remains the identity under which that executable work runs.