CVE-2026-104055

Executive Summary

CVE-2026-104055 is an information disclosure vulnerability in Canonical's postgresql-operator charm, in which the bundled Prometheus postgres_exporter writes the PostgreSQL monitoring user's password in cleartext to its logs whenever a database connection error occurs. The impacted component is the operator charm and any deployment where exporter logs are persisted, aggregated, or readable by a broad set of principals. Any actor with read access to those logs can recover the credential and obtain read-only pg_monitor access to the PostgreSQL instance, enabling reconnaissance of database activity, configuration, and performance telemetry.

Technical Analysis

The postgresql-operator charm deploys and manages a PostgreSQL cluster and co-locates a Prometheus postgres_exporter process. The exporter authenticates to PostgreSQL as a dedicated monitoring user, whose primary function is to expose database metrics to Prometheus. The vulnerability resides in the exporter's error-handling path: when a database connection attempt fails, the exporter emits a log entry that contains the monitoring user's password in cleartext rather than redacting or masking the credential field.

This is a classic CWE-532 (Insertion of Sensitive Information into Log File) issue. The root cause is a failure to sanitize credential-bearing connection parameters before they are serialized into log output. The password becomes part of the log record and inherits whatever access controls, retention policies, and transport protections apply to that log stream — which in most observability stacks is a substantially weaker set of controls than those protecting the credential store itself.

The attack surface is therefore any channel through which the exporter's stdout/stderr or logfile can be read: local filesystem access on the node running the charm, container runtime logs (kubectl logs, docker logs, journalctl on the unit), centralized log aggregation platforms (Loki, Elasticsearch, Splunk), monitoring dashboards, and backup or archive snapshots of those systems. The trigger condition — a database connection error — is not exotic; it occurs during restarts, failovers, network partitions, credential rotation windows, and PostgreSQL outages, which means the cleartext disclosure is likely to recur in normal operational conditions rather than only under adversarial pressure.

Notably, the exporter only requires read-only access as the monitoring user. The credential does not confer write, DDL, or superuser privileges. The pg_monitor role is a predefined PostgreSQL role intended to grant access to monitoring views and functions such as pg_stat_* views, pg_stat_activity, and related statistics functions. An attacker with this credential obtains visibility, not control — but that visibility is itself sensitive and is frequently a stepping stone for further targeting.

The NVD description does not specify the exact code path, library, or function responsible for the log emission. That level of implementation detail is not reproduced here; the vulnerability class and data flow are sufficient to characterize exploitation and detection. There is no public proof-of-concept, no Nuclei template, and no tracked exploit code as of this report.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class and the documented mechanism.

1. Reconnaissance / target identification. An attacker enumerating a Kubernetes or Juju-managed environment identifies units running the postgresql-operator charm and the associated postgres_exporter workload. Exposure of exporter logs depends on the environment's logging configuration. In tightly scoped environments, an attacker must already hold some level of access to the cluster (a low-privileged namespace user, a node-level account, or read access to a logging backend). In lax environments, exporter output may be shipped to a shared observability stack reachable by a much broader population.

2. Triggering the disclosure condition. The cleartext password is written whenever the exporter encounters a database connection error. The attacker does not necessarily need to induce this condition; it occurs organically during operational events. If induction is feasible and desirable (for example, if the attacker can disrupt connectivity between the exporter and PostgreSQL, or wait for an operator-initiated restart or failover), the attacker accelerates the appearance of the credential in the log. Where logs are aggregated, the attacker simply monitors the log stream for connection-error entries coincident with credential material.

3. Credential recovery. The attacker reads the log entry emitted on connection failure. The password appears in cleartext, requiring no decryption, decoding, or brute force. Successful recovery yields the monitoring user's password. There is no meaningful exploitation primitive beyond log access plus the natural occurrence of a connection error.

4. Post-exploitation impact. With the recovered credential, the attacker connects to PostgreSQL as the monitoring user and obtains read-only pg_monitor access. This grants visibility into server activity, session metadata, statistics, and configuration exposed through monitoring views and functions. The attacker cannot modify data or schema with this credential. The principal risk is intelligence gathering: enumeration of live sessions and query patterns, identification of other database consumers, mapping of application behavior, and discovery of sensitive operational context. The credential also constitutes a reusable persistent access path until rotated, and because it is a service account, rotation may be disruptive and therefore delayed by operators.

