CockroachDB restricts privileged HTTP endpoints

A database monitoring interface can expose more than aggregate performance counters. CockroachDB's January 22 advisory A-42567 describes privileged HTTP endpoints accepting unauthenticated requests and some Admin UI pages running with root privileges even for logged-in non-admin users. Because those operations used the database root identity, they could expose privileged data and sometimes modify stored data or files in database directories.

The repair has two parts. Privileged endpoints require valid authentication as an admin user, and Admin UI pages use the logged-in user's credentials. That distinction matters because a login check alone cannot establish that a particular user should receive every result available to root. Authentication establishes identity, while authorization determines what the operation may do with that identity.

I accept the latency cost of CockroachDB's distributed consistency model because the tradeoff is explicit. Administrative access needs equally explicit rules. Consensus about stored data does not establish who should be allowed to retrieve it through an HTTP request. A distributed SQL system still needs each management operation to enforce the intended user boundary.

The affected interface is broader than a dashboard

The 19.2.2 security notes as published by January 22 enumerate the affected endpoints. Event records can reveal usernames, object names and privilege mappings. Session information can reveal cleartext SQL queries. Range and table statistics can disclose stored primary-key values. Administrative operations such as draining a node can affect availability.

These examples explain why calling the interface monitoring does not establish that it is harmless to expose. An event log may contain database names that an ordinary user cannot otherwise inspect. A query string may contain application data. A management request can change the cluster's behaviour even if it does not resemble an INSERT or DELETE sent through a SQL connection.

The notes also distinguish endpoints governed by server.remote_debugging.mode. With its default setting, those special endpoints accept clients only from the node's own machine. That restriction affects exposure for those endpoints, but it does not describe every affected HTTP operation. Assessing the HTTP listener as a whole requires considering which requests are reachable under the actual configuration.

Listener configuration defines network exposure

The contemporaneous node-start reference defines http-addr as the address and port for Admin UI HTTP requests. Its default uses the address portion of listen-addr and port 8080. The SQL and inter-node listener configuration therefore does not by itself describe the administrative HTTP exposure.

For a node whose HTTP interface should be reachable only locally, the relevant argument can explicitly select loopback:

--http-addr=127.0.0.1:8080

This is an argument fragment for an otherwise configured node, not a complete startup command. It illustrates the listener choice. A deployment needing remote administration may require a different address and network policy. The advisory's mitigation is to firewall access to the HTTP endpoint, so the relevant network controls need to cover that listener rather than only application SQL connections.

The node-start reference also explains that insecure mode removes network authentication and encryption. That mode has a broader trust assumption than a secure cluster. The advisory concerns unexpected privileged HTTP access, which should not be confused with intentionally operating a cluster under the documented insecure-mode assumptions.

Certificates and application identity answer different questions

The authentication documentation available at disclosure distinguishes node authentication from client authentication. Secure nodes use certificates, and clients can authenticate using supported credentials. A client using password authentication still needs a trusted CA certificate to validate the node certificate.

Those transport relationships do not authorize an HTTP handler to execute every request as root. Validating the server establishes which server received the connection. Establishing a user's session gives the application a user identity. The operation still needs to use that identity and decide whether the requested information or action is permitted.

This is why the rendering change is substantive. A server can have an encrypted connection and a logged-in user while still using an incorrect privileged identity internally. The advisory explicitly identifies that second condition on some Admin UI pages. Encrypting the response would protect its transmission but would not make its contents appropriate for the recipient.

Updating changes automation's access contract

The advisory names fixed revisions 2.1.10, 19.1.6 and 19.2.2 and invites users to upgrade immediately. Its impact section includes deployments through 2.1.9, 19.1.5 and 19.2.1 when the HTTP port is exposed to unprivileged networks. Older branches also contain the issue, although their HTTP endpoint was not advertised as safe on unprivileged networks.

The security notes say monitoring automation using protected endpoints must authenticate with an admin HTTP session token. A collector that previously worked anonymously can consequently fail after the repair. That failure reflects a deliberate access change. Giving the automation credentials requires a decision about the privileges of the administrative data it collects.

The Admin UI access documentation describes access through any node and password login for users of secure clusters. It also notes that login information lives in a replicated system table. Administrative access is therefore a database-backed facility with its own dependencies, rather than an independent proof that the cluster is healthy.

That interface includes pages for databases, statements and jobs, with advanced debugging reports available separately. Their subjects require different levels of interpretation. A failed login is an access result, while an unavailable job page can concern authorization or the page's operation. Keeping those observations separate helps an administrator report the actual failing request without inferring a database failure from a missing screen.

I regard the corrected behaviour as a necessary distinction between operational visibility and unrestricted database authority. The recovery task for an affected installation includes updating the nodes and identifying which tools depended on anonymous privileged requests. Each tool then needs an intentional access path appropriate to the information it requests.