psqlODBC Security Update: Which Machines Need Patching?

If your application uses psqlODBC, update the driver to 18.00.0006 or a later fixed release on the machines that load it. Updating the PostgreSQL server alone does not replace a client-side driver. The PostgreSQL ODBC project announced this security release on 2 November 2026; its changelog identifies affected releases before 18.00.0006.

The practical question is which process loads the driver: your application server, a reporting worker, a desktop tool, or an image copied into several environments. Start there, rather than assuming the database host is the only machine to patch.

What does the psqlODBC security update fix?

psqlODBC is the official PostgreSQL ODBC driver. It sits in the client connection path. A PostgreSQL server version number does not tell you which ODBC driver a separate application uses.

The release changelog lists 11 vulnerabilities covering memory safety, SQL handling and logging, alongside additional hardening. They have different preconditions; this is not one universal attack that compromises every PostgreSQL deployment. Read the release-specific changelog against the driver features your applications actually use.

Two examples show why that distinction matters:

• Large-object reads: the CVE-2026-120057 advisory describes a client buffer overflow involving a server not authenticated by the current connection settings, or a man-in-the-middle. The patch bounds the copied reply. That is a reason to inspect client software and server authentication together.
• Updatable cursors: the CVE-2026-120065 advisory describes unsafe handling of a server-supplied column name in a particular cursor path. Under its stated conditions, the driver can run altered SQL with the application's privileges. The update fixes identifier escaping.

Do not use this release as a reason to switch database engines or perform an unrelated PostgreSQL major upgrade. The immediate task is identifying and replacing the affected driver in the client workload.

Which machines should you check first?

Use the following inventory as a working checklist. These are deployment examples, not a claim that every installation contains psqlODBC.

Give priority to clients that connect to servers outside your control, accept untrusted SQL, or use the features named in the advisories. A database with no public inbound endpoint still has clients that need maintenance.

Also check whether the application uses ODBC at all. A JDBC, libpq or other connection is not evidence that psqlODBC is loaded. Trace the real dependency before changing a working deployment.

How should you roll out the patch?

This is a recommended operational sequence, not a record of a patch tested against your application.

1. Identify the running dependency. Record the application, host or image, driver name, version, architecture and owner. Inspect the DSN or connection configuration without copying passwords into tickets or logs. Keep 'installed somewhere' separate from 'loaded by this service'.
2. Find the fixed build for that environment. Use the project's download entry point or your distribution's maintained package channel. Confirm the upstream fixed version or a documented vendor backport. A package refresh that leaves the vulnerable driver in place is not completion.
3. Rehearse in a matching environment. Exercise a real read and a controlled write, plus the cursor or large-object behavior your application depends on. Use test data. Check connection setup, transaction handling and normal error paths, not just whether a login succeeds.
4. Update the recreatable source. Patch the image or provisioning definition as well as the current machine. Otherwise the next worker, rebuild or restore can bring the old driver back. Record the resulting artifact identity.
5. Reload the client workload. Restart the affected application or replace its workers as appropriate, then confirm which driver the new process loads. A running process may still hold its previously loaded library after files on disk change.
6. Verify and record the result. Repeat the application's smoke test, inspect errors and connection behavior, and record the driver version used after deployment. Recheck unattended jobs that do not execute until later.

Keep a controlled rollback path, but do not treat returning to an affected driver as the security fix. If compatibility blocks the update, document the exposure and temporary restrictions while you resolve it.

Can connection settings reduce exposure while you patch?

Some advisory workarounds are narrow. For the large-object issue, the maintainers advise avoiding large-object fetches from servers that are not authenticated using the stated SSL or GSSAPI settings. PostgreSQL's TLS documentation explains that verify-full checks both certificate trust and the requested hostname. Configure trust correctly; do not disable verification merely to make a new connection pass.

For the updatable-cursor issue, the advisory lists disabling updatable cursors or using read-only cursors as workarounds. Those changes can affect application behavior, and they do not establish that the other issues in this release are mitigated. Follow the specific advisory, then finish the driver update.

Network restrictions, TLS authentication, least-privilege database roles and software updates address different parts of the connection. Use them together.

What does this mean for PostgreSQL on Krova?

If PostgreSQL runs on a Cube and the ODBC application runs elsewhere, inspect the application machine first. If the application runs on a Cube too, inspect that Cube's driver and deployment image. Moving the database does not automatically update either client.

Krova's PostgreSQL deployment guide covers SSH tunnels for development and IP-allowlisted TCP mappings for deployed applications. Those are useful ways to control access. They do not replace the driver patch, certificate validation or application testing.

For a new self-managed deployment, start with the connection model in that guide and keep the client inventory alongside the server configuration. A patch checklist is more useful when it identifies the process that needs restarting.

The decision

Patch the driver where the application uses it, rebuild what will recreate it, and verify a newly started client. Do not close the task solely because the PostgreSQL server is current.

This article covers the psqlODBC release announced on 2 November, using upstream material checked on 3 November 2026. The release announcement is dated 2 November; the two GitHub advisories discussed here display 3 November. It is not a finding that Krova customer workloads are affected or that any workload has been patched. Package availability, vendor backports and application compatibility must be checked in your environment.