CockroachDB diagnostics inherited the wrong redaction policy

A setting that permits an administrator to inspect configuration should not automatically permit sending the same values in diagnostic telemetry. CockroachDB advisory A-133479, published October 25, describes a bug in that boundary. Diagnostics reporting used user-configurable redaction paths and could include OIDC settings in payloads sent to Cockroach Labs or stored locally.

The sending condition combined diagnostics.reporting.enabled = true with server.redact_sensitive_settings.enabled = false. The advisory identifies those as the defaults. An affected deployment did not need to opt into an unusual debugging mode to meet the configuration condition. It also needed relevant values configured, since the disclosed fields concern OIDC authentication settings.

I value explicit security boundaries in database operation. Telemetry is useful evidence about a running system, but its representation needs its own rules for sensitive configuration. An administrator's ability to see a value locally does not establish that a diagnostic recipient needs the same value.

Client identifiers and secrets have different affected ranges

For versions 20.2 through 23.1 and 23.2.0, the advisory names server.oidc_authentication.client_id. For 23.2.1 and later affected lines, it also names server.oidc_authentication.client_secret. The distinction matters because identifying an affected version alone does not tell the reader whether this disclosure included the secret field.

The reported destination was a secure, non-public, restricted telemetry database at Cockroach Labs. The advisory says the received values have been deleted and that incoming copies will now be discarded. It does not describe a public credential listing or establish that an external attacker obtained the values. The stated problem is inappropriate inclusion and storage in diagnostic data.

Local copies are within scope too. A recipient-side discard rule concerns payloads received by Cockroach Labs. It cannot describe the contents of diagnostic material retained by the user. The advisory's reference to locally stored payloads therefore matters independently of the vendor's response at its own collection endpoint.

The payload contains a cluster ID but does not directly identify the customer or map that ID to the host cluster, according to the impact statement. That qualification should be preserved without treating it as evidence that the settings are harmless. The same advisory recommends credential rotation, including for an OIDC client secret when configured.

Interactive inspection and diagnostics need different rules

The 24.1 release notes introduced server.redact_sensitive_settings.enabled as a control on values shown through SHOW commands and other introspection interfaces. They state that users with MODIFYCLUSTERSETTING can view unredacted settings. That earlier description concerns configuration visibility within an administrative interface.

The October advisory identifies diagnostics using that user-configurable redaction path as the bug. A switch useful for authorized inspection became part of deciding whether sensitive values entered diagnostic reporting. Those contexts have different audiences and purposes. An administrator can need a value to configure authentication while a telemetry system needs only a safe representation of the configuration.

This explains why setting names alone are insufficient to judge a diagnostic payload. A field may be legitimate in the database configuration and useful to a privileged user, yet inappropriate for export. The code that constructs diagnostics needs to classify it for that destination. Reusing another interface's visibility choice can import assumptions that do not hold for telemetry.

I find the defaults particularly relevant here. A redaction flag being false is not evidence that an operator intended to export credentials. In the documented configuration, both conditions were ordinary defaults. The advisory consequently concerns what the product's diagnostic path chose to include under normal settings.

Mitigation changes future payloads

For older affected versions, the advisory recommends disabling diagnostic reporting. Its SQL command is explicit and changes the producer's behavior.

SET CLUSTER SETTING diagnostics.reporting.enabled = false;

For affected newer versions with the redaction control, enabling sensitive-setting redaction is an alternative. That retains diagnostic reporting while changing the visibility condition implicated in the bug.

SET CLUSTER SETTING server.redact_sensitive_settings.enabled = true;

These commands address future inclusion of the affected settings. They have a different purpose from rotating a credential whose previous value may already have been transmitted. The advisory recommends rotation as well when those settings contain values. Producer configuration and credential replacement therefore address different points in the disclosed sequence.

The vendor's deletion and discard statements address another point, the handling of data at its telemetry recipient. Those statements can limit continued storage there while an uncorrected producer still constructs an inappropriate payload. The advisory recommends changing the producer or taking the planned patch, so recipient filtering should not be presented as a complete local correction.

The announced patch versions are prospective

The statement section says the diagnostic redaction behavior will be corrected in 23.1.29, 23.2.14, 24.1.7, 24.2.5 and 24.3.0. On the advisory's publication date, these are the named repair targets. The post should not describe every listed version as already available merely because later documentation links to it.

There is also an inconsistency in the advisory's 24.1 mitigation range, which includes 24.1.7 while the repair list identifies that same version as fixed. The version should be interpreted using the explicit repair statement, rather than extending the vulnerable range beyond its stated fixed version. The configuration mitigations remain concrete actions for an affected unpatched deployment.

The advisory offers a cluster-specific review through the vendor security team for users who need to establish whether their values were received. That is separate from inferring exposure from configuration. A cluster with the affected defaults meets the sending condition, while a review of received data answers a more specific question about its history.

The distinction also limits the conclusions available from a repaired setting today. A current value shows current configuration. It cannot, by itself, establish what an earlier diagnostic payload contained before the setting changed. Historical disclosure and present producer behavior require different evidence.

The issue illustrates a specific separation that diagnostic systems need to preserve. A local introspection setting can control what an authorized administrator sees. Outbound diagnostics need an independent rule that excludes the affected authentication values even when that local inspection setting permits them to be shown.