The disclosed password is also a potential pivot enabler if the monitoring user has been misconfigured beyond its intended scope, though the NVD description describes the intended grant as read-only pg_monitor. No elevation beyond that grant should be assumed based on the available data.

Impact Assessment

The CVSS base score is not available from the data provided (NVD reports N/A). For this report, the vector has been derived from the vulnerability class and the documented impact: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N.

• Attack Vector (Local): Exploitation requires access to exporter logs, which is a local or privileged-reachability condition rather than a network-reachable flaw in the exporter itself.
• Attack Complexity (Low): The disclosure occurs on connection errors, a routine operational event. No specialized timing or race condition is required.
• Privileges Required (Low): The attacker needs some read access to the log stream, which in most environments is granted to a substantial population, though not to unauthenticated parties.
• User Interaction (None): No user action is required beyond the natural occurrence of a connection error.
• Scope (Unchanged): The vulnerable component (exporter) and impacted component (PostgreSQL credential) are within the same security authority.
• Confidentiality (High): A credential is fully exposed in cleartext.
• Integrity / Availability (None): The recovered credential grants only read-only monitoring access; no data or availability impact follows from its use.

Business impact: The primary consequences are credential compromise of a privileged-but-read-only service account, exposure of database activity telemetry, and secondary risks including targeted social engineering or further reconnaissance based on observed database consumers. Regulatory implications may arise where the exposed telemetry or the credential itself is subject to data protection or auditing regimes, particularly in environments where pg_stat_activity can reveal query text or session metadata.

Blast radius: Limited to the PostgreSQL clusters managed by the affected charm in deployments where the exporter logs are readable and connection errors occur. The read-only nature of the credential caps direct integrity and availability impact. However, because logs are frequently centralized, a single compromised logging platform can yield monitoring credentials for many deployments simultaneously, which materially broadens the practical blast radius in large estates.

Detection Guidance

Sigma Rule

title: PostgreSQL Exporter Credential Disclosure in Logs
id: 7c1e9a2b-4f3d-4a1c-9b7e-cve2026104055
status: experimental
description: Detects cleartext PostgreSQL monitoring user password exposure in postgres_exporter logs following connection errors.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-104055
author: valtersit.com
date: 2026/01/01
logsource:
  product: linux
  service: application
detection:
  selection_error:
    - 'postgres_exporter'
  selection_conn_error:
    - 'connection error'
    - 'connect: connection refused'
    - 'failed to connect'
    - 'connection failed'
  selection_cred_pattern:
    - 'password='
    - 'password:'
    - 'user=monitoring'
  condition: selection_error and selection_conn_error and selection_cred_pattern
falsepositives:
  - Legitimate troubleshooting sessions that intentionally log sanitized credential placeholders (verify pattern excludes masked values)
level: high
tags:
  - attack.credential_access
  - attack.t1552

Note: This rule is heuristic. Tune the credential-pattern selection against your environment's actual log format, and whitelist any known-redacted forms.

YARA Rule

rule CVE_2026_104055_postgres_exporter_credential_leak
{
    meta:
        description = "Detects cleartext PostgreSQL monitoring user password in postgres_exporter logs"
        author = "valtersit.com"
        reference = "CVE-2026-104055"
        date = "2026-01-01"
    strings:
        $exporter = "postgres_exporter" ascii nocase
        $user = "monitoring" ascii nocase
        $pw1 = "password=" ascii nocase
        $pw2 = "password:" ascii nocase
        $err1 = "connection error" ascii nocase
        $err2 = "failed to connect" ascii nocase
    condition:
        filesize < 10MB and
        $exporter and
        $user and
        ($pw1 or $pw2) and
        ($err1 or $err2)
}

Suricata IDS Rule

