pgAdmin 4: Server passwords are left in pgAdmin's process environment
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 9.19
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
pgAdmin 4 (the PostgreSQL administration web tool) is affected, specifically in its server mode where multiple users share one instance. In these versions, saved database server passwords can leak into shared process settings, so one user's later database session or background utility may use another user's saved password and gain unauthorized access to that database server.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
To pass a server's password to psql and to the utilities pgAdmin 4 runs as background processes, the server manager wrote it into pgAdmin's own process environment: as PGPASSWORD for the PSQL tool, and under a per-process variable for a utility. Nothing removed it afterwards. pgAdmin's environment is shared by every user's requests and copied into every process it starts, so in server mode another user's later PSQL session or utility inherited the password, and libpq used PGPASSWORD for any connection made without a password of its own, letting one user connect with another user's saved password. The fix puts the password only into the environment built for the process that needs it and starts psql with a copy of pgAdmin's environment instead of the environment itself. This issue affects pgAdmin 4: before 9.19.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- pgadmin.org pgAdmin 4
fixed in 9.19