> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# RabbitMQ amqp091-go: Plaintext Credential Exposure via Exported PLAIN Authentication Struct Fields
- URL: https://f4n6.co.uk/security-feed/rabbitmq-amqp091-go-plaintext-credential-exposure-via-exported-plain-authentication-struct-fields/
- Published: 2026-09-17T20:10:29.000Z
- Updated: 2026-09-17T20:10:29.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

The Go AMQP 0-9-1 client library used with RabbitMQ (amqp091-go) retains the PLAIN authentication username and password in plaintext, in exported struct fields, on the `*Connection` object for the entire lifetime of the connection. After the handshake completes, `Connection.Config.SASL` still holds the `PlainAuth` struct, whose `Username` and `Password` fields are publicly readable. Any reflective logger, APM agent, panic handler, or dependency that traverses or serialises the connection object can therefore read and emit the raw broker credentials into logs, telemetry, or stdout. There is no attacker-controlled remote vector here: the exposure is to anyone who can read the resulting log or telemetry output, which in most estates includes a far wider population than the credential's intended holders. No verified reference data resolved for this item, so no CVSS score, severity rating, or CISA-KEV exploitation state can be stated; the GitHub advisory record is the sole source and this advisory is single-sourced throughout.

## 2\. Regulatory framing

No specific DORA/NIS2 article is directly engaged by this item. The flaw is a library-level information exposure with no incident, no third-party provider relationship, and no exploit in evidence; the generic fact that a patch or code change may be needed does not by itself trigger any article in the regulatory reference.

## 3\. Technical analysis & attack chain

