The Versa Director uses PostgreSQL (Postgres) to store operational and configuration data. It is also needed for High Availability function of the Versa Director. The default configuration has a common password across all instances of Versa Director. By default, Versa Director configures Postgres to listen on all network interfaces. This combination allows an unauthenticated attacker to access and administer the database or read local filesystem contents to escalate privileges on the system.

Exploitation Status: Versa Networks is not aware of this exploitation in any production systems. A proof of concept exists in the lab environment.

Workarounds or Mitigation: Starting with the latest 22.1.4 version of Versa Director, the software will automatically restrict access to the Postgres and HA ports to only the local and peer Versa Directors. For older releases, Versa recommends performing manual hardening of HA ports. Please refer to the following link for the steps https://docs.versa-networks.com/Solutions/SystemHardening/PerformManualHardeningforVersaDirector#SecureHAPorts

This vulnerability is not exploitable on Versa Directors if published Firewall guidelines are implemented. We have validated that no Versa-hosted head ends have been affected by this vulnerability. All Versa-hosted head ends are patched and hardened.

Please contact Versa Technical Support or Versa account team for any further assistance.

Software Download Links: 22.1.4: https://support.versa-networks.com/support/solutions/articles/23000026708-release-22-1-4

Last updated 22 May 2026

Uncontrolled recursion in PostgreSQL SSL and GSS negotiation allows an attacker able to connect to a PostgreSQL AFUNIX socket to achieve sustained denial of service. If SSL and GSS are both disabled, an attacker can do the same via access to a PostgreSQL TCP socket. Versions before PostgreSQL 18.4, 17.10, 16.14, 15.18, and 14.23 are affected.

Impact

channelBinding=require connections can be silently downgraded from SCRAM-SHA-256-PLUS (with channel binding) to plain SCRAM-SHA-256 (without it), losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection triggers the downgrade with a certificate whose signature algorithm has no tls-server-end-point channel-binding hash. Examples are Ed25519, Ed448, and post-quantum algorithms.

Two issues combine in releases 42.7.4 through 42.7.11:

1. The bundled com.ongres.scram:scram-client (3.1 or 3.2) returns an empty byte array instead of failing when it cannot derive the binding hash for such a certificate. This is the library issue tracked as GHSA-p9jg-fcr6-3mhf. 2. pgJDBC does not enforce channelBinding=require where it matters. ScramAuthenticator checks only that the server advertised a -PLUS mechanism; it neither rejects the empty binding nor checks that the negotiated mechanism uses channel binding. The connection therefore downgrades silently, and would do so even against a fixed scram-client, because the missing enforcement is in pgJDBC's own code.

Only connections that set channelBinding=require are affected. Under the default prefer policy, and under allow or disable, falling back to plain SCRAM is the documented behaviour. Releases before 42.7.4 are unaffected, because they do not support channel binding.

Patches

Fixed in pgJDBC 42.7.12. pgJDBC now enforces channel binding in its own code, independently of the scram-client version:

- Under channelBinding=require, it fails the connection when no channel-binding data can be extracted from the server certificate, instead of passing an empty value to the SCRAM client. The error names the certificate signature algorithm. - After negotiation, it requires the selected mechanism to use channel binding (a -PLUS mechanism) whenever channelBinding=require is set, regardless of how negotiation resolved.

Upgrade to 42.7.12 or later.

Workarounds

No pgJDBC setting restores channel-binding enforcement on an affected release; upgrading is the fix.

If you cannot upgrade immediately, verify the server certificate at the TLS layer so that a man-in-the-middle cannot present a substitute certificate. Set sslmode=verify-full with a truststore that contains only your server's CA. This defence is independent of channel binding and blocks the same attacker. Connections that rely on channelBinding=require in place of certificate verification have no equivalent workaround and should upgrade.

References

- GHSA-p9jg-fcr6-3mhf — the related com.ongres.scram:scram-client issue (root cause of the empty channel-binding value). - scram-client 3.3 release (library fix): https://github.com/ongres/scram/releases/tag/3.3 - pgJDBC fix in 42.7.12: commit

Missing authorization in PostgreSQL logical decoding allows a non-superuser holding REPLICATION privilege to dlopen any file visible to the operating system account running the server, via the choice of logical decoding plugin. This in turn runs arbitrary code as that account. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Incorrect ownership assignment in PostgreSQL ALTER TABLE ALTER TYPE command reassigns ownership of dependent statistics objects to the current user. This wrongly allows the table owner to run DROP STATISTICS and ALTER STATISTICS via this improper ownership. It wrongly denies those commands to the prior statistics object owner. DROP TABLE remains able to remove statistics objects, so this exploit achieves nothing in many ownership arrangements. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Missing authorization in PostgreSQL DDL commands allows an object creator to achieve denial of service against ALTER and DROP of the type, via creating a dependency on the type. Many DDL operations did check the privilege, but assigning a range subtype and referencing the type from an SQL expression did not. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Heap buffer overflow in PostgreSQL pgdump of long function transform lists allows an object creator to execute arbitrary code as the operating system user running pgdump, via a crafted transform list. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

