CockroachDB's May advisory makes account restoration a security boundary

Restoring user accounts can change who controls a running database. Cockroach Labs' May 20 advisory S-26052016 discloses a flaw in RESTORE SYSTEM USERS that could let an authenticated user introduce unauthorized administrative accounts. The same advisory describes a separate SQL injection flaw that could execute certain statements with root-level privileges. Both cross the boundary between an authenticated user's assigned authority and the authority of a privileged database operation.

The disclosure identifies corrected releases across six branches. It recommends upgrading users of version 21.2 and later to an appropriate fixed version or a subsequent release. The important operational distinction is between the date of disclosure and the version already deployed. A cluster can have received a maintenance update containing the correction before the public advisory explains why that update matters.

I value CockroachDB's default serializable isolation and its explicit approach to distributed consistency. Those guarantees concern the ordering and agreement of database operations. Authorization has another responsibility, determining whose operations the database permits. A system can consistently execute an operation that its caller should never have been allowed to request, so a security assessment needs both kinds of reasoning.

The two flaws grant authority in different ways

The SQL injection description says an authenticated SQL user could execute certain statements with elevated root-level privileges. The advisory identifies potential unauthorized read and write access. It assigns a CVSS 3.1 base score of 7.6, classified as high severity. The published text does not name the vulnerable SQL feature or provide the statement construction responsible for the injection.

That limits the mechanism that can be stated with confidence. The disclosure establishes an injection path from an authenticated user's input to privileged SQL execution. It does not establish that every query interface is vulnerable, that ordinary parameter binding is defective, or that a particular application statement triggers the flaw. Those would require additional evidence beyond this advisory.

The restore flaw has a more clearly named operation. RESTORE SYSTEM USERS brings account and role information from a backup into a live cluster. The issue could introduce administrative accounts without the authorization required for that outcome. Its CVSS 3.1 base score is 7.8, also high severity. The administrative consequence follows from restoring identities and role information, rather than only restoring application rows.

These are separate attack results. In one, an existing session can cause privileged SQL execution. In the other, the live cluster can gain an unauthorized administrative identity through restoration. Correcting either alone would not establish that the other route is closed. The advisory says both are resolved in its listed patched versions.

Authentication does not grant administrative authority

CockroachDB's authorization documentation describes checking a user's and role's privileges for each statement. An authenticated connection establishes an identity, after which the operation still requires sufficient privileges. This is why the advisory's requirement for an authenticated user does not make the defect irrelevant to a deployment with intentionally restricted application accounts.

The same documentation defines a role as a group of users or other roles whose privileges can be managed together. A user may have direct or indirect membership. The built-in admin role grants privileges on all database objects across the cluster, and root belongs to it by default. Introducing an administrative account can therefore have implications well beyond the objects the original caller could access.

There is also a distinction between the admin role and the ability to administer a particular role through an admin option. They are not interchangeable. Membership in the cluster's administrative role carries a much broader meaning than permission to manage a specific role assignment. A review of account changes needs to preserve that distinction when identifying which restored identities have cluster-wide power.

Object ownership adds another source of authority. The documentation says an object's creator is normally its owner and has all privileges on it. Users that own objects cannot simply be dropped before ownership is transferred. Consequently, inspecting account names alone does not describe the resulting authorization state. Membership and ownership determine how an identity can affect stored objects.

These documented rules explain the seriousness of importing account state. A restore can introduce more than a login name and credential. It can introduce a relationship to roles that already carry broad privileges. The advisory does not enumerate every account field involved in the vulnerable operation, but its reference to user accounts and role information is enough to establish why restoration needs an authorization boundary.

Restore privileges already distinguish different jobs

The RESTORE reference documents a privilege model intended to avoid giving every recovery operator full administrative membership. A system-level RESTORE privilege permits cluster or database restoration, while a database-level restore privilege permits restoring schema objects into that database. Members of admin can perform these restore types without a separate grant.

The documentation recommends granting restore privileges as needed instead of broadly using administrative authority. It also says these grants do not cascade to lower objects in the schema tree. A system-level restore grant does not automatically give the corresponding table-restore capability. This is an example of why an operation's name alone is insufficient to infer what a user is allowed to do.

The distinction can be expressed with the documented forms below. They illustrate different scopes of delegation, using an existing role named recovery_operator and an existing database named application_data.

GRANT SYSTEM RESTORE TO recovery_operator;

GRANT RESTORE ON DATABASE application_data
TO recovery_operator;

These examples describe the ordinary restore privilege model. They are not a workaround for S-26052016 and do not establish the exact preconditions of the vulnerable system-user restore path. The advisory recommends a version upgrade and does not claim that selecting a particular grant configuration repairs either defect on an affected binary.

The restore reference also separates database authorization from access to backup storage. Some source operations require EXTERNALIOIMPLICITACCESS or administrative membership, including implicit cloud authentication. Explicitly supplied storage credentials have different requirements. A user who can access a backup location has not thereby received unrestricted authority to install its account state into a running cluster.

Managing the restore job has another documented permission check. Pausing, resuming or cancelling it requires administrative membership or CONTROLJOB. Viewing jobs can use VIEWJOB, with the reference describing additional qualifying roles. These controls support recovery operations without making observation and execution the same privilege. They also show why a role named for recovery needs an explicit definition of its assigned powers.

The fixed version belongs to the release branch

The advisory lists 26.1.2, 25.4.7, 25.2.16, 24.3.30, 24.1.27 and 23.2.30 as fixed versions. Each is a threshold within its corresponding branch. Comparing only the final patch number across different branches would be meaningless. Version 25.4.7 and version 24.3.30 are different maintenance lines, with different numbers needed to reach the correction.

The document recommends those releases or a later version. For a cluster already on a newer branch, its version must be evaluated in that branch's release history rather than by assuming that the absence of its exact number from this list makes it unpatched. Conversely, an older binary does not become safe because application roles were designed with narrow privileges. The defects concern the enforcement of those intended limits.

The disclosure is not a report that a particular installation has been exploited. It establishes possible unauthorized behavior on affected software. An incident assessment would need separate evidence about account changes or SQL activity. The public text does not supply a universal query that proves exploitation or rules it out, and a newly installed fix cannot retrospectively establish what happened before it was deployed.

Recovery validation includes the resulting identities

My preference is to define a successful recovery in terms of the database state an application is supposed to resume using. That includes the users and roles allowed to operate on the restored data. A recovery procedure that validates row counts while ignoring the resulting administrative memberships leaves an important part of that state unexplained.

The restore documentation provides granular delegation, and the advisory identifies a failure in enforcing the intended account-restoration boundary. Together they support a concrete separation of responsibilities. Access to backup storage, permission to run a restore and authority to introduce privileged identities are questions that need distinct answers in the recovery design. The patched versions restore the implementation boundary described by the advisory, while the intended account and role state remains part of what the operator must know about the recovered cluster.