Vert.x 4.5.35 Fixes 12 CVEs, and Quarkus 3.40.1 Still Ships 4.5.34

Eclipse Vert.x fixed 12 vulnerabilities on 7 October 2026, in versions 4.5.35, 5.1.10 and 5.2.1. The CVE records were published on 15 October. Eight of the 12 are in Vert.x's clients for PostgreSQL, MySQL, SQL Server, DB2, Redis and MQTT, and they share one assumption: that the server on the other end is honest. The worst lets a fake DB2 server send serialized Java objects that the client deserializes. Two more affect any Vert.x WebSocket or gRPC server reachable from the internet.

This post is for Java teams that use Vert.x directly or through Quarkus, which builds on it. It covers what each bug needs, which ones matter for your setup, and a gap worth knowing about: the latest Quarkus release still pins Vert.x 4.5.34. It includes a script that checks a resolved dependency list, and a tested way to pull in the fixes before Quarkus ships them.

The short answer

Upgrade Vert.x to 4.5.35, 5.1.10 or 5.2.1. The 5.0 line has no fix release, so move to 5.1.10 or later. If you use Quarkus, the newest release on 15 October (3.40.1) still manages Vert.x at 4.5.34. Quarkus has merged the upgrade on its maintenance branches but hasn't released it, so either import the Vert.x 4.5.35 BOM ahead of Quarkus's or watch for the next patch release. Turn on TLS with certificate verification for every database, Redis and MQTT connection, because most of these bugs need a fake or intercepted server.

The 12 CVEs

All affect 4.0.0 to 4.5.34, every 5.0 release, and 5.1.0 to 5.2.0, except the HTTP proxy bug, which is 5.x only. Mike Read reported nine of them. Thomas Segismont, who signed off the fixes, found the two pre-login PostgreSQL and MySQL bugs, and Youngjoon Kim found the MQTT one.

Severity depends on where you read it. Vert.x's own GitHub advisories score them with CVSS 3.1, from 5.9 for the client bugs to 8.1 for DB2. The CVE records, from the Eclipse Foundation, use CVSS 4.0 and range from 8.2 to 9.2, which makes the DB2 bug "critical" in some feeds and "high" in others.

The DB2 bug: deserializing what the server sends

The DB2 client's DRDA code had a get_UDT() method that read column data tagged as a Java object (FDOCA type 0x50) with a plain ObjectInputStream.readObject(), with no filter or class allowlist. The fix commit explains that a real DB2 server never sends that type, so the code path was unreachable in normal use. A fake server, or anyone able to tamper with an unencrypted connection, could send one anyway. The bytes were deserialized on the event loop before any application code saw them.

The CVE record points out that TLS is off by default in the DB2 client. Whether that becomes code execution depends on what else is on your classpath, which is the usual story with Java deserialization. The fix removes the code and throws an IllegalStateException if that column type ever arrives.

The client bugs: trusting the server's numbers

The other database, Redis and MQTT bugs all come from reading a size or count from the server and acting on it without a ceiling. The PostgreSQL decoder accepted a message length up to Integer.MAX_VALUE and kept buffering. The MySQL and SQL Server decoders reassembled multi-packet messages with no total limit. The Redis parser and the MySQL column decoder allocated arrays as large as the server declared. The MQTT client stored every incoming QoS 2 message while it waited for a release packet that a hostile broker never sends.

Three of these work before authentication completes. Anything that can impersonate the server, such as a DNS or network position, a compromised host or a lookalike endpoint in a misconfigured environment, can crash the client without valid credentials. Because Vert.x runs many connections on a few event loop threads, an OutOfMemoryError takes down far more than one query.

For most teams these are lower priority than the server-side bugs. The database is usually trusted and on a private network. They matter more where an application connects to servers chosen by users or tenants, such as database tools, data integration services and multi-tenant platforms, or where traffic crosses networks without TLS.

The server bugs: compressed input

Two bugs face the internet directly. In vertx-core, WebSocket compression is supported by default on servers (perFrameWebSocketCompressionSupported and perMessageWebSocketCompressionSupported are both true in 4.5.35), and the frame and message size limits weren't applied to the decompressed data. A client could send a small compressed frame that inflates to far more than the 64 KB frame or 256 KB message default. The gRPC server had the same flaw, applying its 256 KB default maximum to compressed bytes.

