Privilege Escalation via Postgres Binary Protocol Proxying

The log shows nothing. The query was fast, the rows came back. Yet an attacker just became an admin.

This is privilege escalation through Postgres binary protocol proxying. It doesn’t ride on SQL injection or sloppy GRANTs. It happens in the layer under your SQL, in the Postgres wire itself. When that protocol is proxied, it can be altered in-flight. A proxy that understands the binary protocol can change startup messages, authentication responses, and query results before the target sees them.

Postgres speaks more than text-based queries. The binary protocol carries statements, parameters, and authentication negotiations in a structured format. A proxy sitting between client and server can impersonate either side, insert extra messages, or replay previous ones. If that proxy has access to higher-privilege credentials upstream, it can transparently swap roles for the client connection.

Privilege escalation here can take several forms:

• Modifying the StartupMessage to request a superuser role.
• Altering RowDescription and DataRow packets to convince application code it has valid elevated tokens.
• Intercepting AuthenticationOk and replying with credentials tied to superuser accounts.
• Injecting control messages that trigger privileged functions like COPY ... FROM PROGRAM.

Unlike simplistic SQL injections, this technique bypasses role checks at the application layer. Logs may not record the manipulated session accurately, because the server believes the request came directly from the authenticated client.

Defending against Postgres binary protocol proxy privilege escalation requires strict network segmentation, TLS with client certificates, and eliminating unverified proxies from the connection path. Use least privilege for any service accounts that terminate binary connections. Audit connection logs and verify role assignments at the start of each transaction.

If you run critical systems on Postgres, do not assume a trusted network makes you safe. Control every hop between client and server. Watch the wire.

Want to see how this attack works, and how to stop it, without touching production? Try it yourself on hoop.dev and get it running in minutes.