CVE-2024-32655

What it actually does

Integer overflow in WriteBind() uses int variables for message and parameter lengths, writing a truncated size in the Postgres protocol message; the server then misparses subsequent bytes as new messages, enabling injection of arbitrary protocol commands that execute SQL on the application's behalf.

Why it matters to the business

Attackers can execute unauthorized database operations, risking data theft, modification, or deletion, which may cause compliance violations, operational outages, and loss of trust; the library is widely used so many .NET applications remain exposed until upgraded.

How an attack unfolds

An attacker supplies a query with parameter lengths large enough to overflow the int variables inside WriteBind(), causing Npgsql to emit a Postgres protocol message with an understated length; the server reads only the declared bytes and treats the remainder as fresh messages, allowing the attacker to inject arbitrary protocol commands that result in SQL execution under the application's credentials.

How to fix it

Upgrade Npgsql to one of the fixed releases: 4.0.14, 4.1.13, 5.0.18, 6.0.11, 7.0.7, or 8.0.3 (or the equivalent commit e34e2ba8042e666d9af54a1b255fba4d5b11df56 in source builds). Rebuild and redeploy all dependent applications after the upgrade.

How to confirm the fix worked

Inspect the Npgsql assembly or package version against the fixed list; perform functional testing with oversized parameter sets to confirm correct message lengths are emitted; review connection strings and dependency manifests across the environment.

Typical attack path

1. Identify an application using a vulnerable Npgsql version to connect to PostgreSQL
2. Craft a query containing parameter values whose combined lengths exceed INT_MAX
3. Send the query through the application's normal data path
4. Trigger the overflow so the emitted bind message carries an incorrect length
5. Inject protocol messages that the server interprets as separate commands
6. Execute arbitrary SQL statements on the application's behalf

How to detect it

Review PostgreSQL server logs and application connection traces for protocol-level anomalies such as unexpected message boundaries or SQL statements that do not match application source; correlate with client IP and query timing around large parameter submissions.

What your security team should do

• Prioritize upgrade of Npgsql to a fixed version in all applications
• Scan dependency manifests and container images for vulnerable Npgsql versions
• Add Npgsql version checks to CI/CD pipelines and software bill of materials
• Monitor database logs for unexpected statements originating from application connections