pghoard CVE-2026-54711

LOW

Insertion of Sensitive Information into Log File (CWE-532)

2026-06-18 https://github.com/Aiven-Open/pghoard

GHSA-mpx4-jmpr-vm8v

Information Disclosure

Severity by source

vuln.today AI

5.5 MEDIUM

Local vector because log file read access is the exploitation path; PR:L since reading logs requires at least unprivileged OS access; C:H for full credential disclosure; no integrity or availability impact.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Lifecycle Timeline

Source Code Evidence Fetched

Jun 18, 2026 - 16:03 vuln.today

Analysis Generated

Jun 18, 2026 - 16:03 vuln.today

DescriptionCVE.org

Impact

When using .pgpass, database connection information including the username and password will be logged at the debug level.

Patches

Upgrade to version 2.7.1 or greater.

Workarounds

Filter out debug-level logs.

References

This issue was discovered by BugCrowd user DRAKOKORIAN.

AnalysisAI

Credential exposure in pghoard (Aiven's PostgreSQL backup tool) causes database usernames and passwords sourced from .pgpass files to be written in plaintext to debug-level logs. Versions up to and including 2.1.0 are affected per CPE data, though the vendor advisory specifies the fix lands in 2.7.1. Any party with read access to debug log output - including operators, centralized log aggregation systems, or co-tenants in shared logging pipelines - can recover full database credentials. No public exploit code or CISA KEV listing exists at time of analysis, but the straightforward nature of the disclosure (passive credential leakage) makes exploitation trivially easy once log access is obtained.

Technical ContextAI

pghoard (pkg:pip/pghoard) is an open-source PostgreSQL backup daemon maintained by Aiven-Open. It supports authenticating to PostgreSQL using the standard .pgpass file, which stores host/port/database/username/password tuples. The root cause is CWE-532 (Insertion of Sensitive Information into Log File): the credential-loading code path emits the parsed connection parameters, including plaintext credentials, at the DEBUG log verbosity level. In environments where debug logging is enabled - common during troubleshooting, in staging, or when operators have not explicitly tuned log levels - these credentials persist in on-disk log files, stdout captures, syslog buffers, or any downstream log forwarding target such as Elasticsearch, Splunk, or cloud logging services. The affected CPE is pkg:pip/pghoard.

RemediationAI

Upgrade pghoard to version 2.7.1 or greater as specified in the vendor security advisory at https://github.com/Aiven-Open/pghoard/security/advisories/GHSA-mpx4-jmpr-vm8v. This is the primary and preferred remediation. As an interim workaround where immediate upgrade is not feasible, configure log output filters to suppress or redact DEBUG-level log entries; most logging frameworks (Python's logging module, logrotate pipelines, log shippers like Fluentd or Filebeat) support level-based filtering. Note that suppressing all debug logs may reduce operational visibility during incident response. If logs are forwarded to centralized systems (Splunk, ELK, CloudWatch), apply redaction rules at the shipper level to prevent credential propagation to downstream stores. Additionally, rotate any PostgreSQL credentials that may have been exposed in existing debug log archives, and audit log retention policies to purge historical logs containing leaked credentials.