CVE-2026-102463: Eclipse Vert.x PostgreSQL Client DoS

CVE-2026-102463 Overview

CVE-2026-102463 affects the vertx-pg-client component of Eclipse Vert.x, a reactive toolkit for building asynchronous Java applications. The binary array decoder in DataTypeCodec.binaryDecodeArray allocates a Java array sized by a server-declared 32-bit dimension count without enforcing an upper bound [CWE-789]. A malicious PostgreSQL server, a compromised database, or an on-path attacker intercepting an unencrypted connection can send a crafted DataRow message with an excessively large array dimension value. The client then attempts a multi-gigabyte heap allocation and crashes with an OutOfMemoryError, causing denial of service for the application process.

Critical Impact
A single malformed DataRow response triggers unbounded heap allocation in the Vert.x PostgreSQL client, crashing the Java Virtual Machine (JVM) and taking down any dependent service.

Affected Products

Eclipse Vert.x vertx-pg-client versions 4.0.0 through 4.5.34
Eclipse Vert.x vertx-pg-client versions 5.0.0 through 5.0.12 and 5.1.0 through 5.1.9
Eclipse Vert.x vertx-pg-client version 5.2.0

Discovery Timeline

2026-10-15 - CVE-2026-102463 published to the National Vulnerability Database (NVD)
2026-10-20 - Last updated in NVD database

Technical Details for CVE-2026-102463

Vulnerability Analysis

The flaw resides in io.vertx:vertx-pg-client, specifically in DataTypeCodec.binaryDecodeArray. When the client receives a PostgreSQL DataRow message containing a binary-encoded array, the decoder reads a 32-bit integer representing the number of array dimensions. The decoder then uses this value directly to allocate a Java array without validating that the declared dimension count is reasonable. A hostile server can supply a value near Integer.MAX_VALUE, forcing the JVM to attempt an allocation measured in gigabytes. The resulting OutOfMemoryError terminates request processing and typically crashes the hosting process, producing a denial-of-service condition on availability.

Root Cause

The root cause is missing input validation on a size field controlled by a remote party, classified as Allocation of Resources Without Limits or Throttling [CWE-789]. The decoder trusts the untrusted length prefix sent by the PostgreSQL server rather than clamping it to a safe maximum or validating against the remaining buffer length.

Attack Vector

Exploitation requires that the Vert.x client connect to an attacker-controlled or compromised PostgreSQL server, or that the connection travel over an unencrypted channel subject to on-path interception. The attacker returns a crafted DataRow response during a legitimate query. No authentication to the Vert.x application is required because the client itself initiates the vulnerable parse. Attack complexity is elevated because the attacker must influence the database response path, but no user interaction is needed. Public technical details are available in the Eclipse Vert.x SQL Client Security Advisory GHSA-xqmh-8fhj-48fp.

Detection Methods for CVE-2026-102463

Indicators of Compromise

java.lang.OutOfMemoryError entries in application logs referencing io.vertx.pgclient or DataTypeCodec.binaryDecodeArray in the stack trace.
Sudden JVM termination or heap-dump generation on services that use vertx-pg-client to query PostgreSQL.
Unexpected PostgreSQL connections from Vert.x applications to hosts outside the approved database inventory.

Detection Strategies

Inventory Java applications for io.vertx:vertx-pg-client dependencies at the vulnerable versions using software composition analysis (SCA) tooling.
Correlate JVM crash events with recent PostgreSQL query activity to identify suspicious response patterns.
Monitor PostgreSQL wire traffic for DataRow messages that declare abnormally large array dimension counts.

Monitoring Recommendations

Alert on repeated OutOfMemoryError restarts in services that embed Vert.x, especially those correlated with new or unusual database endpoints.
Track outbound TCP connections from application tiers to ensure PostgreSQL traffic only reaches approved servers over Transport Layer Security (TLS).
Enable JVM garbage collection and heap allocation telemetry to surface anomalous multi-gigabyte allocation attempts.

How to Mitigate CVE-2026-102463

Immediate Actions Required

Upgrade io.vertx:vertx-pg-client to a fixed release above the affected 4.5.34, 5.0.12, 5.1.9, and 5.2.0 baselines as published in the vendor advisory.
Enforce TLS for all PostgreSQL connections to prevent on-path attackers from injecting malicious DataRow responses.
Restrict Vert.x applications to connect only to trusted, inventoried PostgreSQL servers via network segmentation and firewall rules.

Patch Information

Eclipse has published remediation details in the GitHub Security Advisory GHSA-xqmh-8fhj-48fp and the Eclipse GitLab CVE Assignment #345. Rebuild and redeploy all services that bundle the vulnerable client library, including transitive dependencies pulled in through frameworks such as Quarkus and Hibernate Reactive.

Workarounds

Require sslmode=verify-full on PostgreSQL connections and pin trusted certificate authorities to block on-path tampering.
Place Vert.x application tiers and PostgreSQL servers on isolated network segments with strict egress filtering.
Configure JVM options such as -XX:+ExitOnOutOfMemoryError combined with supervised process restarts to limit the blast radius while patching is in progress.

bash

# Configuration example: pin to a fixed vertx-pg-client version in Maven
# Replace <FIXED_VERSION> with a release above 5.2.0 per vendor advisory
mvn versions:use-dep-version \
  -Dincludes=io.vertx:vertx-pg-client \
  -DdepVersion=<FIXED_VERSION> \
  -DforceVersion=true