CVE-2024-32655: Npgsql .NET Provider SQLi Vulnerability

CVE-2024-32655 Overview

CVE-2024-32655 is a critical integer overflow vulnerability in Npgsql, the .NET data provider for PostgreSQL. The vulnerability exists in the WriteBind() method within src/Npgsql/Internal/NpgsqlConnector.FrontendMessages.cs, where int variables are used to store message length and parameter length sums. When parameter lengths become sufficiently large, these integer variables overflow, causing Npgsql to write an incorrectly small message size when constructing PostgreSQL protocol messages. This protocol desynchronization allows attackers to inject arbitrary Postgres protocol messages into the database connection, ultimately enabling execution of arbitrary SQL statements.

Critical Impact

This vulnerability enables attackers to inject arbitrary SQL statements through integer overflow in protocol message handling, potentially leading to complete database compromise, data exfiltration, and unauthorized data manipulation.

Affected Products

• Npgsql versions prior to 4.0.14
• Npgsql versions 4.1.x prior to 4.1.13
• Npgsql versions 5.0.x prior to 5.0.18
• Npgsql versions 6.0.x prior to 6.0.11
• Npgsql versions 7.0.x prior to 7.0.7
• Npgsql versions 8.0.x prior to 8.0.3

Discovery Timeline

• May 14, 2024 - CVE-2024-32655 published to NVD
• December 12, 2024 - Last updated in NVD database

Technical Details for CVE-2024-32655

Vulnerability Analysis

This vulnerability represents a classic integer overflow condition that leads to protocol message injection. The WriteBind() method in Npgsql calculates the total message length by summing individual parameter lengths using signed 32-bit integers (int). When an application passes parameters with a combined size exceeding the maximum value of a signed 32-bit integer (2,147,483,647 bytes), the sum overflows and wraps to a negative or small positive value.

The PostgreSQL wire protocol relies on accurate message length headers to delimit messages. When the overflow causes Npgsql to write an incorrectly small message size, the PostgreSQL server reads only that small number of bytes as the intended message. The remaining bytes—still part of the original oversized message—are then interpreted by PostgreSQL as new, separate protocol messages. This creates a protocol desynchronization condition that attackers can exploit to inject crafted SQL statements that execute with the application's database privileges.

Root Cause

The root cause is the use of signed 32-bit integer (int) variables to calculate and store message lengths in the PostgreSQL protocol message construction code. The WriteBind() method accumulates parameter sizes without bounds checking, allowing integer overflow when the sum of all parameter lengths exceeds Int32.MaxValue. The fix involves using larger data types and implementing proper overflow detection to prevent the message length from being incorrectly calculated.

Attack Vector

An attacker can exploit this vulnerability by providing application inputs that result in large parameter values being passed to PostgreSQL through Npgsql. When the combined parameter data causes the integer overflow, the attacker can craft the overflow bytes to form valid PostgreSQL protocol messages containing malicious SQL statements.

The attack requires:

1. Network access to interact with the application
2. The ability to influence parameter data sent through Npgsql to PostgreSQL
3. Careful calculation of payload sizes to trigger the integer overflow at a precise point

The vulnerability manifests in the PostgreSQL protocol message construction within the WriteBind() method. When the sum of parameter lengths overflows the int variable, the message length written to the protocol header becomes incorrect, causing PostgreSQL to misparse subsequent bytes as new protocol messages. For detailed technical analysis, see the GitHub Security Advisory GHSA-x9vc-6hfv-hg8c and the associated security video demonstration.

Detection Methods for CVE-2024-32655

Indicators of Compromise

• Unusually large data transfers to PostgreSQL databases that approach or exceed 2GB per transaction
• Database logs showing unexpected or malformed SQL statements appearing to originate from legitimate application connections
• Protocol errors in PostgreSQL logs indicating message parsing failures or unexpected message types
• Evidence of data exfiltration or unauthorized database modifications without corresponding application-level audit trails

Detection Strategies

• Monitor application logs for unusually large parameter values being passed to database queries
• Implement database activity monitoring (DAM) to detect SQL statements that don't match expected application patterns
• Deploy network intrusion detection systems (NIDS) with rules to identify anomalous PostgreSQL protocol traffic, particularly messages with inconsistent length headers
• Use SentinelOne Singularity to detect suspicious process behavior indicative of exploitation attempts

Monitoring Recommendations

• Enable detailed PostgreSQL logging including log_statement = 'all' and log_min_error_statement = 'error' to capture potential exploitation attempts
• Implement application-level logging of parameter sizes before database operations to identify overflow attempts
• Configure alerts for database connections exhibiting protocol-level anomalies or unexpected SQL execution patterns

How to Mitigate CVE-2024-32655

Immediate Actions Required

• Upgrade Npgsql to a patched version immediately: 4.0.14, 4.1.13, 5.0.18, 6.0.11, 7.0.7, or 8.0.3 depending on your current major version
• Audit applications using Npgsql to identify any that accept large user-controlled inputs that could be passed as database parameters
• Implement input validation at the application layer to reject abnormally large parameter values before they reach Npgsql
• Review database access logs for signs of exploitation or suspicious SQL execution patterns

Patch Information

Npgsql has released patched versions across all supported release branches. The fixes address the integer overflow by implementing proper bounds checking and using appropriate data types for length calculations. Organizations should upgrade to the following versions:

Multiple commits address this vulnerability across different branches. Review the GitHub Security Advisory for complete details.

Workarounds

• Implement application-level size limits on any user-controlled data that may be passed as database parameters
• Deploy a Web Application Firewall (WAF) configured to block requests containing excessively large payloads
• Use network segmentation to limit database access to only authorized application servers
• Consider implementing prepared statement parameter size validation at the application tier as a defense-in-depth measure

# Check your current Npgsql version in .NET projects
dotnet list package | grep -i npgsql

# Update Npgsql to the latest patched version
dotnet add package Npgsql --version 8.0.3

# For older framework versions, update to the appropriate patched version
# Example for projects on 6.0.x branch:
dotnet add package Npgsql --version 6.0.11