PostgreSQL psql COPY FROM STDIN early failure processes data lines as psql commands

Buffer over-read in PostgreSQL ascii() SQL function allows a user to disclose up to 3 bytes after the end of a specific allocation, via a crafted text value. This is the same class of defect that CVE-2026-2006 fixed, though this instance has less impact. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

PostgreSQL psql \unrestrict lets superuser of pgdump origin server execute arbitrary code in psql client

PostgreSQL type confusion in cursor CLOSE + DECLARE executes arbitrary code

Integer underflow in PostgreSQL ECPG allows a database server administrator to achieve temporary denial of service against the ECPG client via sending a bytea value lacking the mandatory prefix. The client overwrites a huge memory region with bytes outside attacker knowledge or control. This typically yields a simple SIGSEGV, but rare cases might achieve client-specific integrity impact via the write. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Type confusion in PostgreSQL pgrestoreattributestats() allows an object creator to execute arbitrary code as the operating system user running the database, via conflation of range and multirange values. Within major version 18, minor versions before PostgreSQL 18.6 are affected. Versions before PostgreSQL 18 are unaffected.

Integer wraparound in PostgreSQL fuzzystrmatch allows a user to direct writes to a huge range of addresses, executing arbitrary code as the operating system user running the database, via extreme inputs to SQL function levenshtein() or levenshteinlessequal(). Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

PostgreSQL expression deparse allows SQL injection via EXTRACT argument

Improper enforcement of message integrity in PostgreSQL GSSAPI support allows a user to negotiate GSSAPI contrary to pghba.conf rules, via initial direct TLS connection. Despite a pghba.conf that appears to require GSSAPI, the connection may exchange data over TLS encryption alone. If the TLS settings are more permissive than the GSS settings, the connection may continue with lesser protection. Within major versions 17-18, minor versions before PostgreSQL 18.6 and 17.11 are affected. Versions before PostgreSQL 17 are unaffected.

Type confusion with PostgreSQL "internal" data type arguments allows any user to execute arbitrary code as the operating system user running the database, via calls to functions with that argument type. Type "internal" represents a class of mutually-incompatible data structures not intended for access from SQL. The system intended to prevent such function calls, but this prevention had gaps. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Stack buffer overflow in PostgreSQL argument name matching allows an object creator to achieve unknown impacts via OUT parameter count. The attack can write only 0x0 and 0x1 bytes. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Buffer over-read in PostgreSQL pgtrgm index picksplit function reads past end of a heap buffer. This might allow a table maintainer to infer limited memory values, via the lossy signal of index split choices. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Integer wraparound in PostgreSQL 32-bit builds of pltcl and plperl allows an object creator to cause the server to undersize an allocation and write out-of-bounds via crafted function bodies. This may execute arbitrary code as the operating system user running the database. CVE-2026-6473 had fixed similar problems. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Heap buffer overflow in PostgreSQL pgstatstatements allows the query author to execute arbitrary code as the operating system user running the database, via crafted queries containing array constants. Within major version 18, minor versions before PostgreSQL 18.6 are affected. Versions before PostgreSQL 18 are unaffected.

PostgreSQL amcheck does not clear untrusted search path

PostgreSQL refint plan cache type confusion executes arbitrary code

Observable response discrepancy in PostgreSQL SCRAM authentication allows an unauthenticated user to test the existence of a user via observing the SCRAM iteration count. This requires the probed user to have a non-default scramiterations count, because the authentication challenge for a nonexistent user reports the default scramiterations. Within major versions 16-18, minor versions before PostgreSQL 18.6, 17.11, and 16.15 are affected. Versions before PostgreSQL 16 are unaffected.

Heap buffer overflow in PostgreSQL tochar(timestamptz) allows the party choosing the timezone to execute arbitrary code as the operating system user running the database, via a long POSIX timezone abbreviation. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Heap buffer overflow in PostgreSQL plperl return of a tied hash allows the function owner to execute arbitrary code as the operating system user running the database, via a crafted function body. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

PostgreSQL ctid type confusion in selectivity estimator discloses derivative of arbitrary read

Incomplete tracking in PostgreSQL of changes to role membership, role attributes, and database ownership allows a query to continue using cached row-level security policies after those changes require a different policy, via plan reuse. Stale policies continue until some other event invalidates the cache or connection termination ends the session. This permits a user to complete reads and modifications that were recently permitted but now forbidden. An attacker must tailor an attack to a particular application's pattern of privilege removal and role-specific row security policies. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.

Cleartext storage in PostgreSQL pgcrypto disabled ciphers allows a user to recover cleartext, via direct observation of the faulty ciphertext. The OpenSSL version and OpenSSL configuration determine the disabled ciphers. If the application accepts encrypted data as input, decryption will succeed even with the wrong key. This in turn loses the modest protection from the Modification Detection Code (MDC). Affected functions are pgpsymencrypt, pgpsymdecrypt, pgppubencrypt, pgppubdecrypt, pgpsymencryptbytea, pgpsymdecryptbytea, pgppubencryptbytea, and pgppubdecryptbytea. Versions before PostgreSQL 18.6, 17.11, 16.15, 15.19, and 14.24 are affected.