psqlODBC 18.00.0005 Fixes CVE‑2026‑109448 Heap Corruption

Every application that reaches PostgreSQL through psqlODBC, the official ODBC driver, from version 08.01.0102 through 18.00.0004 should move to psqlODBC 18.00.0005 or later. The release fixes CVE-2026-109448: the driver kept the number of bound parameters in a signed 16-bit field, so binding more than 32767 parameters on one statement corrupted heap memory. Applications most at risk are those that build a parameter list from user input, such as an IN (?, ?, ...) list, and those are also the ones that need a code change to keep working after the upgrade.

What Happens Past 32767 Parameters #

The advisory GHSA-cmfx-rm3r-p2jr explains the arithmetic. SQLBindParameter accepted parameter numbers from 1 to 65535, but the count lived in a signed 16-bit field. Binding parameter 32768 wraps the count to -32768; binding parameter 32769 then grows the binding arrays and zero-fills them from index -32768, writing about 2.5 MB of zeros that start 1.25 MB before the allocation. At exactly 32768 parameters nothing is corrupted, but execution fails with SQLSTATE 07002 even though every parameter was bound, which is why the release announcement speaks of "more than 32768" and the advisory title of "more than 32767".

The symptom depends on the allocator. Glibc builds abort with realloc(): invalid next size, Windows standard builds fail with an access violation, 0xC0000005, and other allocators, including the Windows mimalloc builds, can keep running on a corrupted heap and crash later. The CVSS 3.1 score of 5.9, Medium, from the PostgreSQL CNA reflects that the impact is on availability only; the weaknesses are CWE-190 and CWE-124. CISA's SSVC assessment rates exploitation as none.

Replacing Long Parameter Lists With One Array Parameter #

The old way builds one placeholder per value, so the parameter count grows with the input:

-- one ? per user-supplied id: 40000 ids means 40000 parameters
SELECT * FROM orders WHERE customer_id IN (?, ?, ?, ...);

The new way, which the advisory recommends as a workaround, passes the whole list as a single array parameter, so the statement always has one parameter:

-- one array parameter, for example '{17,42,99}' bound as text
SELECT * FROM orders WHERE customer_id = ANY(?::int[]);

Upgrading psqlODBC #

1. Find every host and image that loads psqlODBC, including Windows machines that use it through ADO or other OLE DB consumers, and note the installed version.
2. Install 18.00.0005 or later. Windows installers and merge modules for x86, x64 and ARM64 are on the PostgreSQL download site and the GitHub release page; the Windows packages are now built with OpenSSL 3.5.9.
3. Before or alongside the upgrade, cap the number of parameters any statement builds from external input, or switch those queries to a single array parameter as shown above.
4. Handle SQLSTATE 07009 from SQLBindParameter in code paths that bind a variable number of parameters, so an oversized request returns an error to the caller instead of an unexplained failure.
5. Check statements that bind 1000 or more parameters on the server: the same release fixes a bug that truncated type names after parameter 1000, causing errors such as type "timestam" does not exist.

Two Other Fixes in 18.00.0005 #

Besides the prepared-statement type name bug, 18.00.0005 fixes bytea parameters that failed with "Type is invalid" through Microsoft's OLE DB Provider for ODBC, MSDASQL, since 18.00.0003. The psqlODBC team credits Richard Kuesters with reporting the security issue.

Verification Checklist After the Upgrade #

• The ODBC driver manager or the installed package reports psqlODBC 18.00.0005 or later on every host.
• No query path binds a parameter count taken directly from user input without an upper limit.
• Large value lists reach PostgreSQL as one array parameter with = ANY(?).
• Application logs no longer show realloc(): invalid next size or 0xC0000005 crashes from the driver.
• Code paths that bind many parameters handle SQLSTATE 07009.