When you press Ctrl-C in psql to cancel a running Postgres query, the CancelRequest is sent as a new, separate TCP connection using a special protocol magic number. Critically, psql always sends this request unencrypted — even when the original connection uses strict TLS settings. This exposes a Denial-of-Service vulnerability: anyone who can intercept network traffic can replay the cancellation request to cancel any future queries on that connection. While Postgres 17 added encrypted cancellation support in libpq, and Postgres 18 introduced longer secret keys (up to 256 bytes) via protocol v3.2, psql itself still doesn't use these features by default. The post also covers how this unencrypted CancelRequest breaks SNI-based Postgres proxies like Elephantshark, and how the fix involves mapping (process ID, secret key) pairs to destination hostnames. Mitigations include using Postgres 18 with min_protocol_version=3.2, using a VPN, or avoiding Ctrl-C in psql.

7m read timeFrom neon.com
Post cover image
Table of contents
How CancelRequest worksHello, Denial-of-Service?No TLS = SNI is MIAWrapping up

Sort: