# PostgreSQL Weak and Default Credential Check

- **URL:** https://hackindex.io/services/postgresql/vulnerability-discovery/postgresql-weak-and-default-credential-check
- **Path:** PostgreSQL > Vulnerability Discovery
- **Up:** [Vulnerability Discovery](https://hackindex.io/services/postgresql/vulnerability-discovery.md)
- **Published:** 2026-03-26
- **Updated:** 2026-03-26

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

```bash
psql -h $TARGET_IP -p ${PORT:-5432} -U postgres -d postgres -c 'SELECT version();' 2>&1
```

```bash
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.

```bash
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.

```bash
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

- [PostgreSQL: Password authentication](https://www.postgresql.org/docs/current/auth-password.html) - Password authentication methods and PGPASSWORD environment variable reference
- [NetExec documentation](https://www.netexec.wiki/) - PostgreSQL protocol usage and Pwn3d superuser detection reference