Skip to content
HackIndex logo

HackIndex

PostgreSQL Remote Access Misconfiguration

3 min read Mar 26, 2026

PostgreSQL access is controlled at two levels: the network interface it listens on (listen_addresses) and the client authentication rules in pg_hba.conf. Both need to be misconfigured simultaneously for remote access to be possible — the service must be bound to a network interface and pg_hba.conf must allow the connection. When both conditions are met and the authentication method is weak or absent, the database is directly attackable from the network without requiring any other foothold.

Confirm Network Exposure

Check whether port 5432 responds from outside the host:

┌──(kali㉿kali)-[~]
└─$ nmap -sV -p 5432,5433 $TARGET_IP 
PORT     STATE SERVICE    VERSION
5432/tcp open  postgresql PostgreSQL DB 14.5

A responding PostgreSQL service on a non-loopback IP confirms the instance is network-accessible. Even a rejection or authentication failure from psql confirms the port is open and the service is listening.

Check the Listen Address

Once any valid connection is available, confirm what interface PostgreSQL is bound to:

┌──(kali㉿kali)-[~]
└─$ PGPASSWORD=$PASSWORD psql -h $TARGET_IP -p ${PORT:-5432} -U $USER -d postgres -c "SHOW listen_addresses;" 
 listen_addresses
------------------
 *
(1 row)

listen_addresses = * means PostgreSQL is listening on all available network interfaces including any public-facing ones. A value of localhost or 127.0.0.1 means you reached it through a tunnel or pivot rather than direct exposure.

Inspect pg_hba.conf for Permissive Entries

With superuser access the pg_hba_file_rules view reveals which hosts and networks are allowed to connect and with what authentication method:

┌──(kali㉿kali)-[~]
└─$ PGPASSWORD=$PASSWORD psql -h $TARGET_IP -p ${PORT:-5432} -U postgres -d postgres -c "SELECT type, database, user_name, address, netmask, auth_method FROM pg_hba_file_rules ORDER BY auth_method;" 
 type  | database | user_name | address   | netmask   | auth_method
-------+----------+-----------+-----------+-----------+-------------
 host  | all      | all       | 0.0.0.0   | 0.0.0.0   | trust
 host  | all      | all       | 0.0.0.0   | 0.0.0.0   | md5
 local | all      | all       |           |           | peer

Entries to flag:

  • auth_method = trust with a broad address range — passwordless access from any covered host.
  • auth_method = md5 or scram-sha-256 with address = 0.0.0.0/0 — password authentication required but accessible from anywhere, making it a brute-force target.
  • user_name = all combined with a broad address range — any account is accessible from the covered network.

Verify on the Host if Shell Access is Available

┌──(kali㉿kali)-[~]
└─$ ss -tlnp | grep 5432 
LISTEN  0  244  0.0.0.0:5432  0.0.0.0:*  users:(("postgres",pid=1234,fd=5))
┌──(kali㉿kali)-[~]
└─$ grep -v '^#' /etc/postgresql/*/main/pg_hba.conf 2>/dev/null | grep -v '^$' 
local   all   all                                peer
host    all   all   0.0.0.0/0   md5
host    all   all   127.0.0.1/32   trust
┌──(kali㉿kali)-[~]
└─$ grep 'listen_addresses' /etc/postgresql/*/main/postgresql.conf 2>/dev/null 
listen_addresses = '*'

Document the Finding

Record the listen_addresses value, which pg_hba.conf entries cover the attacker's source network, and what authentication method applies. A publicly accessible PostgreSQL instance with md5 or scram-sha-256 on a broad host entry is a credential brute-force target. One with trust on a broad entry is immediately accessible without credentials. Either finding combined with a superuser account being accessible is a critical severity finding.

References