You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Existence (reproduction withheld pending maintainer)
A datasource credential placed in a nested config position (not the top-level credential key) is accepted at the runtime admin door and then served in cleartext through the datasource read doors (GET /api/v1/datasources/:name and GET /api/v1/meta/datasource), with hasSecret:false / redactedConfigKeys:[]. The equivalent credential at the top-level key is correctly refused at publish and redacted on read — so the redactor is top-level-key-only and does not descend into nested config objects. Observed across all three replicas of a live multi-node deployment; the meta-registry entry propagates cluster-wide at create time.
Per the maintainer disclosure ruling (2026-08-18, #9387) and RUNNER protocol rule 2's carve-out, the reproduction, the exact nested position, and the request bodies are NOT published here or anywhere on GitHub. They are held in the QA runner session and available to the maintainer directly. Existence published, recipe withheld, is a complete and actionable report.
Independently reproduced twice by two separate QA agents (original run + a dedicated rule-7 verify-pass), each from its own fixtures, with the top-level position as the negative control (correctly refused). No cross-tenant read was involved — the exposure is on the authoring tenant's own read path. All planted secrets were scrubbed after each run (verified absent from every door on every replica).
Suggested direction
Make the read-side redactor (and the publish-time inline-credential refusal) recurse into nested config objects, so the nested position is treated identically to the top-level key it mirrors. A second-order cleanup gap was also seen: datasource DELETE clears the admin/detail-door registry but does not evict the /api/v1/meta/datasource in-memory metadata registry cluster-wide (create broadcasts, delete does not mirror), which prolonged the exposure until the entry was scrubbed.
Existence (reproduction withheld pending maintainer)
A datasource credential placed in a nested config position (not the top-level credential key) is accepted at the runtime admin door and then served in cleartext through the datasource read doors (
GET /api/v1/datasources/:nameandGET /api/v1/meta/datasource), withhasSecret:false/redactedConfigKeys:[]. The equivalent credential at the top-level key is correctly refused at publish and redacted on read — so the redactor is top-level-key-only and does not descend into nested config objects. Observed across all three replicas of a live multi-node deployment; the meta-registry entry propagates cluster-wide at create time.Per the maintainer disclosure ruling (2026-08-18, #9387) and RUNNER protocol rule 2's carve-out, the reproduction, the exact nested position, and the request bodies are NOT published here or anywhere on GitHub. They are held in the QA runner session and available to the maintainer directly. Existence published, recipe withheld, is a complete and actionable report.
Why this is distinct from prior art
config.options.auth.passwordis a fourth spelling of an inline credential — authorable, persisted cleartext, unredacted, and read by the client #9040 / mongo passthrough secrets with no binder slot (proxyPassword, TLS key material, passphrases) stay writable as at-rest cleartext — redacted on read since #9040, but the store-side half has no door #9124 established read-side redaction for mongo passthrough secrets; mongo passthrough secrets with no binder slot (proxyPassword, TLS key material, passphrases) stay writable as at-rest cleartext — redacted on read since #9040, but the store-side half has no door #9124 explicitly notes read is redacted since mongoconfig.options.auth.passwordis a fourth spelling of an inline credential — authorable, persisted cleartext, unredacted, and read by the client #9040 and only the store-side half was open. This finding is that read redaction does not hold for the nested position — a live gap on the read boundary, not the at-rest half.sys_metadata.metadatais a general cleartext sink: any authored artefact whose schema permits an inline credential lands it there (datasourceconfig.password, connectorauthentication) #7990 flagssys_metadata.metadataas a general cleartext sink for inline credentials in authored artefacts; this is the datasource-admin-door + read-door manifestation, where the refusal/redaction that works for the top-level key is absent for the nested one.Verification
Independently reproduced twice by two separate QA agents (original run + a dedicated rule-7 verify-pass), each from its own fixtures, with the top-level position as the negative control (correctly refused). No cross-tenant read was involved — the exposure is on the authoring tenant's own read path. All planted secrets were scrubbed after each run (verified absent from every door on every replica).
Suggested direction
Make the read-side redactor (and the publish-time inline-credential refusal) recurse into nested config objects, so the nested position is treated identically to the top-level key it mirrors. A second-order cleanup gap was also seen: datasource
DELETEclears the admin/detail-door registry but does not evict the/api/v1/meta/datasourcein-memory metadata registry cluster-wide (create broadcasts, delete does not mirror), which prolonged the exposure until the entry was scrubbed.QA-source: #13404 · integration-system.datasource-credential-refusal-matrix · clauses 1,3