If you can't upgrade straight away, turning WebSocket compression off on the server removes the decompression path. The JSON Schema bug is a CPU problem rather than memory: uniqueItems compares every pair of array items, so a moderately large array in a request body can tie up a thread. It reaches you through the OpenAPI router and web validation modules, as well as direct use.

Quarkus 3.40.1 still resolves Vert.x 4.5.34

Quarkus manages Vert.x versions in its BOM, so a Quarkus application gets whatever version that BOM names. We built a small project on the Quarkus 3.40.1 BOM, the latest on Maven Central on 15 October, with REST, the reactive PostgreSQL client, the Redis client and WebSockets Next, and resolved it with mvn dependency:list. Every Vert.x module came out at 4.5.34.

Quarkus merged pull requests on 9 October (3.40 and 3.33 branches) and 13 October (3.27) updating Vert.x to 4.5.35, and on 12 October updating its 4.0 development line to 5.1.10. None of those had shipped in a release when we checked.

Until one does, you can import the Vert.x BOM above Quarkus's. Maven uses the first import that manages a dependency, so this order wins:

<dependencyManagement>
  <dependencies>
    <!-- Vert.x 4.5.35 security fixes, until Quarkus ships them -->
    <dependency>
      <groupId>io.vertx</groupId>
      <artifactId>vertx-dependencies</artifactId>
      <version>4.5.35</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-bom</artifactId>
      <version>3.40.1</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

With that change, the same project resolved every Vert.x module at 4.5.35, and Netty moved from 4.1.138.Final to 4.1.139.Final, the same pairing as Quarkus's own merged update. We checked dependency resolution, not runtime behaviour. A patch release within the 4.5 line should be safe, but run your tests, and remove the override once Quarkus ships the update.

Check your dependency list

This script reads the output of mvn dependency:list, or any text with io.vertx coordinates such as a Gradle lockfile, and lists which affected modules you resolve and the version to move to. It uses only the standard library.

#!/usr/bin/env python3
"""Check a resolved dependency list against the October 2026 Vert.x CVEs.

Feed it the output of `mvn dependency:list` (or any text containing
io.vertx:<artifact>:...:<version> coordinates, such as a Gradle lockfile):

    mvn -q dependency:list -DoutputFile=deps.txt
    python3 vertx_oct2026_check.py deps.txt
"""
import re
import sys

JSON_SCHEMA = ["CVE-2026-102461 uniqueItems O(n^2) validation (CPU)"]
CVES = {
    "vertx-core": ["CVE-2026-102467 WebSocket decompression bomb"],
    "vertx-grpc-server": ["CVE-2026-102477 gRPC decompression bomb"],
    "vertx-pg-client": ["CVE-2026-103223 unbounded message length (pre-auth)",
                        "CVE-2026-102463 array dimension allocation"],
    "vertx-mysql-client": ["CVE-2026-103224 unbounded multi-packet reassembly (pre-auth)",
                           "CVE-2026-102466 column count allocation"],
    "vertx-mssql-client": ["CVE-2026-102462 unbounded TDS reassembly (pre-auth)"],
    "vertx-db2-client": ["CVE-2026-102469 Java deserialization of UDT column data"],
    "vertx-redis-client": ["CVE-2026-102465 RESP array allocation"],
    "vertx-mqtt": ["CVE-2026-102464 unbounded inbound QoS 2 retention"],
    "vertx-http-proxy": ["CVE-2026-102475 body transformer buffer limit (5.x only)"],
    "vertx-json-schema": JSON_SCHEMA,
    "vertx-openapi": JSON_SCHEMA,
    "vertx-web-openapi-router": JSON_SCHEMA,
    "vertx-web-validation": JSON_SCHEMA,
}
COORD = re.compile(r"io\.vertx:([\w.-]+):(?:[\w-]+:){0,2}?(\d+\.\d+\.\d+)")


def parse(v):
    return tuple(int(x) for x in v.split("."))


def affected(artifact, v):
    v = parse(v)
    if artifact == "vertx-http-proxy" and v < (5, 0, 0):
        return False
    return (4, 0, 0) <= v <= (4, 5, 34) or (5, 0, 0) <= v < (5, 1, 10) or v == (5, 2, 0)


def fixed_in(v):
    major_minor = parse(v)[:2]
    if major_minor[0] == 4:
        return "4.5.35"
    return "5.2.1" if major_minor >= (5, 2) else "5.1.10 (5.0.x has no fix release)"


