PostgreSQL Penetration Testing

“Database security often represents the last line of defense before sensitive data exposure. A successful compromise of a PostgreSQL instance can lead to privilege escalation from the application level straight to operating system compromise.”

COPY ... FROM PROGRAM executes a shell command on the database server and reads its output into a table. It is a documented feature, added deliberately for loading data, available to any role with the right privilege. It is also, from an attacker’s chair, a remote code execution primitive shipped in the box. PostgreSQL Penetration Testing treats the database as what a superuser session makes it — a way onto the host — rather than as a pile of tables.

Bypassing Authentication

The guide sets the baseline first: how the postgres superuser is provisioned and how roles are granted, because you cannot recognise an over-privileged account without knowing what a normal one looks like.

Then offence. Nmap and Metasploit modules find exposed listeners on port 5432 and work the authentication gateway. The realistic entry point is less brute force than default and reused credentials, and the underappreciated one is trust authentication in pg_hba.conf — a mode that authenticates any connecting user with no password at all. It is the standard local default so applications on the same host can connect, and every so often someone widens the address range on that line to reach a remote client and turns a local convenience into an open superuser socket.

Advanced Data Extraction & Code Execution

The post-exploitation chapters are the substance:

• System file reading: A superuser can read files the postgres OS account can access and pull them back through SQL — /etc/passwd, configuration, application secrets. Out-of-band, through legitimate functions, nothing that looks like an exploit.
• Hash extraction: Dumping the role password hashes from pg_authid for offline cracking, which matters because those credentials are often reused for the OS account or elsewhere on the estate.
• Reverse shell weaponisation: The endpoint of the path. COPY FROM PROGRAM on modern versions, or a plpython/plperl untrusted procedural language, or writing a file to disk and triggering it — several routes to the same outcome, a shell running as the postgres user on the database host.

The one qualification the excitement should not skip: all of this requires superuser or a specifically privileged role. A session as a constrained application role scoped to one database gets none of it, which is exactly why the single most valuable hardening step is making sure the application never connects as postgres.

Hardening the Architecture

The mitigations follow directly:

• Reserve superuser for administration and run applications as roles scoped to the databases and operations they actually need.
• Tighten pg_hba.conf — replace trust with scram-sha-256, and narrow the address ranges to the hosts that genuinely connect. The cost is the usual one: a range that is too tight severs a client nobody documented, so this is a discovery exercise carrying a real outage risk if done blind.
• Audit for the behaviours that signal post-exploitation — COPY FROM PROGRAM, reads against pg_authid, procedural-language function creation. These are rare in normal operation, which is what makes them good signals; the failure mode is leaving log_statement at its default, where the queries execute and nothing records them.

Who Is This Book REALLY For?

• Senior penetration testers: A focused primer on turning a database login into a shell on the underlying Linux host, with the several routes that survive one being disabled.
• PostgreSQL administrators: The uncomfortable demonstration that superuser is host compromise, not merely full database access, and why the application account must never hold it.
• Blue team analysts: What COPY FROM PROGRAM and unexpected file reads look like in the logs — assuming statement logging is on, which is the assumption the whole detection rests on.

The Bottom Line

PostgreSQL Penetration Testing lands on something plain: a database is software, and software this capable will be used for everything it can do, not merely what it was deployed for. Hand an attacker a superuser session and they are no longer in your database. They are on your server.