Three DoS Vulnerabilities Patched in Rust PostgreSQL Driver

A malicious or compromised PostgreSQL server can pin a tokio worker thread to 100% CPU indefinitely by sending an unbounded SCRAM PBKDF2 iteration count — and that's just one of three newly fixed DoS holes in the Rust postgres driver stack.

CPU Exhaustion via Unbounded PBKDF2 Iterations

postgres-protocol implements SCRAM-SHA-256 authentication, which includes a PBKDF2 derivation with an iteration count sent by the server. Prior to version 0.6.12, the code accepted any iteration count without a cap. An attacker controlling the server, or a MITM who can intercept and modify the server's SCRAM message, can set an astronomical iteration count. The client then spends seconds or minutes computing the derived key, blocking the single tokio worker thread that handles authentication. No other connections on that worker make progress. This is textbook CPU-exhaustion DoS.

Panic on Malformed Hstore Values

The same postgres-protocol crate, up to 0.6.12, panics when decoding a malformed hstore value. Hstore is a key-value text storage type; a crafted binary representation with inconsistent lengths triggers an unwrap or index panic inside decode. Any client that processes an incoming hstore value from a hostile server or a stored malicious row crashes. No graceful error — the application terminates.

Panic on Unexpected DataRow Layout

tokio-postgres version 0.7.18 fixes a panic that occurs when a DataRow message contains fewer field values than the number of columns in the prepared statement. The protocol expects the row to match the column count, but a malicious server can send a truncated row. The client's row processing code accesses out-of-bounds indices, causing a panic in the async stream. Again, a full disconnect rather than a recoverable error.

All three advisories were committed to the RustSec advisory-db on June 12, 2026. The fixes are in postgres-protocol 0.6.12 and tokio-postgres 0.7.18. Any Rust application that uses these libraries and accepts connections from untrusted PostgreSQL servers — think cloud services, multi-tenant databases, or any setup where the client connects to a database you don't fully control — should update immediately. The attack surface is real: if an attacker can compromise the database server or intercept the TLS connection, they can crash your Rust process or degrade your service.

Source: Add advisories for rust-postgres DoS issues (postgres-protocol, tokio...
Domain: github.com