The vulnerability is a design flaw in how the client stores authentication state, not a memory-safety bug or a remotely reachable parsing flaw. In `auth.go` (lines 21-23 of the advisory's citation) the PLAIN authenticator is declared as:

```go
type PlainAuth struct {
    Username string
    Password string  // exported plaintext
}

```

When an application dials a broker, the `PlainAuth` instance is embedded in the connection configuration, `Connection.Config`, and the `Config.SASL` field holds the `Authentication` implementation used for the session. The struct persists in memory unchanged after the handshake finishes and for as long as the connection stays open. Because both fields are exported (capitalised) Go string fields, any code holding the `*Connection` pointer can read the password directly, and any code using the `reflect` package can walk the nested structure and pull the value from `Connection.Config.SASL.(*PlainAuth).Password` without restriction.

The exposure paths the advisory names are all read-side, not write-side:

- Reflective loggers: structured logging frameworks that serialise nested configuration structs to JSON or logfmt will emit the password if the connection object is in scope.
- APM and performance agents: telemetry tools that capture state snapshots of live objects can ingest the credential into their backends.
- Debugging and panic handlers: goroutine dumps and deep-struct printers triggered on errors or signals will print the field values.

The advisory describes a three-step exposure chain, which is a plausible operational sequence rather than an observed intrusion:

1. An operator configures a reflective logger or third-party APM package to capture system state, including the active AMQP `*Connection` object.
2. The inspection engine uses Go's `reflect` package to walk the struct hierarchy and reads the string value from `Connection.Config.SASL.(*PlainAuth).Password`.
3. The plaintext password is written to standard system logs, which are scraped into shared log aggregators, making production broker credentials readable by unprivileged operators or anyone with access to log archives.

Two caveats on scope. First, the advisory does not name affected amqp091-go versions, a patched version, or a fix, and no CVE record with a CVSS score was resolved in the verified reference data; treat the version and remediation picture as unknown until the upstream repository confirms it. Second, the advisory explicitly frames this as a credential-harvesting vector in multi-tenant environments or via secondary log exposure; it does not describe remote code execution, and no attacker activity, campaign, or attribution is claimed. The related advisory GHSA-465g-fh3v-9jw4 (query-parameter injection in the same library's URI handling, allowing TLS path parameters to hijack connection configuration on re-parse) is a separate flaw in the same package; it is context for the library's overall hygiene, not part of this vulnerability's mechanism.

## 4\. Mitigation & containment

No vendor fix is identified in the source material, so the actions below are exposure reduction and detection, not a patch. Confirm current guidance directly against the upstream amqp091-go repository before acting on version changes.

### P1, within 24 hours

- Inventory Go services that connect to RabbitMQ using PLAIN authentication via amqp091-go. For each, determine whether the `*Connection` object, or any struct containing it, is passed to a logger, APM agent, or panic/dump handler.
- Search existing log archives, SIEM ingest, and APM backends for the RabbitMQ credentials currently in use. If a password appears in any log store, treat it as disclosed and rotate it at the broker.
- Add the connection object to redaction or deny lists in structured logging frameworks where the framework supports field-level exclusion; where it does not, stop logging the object entirely.

### P2, within 72 hours

- Review APM and telemetry configurations for state-snapshot or object-capture features that could serialise live connection structs, and disable those features for the affected services.
- Review panic handlers, goroutine dump libraries, and debug endpoints for anything that prints deep struct hierarchies containing the connection, and restrict or remove them in production builds.
- Where the architecture allows, prefer an authentication mechanism that does not leave a reusable plaintext secret in the connection config, or supply credentials through a path that the client does not retain post-handshake; validate the exact options against the current library source before committing to an approach.

### P3, within 7 days

- Establish a control that scans log pipelines and aggregators for known broker credential strings, so future leaks of this class are caught at ingest rather than at audit.
- Track the upstream advisory (GHSA-27gv-rfvv-22mv) for a published fix and affected version range, and schedule the upgrade when it lands.
- If the related URI-handling flaw (GHSA-465g-fh3v-9jw4) is in scope for the same services, review how TLS certificate and key paths are sourced, since that flaw allows path-delimiter characters to inject connection parameters on re-parse.

## 5\. Indicators of compromise

No indicators of compromise available in the source material. This is a library design flaw with no attacker artefacts, malware, or observed intrusions in the source; there are no hashes, domains, IPs, or behavioural patterns to pivot on.

## 6\. Detection

Insufficient indicators to author detection rules. The source contains no strings, file paths, registry keys, command lines, or network signatures belonging to a threat actor; the struct definition and field names are library source code, not attack artefacts, and a rule matching them would fire on the client library itself rather than on any malicious activity. Detection effort belongs at the log-ingest layer: alert on any log event whose payload matches the current RabbitMQ credential strings, per the P3 control in section 4.

## 7\. Sources

- GitHub Security Advisories, RabbitMQ amqp091-go: Plaintext Credential Exposure via Exported PLAIN Authentication Struct Fields, https://github.com/advisories/GHSA-27gv-rfvv-22mv, 2026-09-17
- GitHub Advisory Database, CVE-2026-77407, https://github.com/advisories/GHSA-27gv-rfvv-22mv, 2026-09-17
- GitHub Security Advisories, RabbitMQ amqp091-go: Connection Configuration Overwrite via Unsanitized TLS Path Parameter Injection, https://github.com/advisories/GHSA-465g-fh3v-9jw4, related context, date not stated

## 8\. Adverse Trace position

We assess this as a credential-exposure flaw with real operational impact in any estate where Go services log or telemetry-capture live objects, but not as an urgent remote vulnerability: no CVSS score, severity, or CISA-KEV state could be verified, no affected version range or fix is published, and the entire technical picture rests on a single GitHub advisory, so clients should verify against the upstream repository before enforcing changes. The practical risk for EMEA financial services is broker credentials landing in log aggregators and SIEM platforms with broad read access, which converts a library hygiene issue into an insider and log-archive exposure problem; the P1 log-archive sweep and credential rotation is the action that reduces risk fastest. We will monitor the upstream advisory and the amqp091-go repository for a published fix and affected versions, and we will update this note if a CVSS score, a patched release, or evidence of active exploitation emerges.

---

[Read the original source →](https://github.com/advisories/GHSA-27gv-rfvv-22mv?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*