CVE-2026-104055 in postgresql-operator
Summary
by MITRE • 10/02/2026
The postgresql-operator charm runs a Prometheus postgres_exporter to collect database metrics using a dedicated "monitoring" PostgreSQL user. On database connection errors, the exporter writes the monitoring user's password in cleartext to its logs. Any actor able to read those logs can recover the password, which grants read-only pg_monitor access to PostgreSQL. This is fixed in the dev track (14/edge) in revisions 1189 (arm64) and 1190 (amd64), and in the stable track (14/stable) in revisions 1216 (arm64) and 1217 (amd64).
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The postgresql-operator charm utilizes a Prometheus postgres_exporter to facilitate the collection of database metrics, relying on a dedicated monitoring user with restricted privileges. This architectural design is intended to adhere to the principle of least privilege by granting only read-only access via the pg_monitor role for observability purposes. However, a critical implementation flaw exists within the error handling logic of this exporter component. When the postgres_exporter encounters database connection errors, it fails to sanitize sensitive authentication data before logging these events. Consequently, the plaintext password associated with the monitoring user is written directly into the system logs alongside other diagnostic information.
This vulnerability represents a classic case of improper input validation and sanitization leading to credential exposure in log files. From an industry standard perspective, this aligns closely with CWE-532, which covers insertion of sensitive information into log files for security purposes. The flaw allows any actor who gains access to the system logs or has permission to read them to recover the monitoring user's password. This constitutes a significant confidentiality breach as it exposes credentials that should remain secret even during operational failures.
The operational impact of this vulnerability is substantial despite the restricted nature of the compromised account. An attacker with log-reading capabilities can extract the plaintext password and subsequently authenticate to the PostgreSQL instance using the pg_monitor role. While this role does not provide write access or administrative control, it allows for extensive read-only data exfiltration. The pg_monitor privilege set includes permissions to view database objects, query system catalogs, and potentially access sensitive data depending on the specific configuration of the monitored databases. This can lead to unauthorized disclosure of business-critical information, intellectual property theft, or compliance violations under regulations such as GDPR or HIPAA if protected health information is present in the accessible tables.
Furthermore, this vulnerability facilitates lateral movement within a compromised environment. If an attacker has already achieved initial access through another vector and obtained log file permissions, they can pivot to the database layer without needing additional exploitation steps beyond credential harvesting. This scenario maps directly to MITRE ATT&CK technique T1087, specifically Account Discovery or Credential Dumping from local systems, as well as T1530 Data from Local System Exfiltration. The ability to move laterally and access data stores increases the overall blast radius of an initial compromise significantly.
To mitigate this risk, organizations must ensure they are running a patched version of the postgresql-operator charm. The issue has been resolved in the development track with revisions 1189 for arm64 architectures and 1190 for amd64 architectures. For environments relying on stable releases, updates to revision 1216 for arm64 and revision 1217 for amd64 are required. Immediate upgrade is recommended to eliminate the plaintext password exposure in logs. In addition to patching, administrators should audit existing log files for any previously leaked credentials and rotate the monitoring user's password as a precautionary measure even after applying the fix. Implementing strict file permissions on log directories can also limit access to sensitive operational data, reducing the window of opportunity for attackers attempting to harvest such information from unpatched systems.