PostgreSQL Operator EUVD-2026-91803

Two concrete conditions must both hold: (1) the attacker must be able to read the Prometheus postgres_exporter's logs for the postgresql-operator charm - e.g., access to the Juju unit/container, the log files, or a downstream log-aggregation/observability system that ingests them; and (2) a database connection error must have occurred, because the exporter only writes the monitoring user's password in cleartext on connection failure (so under normal error-free operation the secret is not exposed). Limiting factors: exploitation yields only the 'monitoring' user credential, which maps to read-only pg_monitor access (no write, no admin, no RCE); it affects only charm revisions prior to 1189/1190 (dev track 14/edge) and 1216/1217 (stable track 14/stable); and it is bounded to Charmed PostgreSQL deployments using the operator charm with the exporter enabled.

This is a genuine but modest-severity information-disclosure flaw (CWE-532), not a high-urgency priority. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 5.3 (Medium) with only low confidentiality impact (VC:L) and no integrity or availability impact - consistent with the description, which limits the payoff to recovering a 'monitoring' user password that grants only read-only pg_monitor access. No EPSS score was provided, the CVE is not listed in CISA KEV, and no public exploit code was supplied, so exploitation status is 'no public exploit identified at time of analysis.' A key nuance: the CVSS marks AV:N, but exploitation realistically requires the ability to READ the postgres_exporter's logs, which is itself a privileged/positioned capability rather than anonymous network reach - the PR:L metric partially captures this, but defenders should treat the true attack surface as 'anyone with log read access' (log aggregation operators, co-located processes, or anyone who can reach shipped logs) rather than any unauthenticated internet attacker. The payoff is bounded: pg_monitor is read-only, so there is no direct path to data modification or RCE from this flaw alone. Overall this is a legitimate hardening fix worth patching in affected Charmed PostgreSQL deployments, but not a drop-everything emergency.

An operator or attacker with access to the postgresql-operator charm's logs (directly on the unit, or via a centralized logging/observability pipeline) waits for or induces a database connection error, which causes the postgres_exporter to write the monitoring user's password in cleartext to the log. They copy the password and authenticate to PostgreSQL as the monitoring user, obtaining read-only pg_monitor visibility into database metrics and statistics. No public exploit code is required - recovery is a trivial log grep once the error has been logged.