GHSA-3GJW-F78C-VVPW: Denial of Service via Unhandled Out-of-Bounds Indexing Panic in tokio-postgres

tokio-postgres is an asynchronous, pure-Rust client implementation for the PostgreSQL database. It is widely deployed across high-performance Rust web backends, microservices, and data pipelines to manage database connection pools and execute SQL statements asynchronously. The library communicates directly with PostgreSQL backends using the standard PostgreSQL frontend/backend protocol.

A trust assumption mismatch exists within the library regarding messages sent by the database server. Specifically, the client assumes that the database server will only transmit well-formed row data that strictly matches the previously declared query schema. This architectural trust exposes an attack surface where a rogue or manipulated database server can trigger unexpected state transitions on the client.

The vulnerability manifests as an unhandled out-of-bounds slice indexing panic. This occurs when the client attempts to access fields of a row that contains fewer fields than the columns advertised in the query's metadata. Because the panic is unhandled, it typically terminates the executing thread or aborts the entire Rust process, leading to a Denial of Service (DoS) of the client application.

To understand the root cause of this vulnerability, we must examine the sequence of messages in the PostgreSQL backend-to-frontend protocol. When a client issues a query, the backend server first sends a RowDescription (type 'T') message. This message contains metadata about each column, including its name, table OID, attribute number, data type, size, and modifier. This message establishes the structure and column count N of the expected output.

Following the description, the backend transmits one or more DataRow (type 'D') messages containing the actual query results. A DataRow starts with a two-byte integer indicating the number of fields M present in that row, followed by length-value pairs for each field. Under normal conditions, the field count M must equal the column count N defined in the RowDescription message.

Prior to version 0.7.18, tokio-postgres did not validate that M is equal to N during row construction. The constructor parsed the DataRow into an internal vector of byte ranges representing each field's offset. When an application later attempted to access a column at index I (where 0 <= I < N), the library mapped the index to the corresponding range in the vector. If M < N and the application requested an index I >= M, the program attempted to access an element beyond the bounds of the parsed ranges vector, causing an indexing panic.

We can analyze the vulnerability by inspecting the code inside tokio-postgres/src/row.rs prior to the patch.

// Vulnerable Row constructor
impl Row {
    pub(crate) fn new(statement: Statement, body: DataRowBody) -> Result<Row, Error> {
        let ranges = body.ranges().collect().map_err(Error::parse)?;
        Ok(Row {
            statement,
            body,
            ranges,
        })
    }
}

In this implementation, ranges is populated directly from the DataRowBody without evaluating its length against the number of expected columns in statement.columns(). The application retrieves data using column indexes, which are bounds-checked against the Statement columns, not the actual ranges vector.

The patch introduces strict validation in both Row::new and SimpleQueryRow::new functions:

// Patched Row constructor
impl Row {
    pub(crate) fn new(statement: Statement, body: DataRowBody) -> Result<Row, Error> {
        let ranges = body.ranges().collect().map_err(Error::parse)?;
        let row = Row {
            statement,
            body,
            ranges,
        };
        // The DataRow field count is sent by the server independently of the
        // RowDescription column count; a mismatch would make column accessors
        // index `ranges` out of bounds and panic, so reject it up front.
        if row.ranges.len() != row.statement.columns().len() {
            return Err(Error::parse(io::Error::new(
                io::ErrorKind::InvalidData,
                "DataRow field count does not match the number of columns",
            )));
        }
        Ok(row)
    }
}

This validation converts an inevitable out-of-bounds panic into a standard, recoverable Rust Result::Err wrapping an io::Error of type InvalidData.

An attacker can exploit this vulnerability through three main vectors: hosting a rogue PostgreSQL database, compromising an existing database server, or executing a Man-in-the-Middle (MitM) attack to alter network packets. The vulnerability requires no authentication on the application side beyond standard database access configuration.

In a typical exploit scenario, the client application initiates a query expecting a multi-column result. The attacker-controlled server sends a valid RowDescription defining two columns but returns a DataRow with only one field.

When the client receives the data, the row is instantiated successfully because there is no constructor-level validation. The crash occurs when the application attempts to process the row, specifically when indexing into the ranges vector during column value extraction.

The security impact of this vulnerability is a complete Denial of Service (DoS) of the client application. Because Rust's asynchronous execution model often routes multiple client requests through a shared thread pool, an unhandled panic can abort the task and, depending on panic behavior configurations (such as panic = "abort"), crash the entire executable.

The attack requires low complexity if the target application connects to external or user-provided database sources. In managed cloud environments where database endpoints are strictly controlled, exploitation requires either network-level interception (MitM) or prior compromise of the database host.

As this issue is tracked exclusively under the GitHub Advisory Database (GHSA-3GJW-F78C-VVPW) and does not have an assigned CVE identifier, standard scoring metrics like CVSS or EPSS percentiles from NVD are not available. However, a qualitative risk assessment places this at High severity because of the low effort required to crash consumer services once database communication is intercepted.

Remediation requires upgrading the tokio-postgres library to version 0.7.18 or later. This can be verified by analyzing the dependency tree using the Cargo build tool.

cargo tree -p tokio-postgres

To prevent network-level exploitation such as packet manipulation, database connections must enforce strict TLS validation. Applications should avoid connecting to database servers over unencrypted connections or with disabled certificate checks.

// Secure connection configuration
let mut builder = native_tls::TlsConnector::builder();
// Ensure strict verification of the server's identity
builder.danger_accept_invalid_certs(false);
builder.danger_accept_invalid_hostnames(false);

Additionally, applications should handle database queries within structured boundaries that can recover from runtime errors, ensuring that database parsing failures do not lead to application crashes.