Relationships
#1303 Issue redactor treats the MongoDB authSource parameter as a secret, corrupting reproduction steps
Opened by magistr · 7/20/2026· Shipped 7/20/2026
Summary
The issue-submission redactor treats the MongoDB connection-string parameter
authSource as a secret and replaces its value with [REDACTED-SECRET-N]. That
parameter names the authentication database (conventionally admin) — it is
not a credential. The result is that any bug report containing a realistic
MongoDB URI has its reproduction steps silently rewritten into something that
will not work when copied.
This appears to be a recurrence of the class of problem in swamp-club#1241 ("Issue submission redactor silently corrupts report bodies"), which is marked shipped.
What happened
Filing swamp-club#1302 (a datastore config bug) the submission reported:
Redacted 2 secrets from issue content.Both "secrets" were the same false positive, in the reproduction command and in the workaround YAML. The URI
mongodb://HOST:27017/?replicaSet=rs0&authSource=[REDACTED-SECRET-1]became
mongodb://HOST:27017/?replicaSet=rs0&authSource=[REDACTED-SECRET-2]No password was present anywhere in the body — the report deliberately used
passwordEnv and a placeholder host.
It matches on the parameter name, not the value
On re-submission the value was changed to the obvious non-secret placeholder
AUTHDB, and it was redacted again:
"original": "...&authSource=[REDACTED-SECRET-3]",\"username\":\"swamp\"...",
"redacted": "...&authSource=[REDACTED-SECRET-4]",\"username\":\"swamp\"..."A third occurrence was then matched inside the prose sentence describing the redaction, producing the self-referential output:
it matched `authSource=[REDACTED-SECRET-5]` in the Mongo URI and rewrote `admin` toSo the rule keys off authSource= and redacts whatever follows, regardless of
whether it could plausibly be a secret. The only way to file the report intact
was to delete the parameter from the URI entirely.
Note the bare token authSource (without =) is not matched — only the
assignment form.
Impact
- Reproduction steps in submitted issues become subtly wrong. A maintainer copying the repro gets a URI that fails to authenticate, and the failure looks like a different problem than the one being reported.
- The corruption is applied at submit time, so the reporter sees their correct text locally and a wrong version is stored.
- It is self-perpetuating: you cannot describe the false positive in the report without triggering it.
Suggested fix
Exclude connection-string parameters that are known not to be credentials —
authSource, replicaSet, authMechanism, readPreference, appName,
tls/ssl, retryWrites, w, readConcernLevel — from the URI credential
matcher. The genuine credential positions in a MongoDB URI are the userinfo
segment (mongodb://[REDACTED-USER]:***@[HOST-1] and password=`; matching those and leaving
the rest alone would avoid this whole class of false positive.
More generally, a redactor that rewrites report bodies should probably show the reporter a diff and let them confirm, rather than silently substituting — that would have caught all three of these instantly.
Environment
- swamp:
20260720.142822.0-sha.0caa5556 - OS: darwin (aarch64)
- Observed on:
swamp issue bugandswamp issue edit
Related
- swamp-club#1241 — issue submission redactor silently corrupts report bodies
- swamp-club#1302 — the report whose submission surfaced this
Shipped
Click a lifecycle step above to view its details.
magistr commented 7/20/2026, 9:50:27 PM
Heads-up for whoever picks this up: the body above was itself rewritten by the
redactor on submission, which makes some of the evidence hard to read. The
submit response reported Redacted 6 secrets, 1 hostname.
Every example I wrote to illustrate the false positive was redacted, including the "original" side of the before/after pairs — so the quoted evidence now shows placeholders on both sides and reads as though the values were always placeholders. They were not; each was a plain non-secret value.
Two further effects visible in the stored body:
The parameter value I replaced with the literal placeholder
AUTHDB(chosen precisely because nothing about it resembles a credential) was redacted anyway. That is the core evidence that the matcher keys on the parameter name rather than the value.In the "Suggested fix" section I referenced the userinfo portion of a connection string — the generic
scheme://[REDACTED-USER]:***@[HOST-1] form, with those literal placeholder words, not real values. It was rewritten to[REDACTED-USER]:***@[HOST-1]` and lost its closing backtick and parenthesis, corrupting the markdown. So the redactor also mangles documentation-style references to URI syntax, and can leave unbalanced markup behind.
The substance of the report stands: the matcher fires on the auth-database query
parameter in a MongoDB connection string, whose value is a database name
(conventionally admin), not a credential.
If it helps reproduce, the trigger is the assignment form of that parameter. The
bare parameter name on its own is not matched — only when followed by = and a
value. Filing swamp-club#1302 required deleting the parameter from the URI
entirely to get an uncorrupted body stored.
Sign in to post a ripple.