Eclipse Vert.x MySQL client flaw causes denial of service

Eclipse Vert.x contains a high-severity flaw that allows attackers to crash applications via crafted database responses. Security teams must assess exposure immediately as the source material does not confirm a fix.

What happened

The National Vulnerability Database records CVE-2026-102466 with a CVSS score of 8.2. The issue resides within the io.vertx:vertx-mysql-client component of the Eclipse Vert.x framework. It affects versions 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9 and version 5.2.0.

The client pre-allocates an array for column definitions based on data sent by the MySQL server. The code performs no upper-bound validation on the declared column count. An attacker with man-in-the-middle positioning or control of a compromised MySQL server can exploit this.

They can send a crafted result set packet containing an extremely large column count. The client attempts a massive heap allocation to accommodate this data. This action triggers an OutOfMemoryError within the application runtime.

The error crashes the Netty event loop thread responsible for processing network events. This crash causes a complete denial of service for all active connections. It also halts all verticles running within the affected Vert.x application instance.

Why it matters

Organisations using Eclipse Vert.x for database connectivity face significant availability risks. The vulnerability requires no authentication on the client side to trigger the crash. Attackers only need to influence the data stream between the client and server.

The impact is total application unavailability rather than data theft. However, the resulting downtime can disrupt critical business services. The flaw exists in multiple major version branches of the framework. This suggests widespread potential exposure across different deployment environments.

Teams cannot rely on server-side protections alone to mitigate this risk. The client must validate incoming data before allocating memory. Until a fix is provided, any connection to an untrusted MySQL server is potentially vulnerable.

What happens next

• Inventory all systems running affected versions of io.vertx:vertx-mysql-client.
• Monitor application logs for OutOfMemoryError events related to Netty threads.
• Review network architecture to identify potential man-in-the-middle exposure points.
• Await official patch releases from the Eclipse Foundation for remediation.

Patch priority

Security teams usually prioritise systems with direct internet exposure or those connecting to untrusted databases. Check whether your architecture allows external attackers to inject crafted SQL responses. If no fix exists, consider isolating affected services from untrusted network segments. Back up application configurations before making any changes. Test any temporary mitigations in non-production environments first to avoid service disruption.

What to do and how to stay safe: Eclipse Vert.x

• Audit your dependency tree to identify if io.vertx:vertx-mysql-client is present in your build.
• Verify the specific version of Eclipse Vert.x in use against the affected ranges listed.
• Implement network segmentation to restrict MySQL client connections to trusted internal servers only.
• Monitor application health checks for sudden memory spikes or thread crashes indicating exploitation.

Step-by-step guide: Patch Management: Definition, Purpose and Operational Reality

General security guidance from the AppSec Scoop newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of Eclipse Vert.x are affected by CVE-2026-102466?

Versions 4.0.0 to 4.5.34, 5.0.0 to 5.0.12, 5.1.0 to 5.1.9 and 5.2.0 are affected.

Is there a patch available for this vulnerability?

The source material does not state whether a fix or patch is available.

What is the severity rating for CVE-2026-102466?

The National Vulnerability Database rates the vulnerability as HIGH with a CVSS score of 8.2.