found = {}
for line in open(sys.argv[1]):
    for artifact, version in COORD.findall(line):
        found[artifact] = version

hits = 0
for artifact, version in sorted(found.items()):
    if artifact in CVES and affected(artifact, version):
        hits += 1
        print(f"io.vertx:{artifact}:{version} -> upgrade to {fixed_in(version)}")
        for cve in CVES[artifact]:
            print(f"    {cve}")
others = sorted(a for a in found if a not in CVES)
print(f"\n{hits} affected Vert.x artifact(s); {len(others)} other Vert.x artifact(s) not named in the advisories")

On the Quarkus 3.40.1 project, then the same project with the override, then a fixture on Vert.x 5.0.12:

$ python3 vertx_oct2026_check.py quarkus-3.40.1-deps.txt
io.vertx:vertx-core:4.5.34 -> upgrade to 4.5.35
    CVE-2026-102467 WebSocket decompression bomb
io.vertx:vertx-pg-client:4.5.34 -> upgrade to 4.5.35
    CVE-2026-103223 unbounded message length (pre-auth)
    CVE-2026-102463 array dimension allocation
io.vertx:vertx-redis-client:4.5.34 -> upgrade to 4.5.35
    CVE-2026-102465 RESP array allocation

3 affected Vert.x artifact(s); 6 other Vert.x artifact(s) not named in the advisories

$ python3 vertx_oct2026_check.py quarkus-3.40.1-overridden-deps.txt

0 affected Vert.x artifact(s); 6 other Vert.x artifact(s) not named in the advisories

$ python3 vertx_oct2026_check.py fixture-5.0.txt
io.vertx:vertx-core:5.0.12 -> upgrade to 5.1.10 (5.0.x has no fix release)
    CVE-2026-102467 WebSocket decompression bomb
io.vertx:vertx-db2-client:5.0.12 -> upgrade to 5.1.10 (5.0.x has no fix release)
    CVE-2026-102469 Java deserialization of UDT column data
io.vertx:vertx-http-proxy:5.0.12 -> upgrade to 5.1.10 (5.0.x has no fix release)
    CVE-2026-102475 body transformer buffer limit (5.x only)
io.vertx:vertx-json-schema:5.0.12 -> upgrade to 5.1.10 (5.0.x has no fix release)
    CVE-2026-102461 uniqueItems O(n^2) validation (CPU)
io.vertx:vertx-web-openapi-router:5.0.12 -> upgrade to 5.1.10 (5.0.x has no fix release)
    CVE-2026-102461 uniqueItems O(n^2) validation (CPU)

5 affected Vert.x artifact(s); 0 other Vert.x artifact(s) not named in the advisories

The Quarkus result is typical. The application doesn't use DB2, gRPC or the HTTP proxy, so three modules matter: core for WebSockets, and the PostgreSQL and Redis clients.

What to do

1. Resolve your real dependency tree and run the check. Vert.x modules often arrive through frameworks, not your own pom.xml.
2. Upgrade to 4.5.35, 5.1.10 or 5.2.1. On 5.0, move to 5.1.10.
3. On Quarkus, import the Vert.x 4.5.35 BOM first, or upgrade as soon as the next 3.40, 3.33 or 3.27 patch release ships.
4. Turn on TLS with verification for database, Redis and MQTT connections, starting with DB2.
5. Don't rely on your scanner yet. On 15 October, GitHub's database held these as unreviewed advisories with no package mapped, so tools that read GitHub's reviewed data won't flag them until that changes. One CVE record also names the wrong module: CVE-2026-102465's text says vertx-mysql-client, but Vert.x's advisory and the description are about the Redis client.

The fair view

Most of these are denial-of-service bugs, and eight need you to connect to a server that is malicious or that someone has impersonated. In a typical deployment, a private database with TLS turned on, that's a high bar. The DB2 bug needs DB2 and a usable gadget chain to go beyond a crash. And Vert.x shipped all 12 fixes across three release lines on one day, with clear advisories.

The pattern is still worth taking from this. Client libraries tend to get less scrutiny than servers, because the server is assumed to be friendly. That assumption holds until the network, DNS or a tenant's configuration says otherwise. Size limits on what you read from a peer belong in clients as much as in servers.