vertx-pg-client EUVD-2026-101958

Exploitation requires the attacker to occupy a trusted data-path position: either (1) control over, or compromise of, the PostgreSQL server that the Vert.x application connects to, or (2) an on-path/man-in-the-middle position on an UNENCRYPTED (non-TLS) connection between vertx-pg-client and the database. The vulnerable code path is DataTypeCodec.binaryDecodeArray in vertx-pg-client, triggered when decoding a binary-format array column in a DataRow message; the attacker supplies an excessively large server-declared 32-bit array dimension count that is allocated without an upper bound. Limiting factors: no application-level authentication or user interaction is needed (PR:N/UI:N), but the requirement for DB-server control or MITM-on-plaintext is a substantial barrier (reflected as AC:H) - deployments using TLS to a trusted, operator-controlled database are largely insulated. Affected: Vert.x 4.0.0-4.5.34, 5.0.0-5.0.12, 5.1.0-5.1.9, and 5.2.0 using vertx-pg-client with binary array decoding.

This is a denial-of-service flaw (CVSS 4.0 8.2, VA:H with VC:N/VI:N - availability-only impact) in the vertx-pg-client binary array decoder. The input provides only a CVSS 4.0 vector; no EPSS score, KEV listing, or POC is present, so exploitation probability signals are absent rather than low. Exploitation status is 'no public exploit identified at time of analysis.' The headline 8.2 is driven by AV:N/PR:N/UI:N, but this overstates practical risk because the attacker is not an arbitrary remote party: per the description they must either control/compromise the PostgreSQL server the client talks to, or be an on-path (MITM) attacker on an UNENCRYPTED connection. The CVSS:4.0 vector correctly captures this friction with AC:H. In normal deployments the database is a trusted component reached over TLS, so the realistic attack surface is far narrower than AV:N alone implies. Net: this is a medium real-world priority for most deployments (patch in routine cycles; prioritize if you connect to untrusted/third-party Postgres instances or use unencrypted client-DB links). Note the signal tension: CVSS vector implies unauthenticated remote reach, but the written conditions require a privileged network/trust position - the AC:H metric is the reconciling factor and should be weighed heavily.

A Vert.x service connects to a PostgreSQL database that is attacker-controlled (e.g., a compromised or malicious third-party/multi-tenant DB), or an attacker sits on-path on an unencrypted (non-TLS) client-to-database link. The attacker returns a crafted DataRow for a binary array column declaring an enormous 32-bit dimension count, causing the client to attempt a multi-gigabyte heap allocation and crash with OutOfMemoryError, taking down the service. No public exploit code is identified at time of analysis.