Skip to main content
← Back to list
01Issue
BugShippedSwamp CLI
Assigneesstack72

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` to

So 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 bug and swamp issue edit
  • swamp-club#1241 — issue submission redactor silently corrupts report bodies
  • swamp-club#1302 — the report whose submission surfaced this
02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 2 MOREREVIEW+ 4 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

7/20/2026, 11:45:48 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack727/20/2026, 10:07:58 PM
Editable. Press Enter to edit.

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:

  1. 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.

  2. 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.

stack72 commented 7/20/2026, 11:45:55 PM

Thanks @magistr for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.