alert tcp any any -> any any (msg:"CVE-2026-104055 Potential postgres_exporter Credential Disclosure in Exported Logs"; flow:to_server,established; content:"postgres_exporter"; nocase; content:"password="; nocase; content:"connection error"; nocase; distance:0; within:512; sid:2026104055; rev:1; reference:cve,2026-104055; classtype:policy-violation;)

Note: This rule targets log-shipping traffic where log lines are transmitted in cleartext over the wire. Where logs are shipped over encrypted channels, application-layer detection at the log source is preferred.

Elastic Detection

process where event.action == "log" and
  process.name : ("postgres_exporter", "postgres-exporter") and
  message : ("connection error", "failed to connect", "connection failed") and
  message : ("password=", "password:")

Splunk SPL Query

index=* (sourcetype=*postgres* OR source=*postgres_exporter*)
  ("connection error" OR "failed to connect" OR "connection failed")
  ("password=" OR "password:" OR "user=monitoring")
| stats count values(message) as messages by host, source
| where count > 0

Wazuh OSSEC Rule

<group name="postgres_exporter,CVE-2026-104055,">
  <rule id="1040551" level="12">
    <decoded_as>json</decoded_as>
    <match>postgres_exporter</match>
    <regex>connection (error|failed)|failed to connect</regex>
    <regex>password[=:]</regex>
    <description>Possible cleartext monitoring credential disclosure in postgres_exporter logs (CVE-2026-104055)</description>
    <mitre>
      <id>T1552</id>
    </mitre>
    <group>credential_access,</group>
  </rule>
</group>

Note: Adjust the decoder to match your log ingestion format (JSON, syslog, or raw). Validate that the regex does not match redacted forms.

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No workarounds are recorded in the data provided. The CNA description does identify fixed revisions in the operator charm, which should be treated as the primary remediation path even though they were not captured by the automated patch sources tracked here.

1. Immediate mitigations (compensating controls while patching is coordinated):

   • Restrict read access to postgres_exporter logs at every layer: node filesystem permissions, container runtime log access, Kubernetes RBAC on pod logs, and access controls on any centralized log aggregation platform. Treat exporter logs as credential-bearing material.
   • Reduce retention and replication of exporter logs; avoid shipping them to broadly accessible observability dashboards.
   • Rotate the monitoring user's password on any deployment where exporter logs may have been read by a wider audience. Rotation is the only reliable way to invalidate a credential that has been disclosed.
   • Alert on the detection signatures above so that a fresh disclosure event is noticed rather than silently accumulated.
   • If the exporter can be configured to suppress or redact connection strings on error, apply that configuration; the NVD description does not enumerate such an option, so verify against the current exporter documentation for your deployment.

2. Patch / upgrade steps:

   • Upgrade the postgresql-operator charm to the fixed revisions on the appropriate track and architecture:
     • Dev track (14/edge): revision 1189 (arm64) or 1190 (amd64).
     • Stable track (14/stable): revision 1216 (arm64) or 1217 (amd64).
   • Apply the matching revision for the platform's CPU architecture; do not mix revisions across nodes in a single cluster.
   • Following upgrade, rotate the monitoring credential to invalidate any value that may have been written to logs before the fix was deployed.

3. Long-term hardening:

   • Adopt a policy that service-account credentials must never be serialized into log output; enforce this via linting and code review for any exporter or agent deployed alongside a database.
   • Where practical, eliminate long-lived static passwords for the monitoring user in favor of short-lived or certificate-based authentication.
   • Apply least-privilege log access by default and audit who can read database-adjacent logging streams.
   • Track the operator charm's release revisions as a patching signal; revisions are the authoritative fix reference for this vulnerability class.

References

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-104055
• CWE-532: Insertion of Sensitive Information into Log File — https://cwe.mitre.org/data/definitions/532.html
• Canonical postgresql-operator charm (release revisions) — https://charmhub.io/postgresql
• Prometheus postgres_exporter — https://github.com/prometheus-community/postgres_exporter
• CISA KEV catalog: not listed (checked with current data). No threat actor campaigns or exploit-in-the-wild evidence are recorded for CVE-2026-104055 at the time of writing. There is no public PoC, no Nuclei template, and no published exploit code.