CockroachDB Cloud repairs the SQL authority behind Developer access
An internal Console API gave Cloud Developer users SQL administrator-like access. The fix restricts the per-cluster SQL identities used by the Console.
A cloud role can look appropriately restricted while a service behind it uses a database identity with much broader authority. CockroachDB Cloud had that mismatch in an internal API used by selected Console pages. A user assigned the Developer role could invoke the API for any cluster in the same organization and perform SQL administrator-like operations, including reading and writing any table.
The January 18 advisory C20230118 says Cockroach Labs has deployed a fix to all Cloud organizations. It describes an organization-insider risk rather than an unauthenticated attack from outside the organization. Self-hosted CockroachDB deployments are explicitly outside the scope. For affected Cloud clusters, the advisory says the database version does not determine exposure.
I like CockroachDB's explicit consistency model and accept its consensus latency as a visible cost. That architectural preference is separate from the trust placed in a hosted control plane. A database can enforce SQL permissions correctly while an intermediary chooses an identity that grants its caller too much access.
The Console crossed two authorization systems
The affected API was not publicly documented. Selected Cloud Console pages used it internally to retrieve data by proxying to a cluster's DB Console. That proxy path connected organization-level access to database-level operations. The existence of a Developer role at the outer layer did not ensure a correspondingly restricted SQL identity at the inner layer.
The advisory describes the consequence in terms of both reads and writes. A Developer could access any table in a cluster through the vulnerable API path, despite not being intended to have data access outside an assigned scope. That is more extensive than seeing an extra administrative statistic. It changes the authority available to an authenticated organization member.
An undocumented API still processes requests under a permission model. The absence of public documentation does not make the caller more trustworthy, nor does it change the operations the proxy can perform. In this case, Cockroach Labs identifies the internal nature of the endpoint as context while locating the security problem in the authority it exposed.
The distinction also explains why this is not a database-version upgrade advisory. The fix belongs to the hosted Console and its underlying SQL-user mapping. Installing a different self-hosted database release would not describe the repair to this Cloud-only path. The service operator changed the permissions used on behalf of the Cloud user.
The repaired identity has a defined permission set
After the correction, Developer access to the relevant Console pages uses an underlying SQL user for each cluster with restricted permissions. The advisory names VIEWACTIVITYREDACTED, VIEWCLUSTERSETTING and CONTROLJOB, together with access to cluster-node metadata. This is the concrete replacement for the administrator-like access previously available through the path.
The role-option implementation in CockroachDB 22.2.0 provides supporting context for these names. It represents the activity-viewing, cluster-setting and job-control options separately. It also distinguishes VIEWACTIVITYREDACTED from VIEWACTIVITY, and VIEWCLUSTERSETTING from the option to modify cluster settings. These are individual capabilities that the database can represent, rather than a single all-or-nothing administrator flag. The implementation records those options in system.role_options and maps each option to its own update of that table. The selected identity can therefore carry a deliberately limited combination.
That source also documents the unredacted activity option as controlling DB Console endpoints and allowing unredacted node information. The distinction reinforces why selecting a redacted activity permission is a meaningful part of the corrected identity. A management interface can require operational visibility without requiring every data-viewing capability associated with a broader role.
The advisory preserves administrator-like SQL access for the Cloud Organization Admin role. It describes that role as intentionally highly privileged. The change therefore aligns the proxy's SQL identity with the outer role's intended authority, rather than removing all privileged operations from the Console.
Lost functionality can be the intended result
Cockroach Labs warns that some Developer users may lose access to functionality they previously used. The advisory treats that as an expected result of reducing permissions. Restoring the old access indiscriminately would risk recreating the authority mismatch that the service fix removes.
Where a user needs additional functionality, the advisory recommends direct cluster access using an SQL user assigned the required privileges. That includes direct SQL access or DB Console access through the Cloud Tools page. The important property is the specific SQL user and its permissions, rather than the convenience of the route used to open the interface.
This changes how administrators interpret an access regression after the fix. A formerly available action is not sufficient evidence that the Developer role should retain it. The required operation must be authorized under the intended database identity. The advisory's remedy supplies that route without giving every Developer the Organization Admin role.
My preference is for this separation to remain visible in hosted services. Organization membership answers who can use the control plane, while SQL privileges answer what the selected cluster identity may do. A proxy must preserve the restriction through that translation, including endpoints used only by the service's own pages.
Reported impact and available evidence differ
The advisory says Cockroach Labs discovered the issue while developing a related Console capability and performing threat modeling and testing. It reports no affected customers and no evidence of exploitation before patching. The company also says its product-usage analysis indicates the issue was not exploited in a Cloud organization.
Those are the vendor's findings, not a claim that every customer independently verified the same conclusion from exported evidence. The advisory says pertinent logs for this scenario cannot be shared. It separately recommends log export for Dedicated clusters and SQL audit logging on tables containing confidential data as general practices.
The deployed fix closes the described path by using a restricted per-cluster identity for Developer operations. Administrators still own assignment of organization roles and any direct SQL privileges they grant. The concrete boundary after remediation is that Console Developer access no longer supplies unrestricted table access through this internal proxy API.