<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>VulnFeed.org: PostgreSQL psqlODBC</title><link>https://vulnfeed.org/</link><description>Every disclosure, as it lands. Critical-only feed available.</description><language>en</language><atom:link href="https://vulnfeed.org/feed/product/postgresql-psqlodbc.xml" rel="self" type="application/rss+xml"/><item><title>CVE-2026-120061: psqlODBC ODBC escape parser stack buffer overflow</title><link>https://vulnfeed.org/cve/CVE-2026-120061/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-120061/</guid><pubDate>Mon, 02 Nov 2026 19:18:03 +0000</pubDate><description>The psqlODBC parser for ODBC escape sequences in application SQL text writes the argument offsets of a {fn} escape into a fixed 16-entry stack array without a bound and does not initialize the array. An escape with too many arguments overflows the stack, and a reference to an unsupplied argument copies arbitrary bytes into the query. The copy of a {d}, {t}, {ts}, or {escape} body also writes one byte past a 128-byte stack buffer. An application that forwards untrusted SQL text to the driver exposes its process to memory corruption. Versions before psqlODBC 18.00.0006 are affected.</description></item><item><title>CVE-2026-120062: psqlODBC SQL injection through SQLSpecialColumns table and schema names</title><link>https://vulnfeed.org/cve/CVE-2026-120062/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-120062/</guid><pubDate>Mon, 02 Nov 2026 19:18:03 +0000</pubDate><description>SQLSpecialColumns in psqlODBC splices the table and schema names it receives into its catalog query without escaping them, while the other catalog functions escape them. An application that passes an untrusted table or schema name to SQLSpecialColumns lets the caller execute arbitrary SQL with the privileges of the connection. Versions before psqlODBC 18.00.0006 are affected.</description></item><item><title>CVE-2026-120064: psqlODBC does not validate column numbers and row indexes in binding and descriptor functions</title><link>https://vulnfeed.org/cve/CVE-2026-120064/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-120064/</guid><pubDate>Mon, 02 Nov 2026 19:18:03 +0000</pubDate><description>Several psqlODBC entry points use an application-supplied column number or row index as an array index without validating it. SQLBindCol with a column number above 32767 wraps the binding count negative and a later copy runs off the array. A negative SQL_DESC_COUNT on an application row descriptor unbinds columns at negative indexes. SQLColAttribute with a very large column number uses a negative index. SQLSetPos(SQL_ADD) does not check the row number against the rowset size. An application that forwards untrusted column or row numbers exposes its process to out-of-bounds reads and writes. Versions before psqlODBC 18.00.0006 are affected.</description></item><item><title>CVE-2026-120065: psqlODBC does not escape a server-supplied column name in its updatable-cursor queries</title><link>https://vulnfeed.org/cve/CVE-2026-120065/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-120065/</guid><pubDate>Mon, 02 Nov 2026 19:18:03 +0000</pubDate><description>For an updatable cursor over a table without OIDs that has an auto-increment int4 column, psqlODBC uses that column to identify rows. It places the column&apos;s name, as reported by the server, between double quotes in its keyset queries and in the WHERE clause of its positioned SELECT, UPDATE, and DELETE statements, without doubling any double quote in the name. A column name that contains a double quote therefore changes the SQL that the driver runs with the application&apos;s privileges, including which rows a positioned UPDATE or DELETE affects. Any database user who can create a table that the application reads with an updatable cursor can choose such a name, and so can a server not trusted under current SSL settings. Versions before psqlODBC 18.00.0006 are affected.</description></item><item><title>CVE-2026-120057: psqlODBC large-object read overflows the application buffer</title><link>https://vulnfeed.org/cve/CVE-2026-120057/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-120057/</guid><pubDate>Mon, 02 Nov 2026 19:18:02 +0000</pubDate><description>psqlODBC copies the reply to a large-object read (loread) into the application&apos;s buffer using the length sent by the server, without comparing it to the buffer size. A server not trusted under current SSL settings, or a man-in-the-middle, can return more bytes than the buffer holds and overwrite adjacent memory in the client process with server-chosen bytes. Fetching any large-object column is sufficient to trigger it. Versions before psqlODBC 18.00.0006 are affected.</description></item><item><title>CVE-2026-120058: psqlODBC row cache overflow when a later FETCH changes the column count</title><link>https://vulnfeed.org/cve/CVE-2026-120058/</link><guid isPermaLink="true">https://vulnfeed.org/cve/CVE-2026-120058/</guid><pubDate>Mon, 02 Nov 2026 19:18:02 +0000</pubDate><description>psqlODBC sizes its row cache from the column count of a cursor&apos;s first result, but recomputes the column count from each later FETCH reply without checking that it matches. A server not trusted under current SSL settings can answer a later FETCH with more columns and make the driver write tuple records past the end of the heap allocation. A keyset reply with fewer columns than the key fields also underflows the unsigned field count. This is reachable with UseDeclareFetch enabled. Versions before psqlODBC 18.00.0006 are affected.</description></item></channel></rss>
