Cloudanix VulnDB

CVE-2026-119276

Medium · 5.9

CVSS

5.9

EPSS

0.4%

Published

Oct 29, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A flaw in the Java database connector lets a bad server trick the application into using huge amounts of memory, which can slow it down or make it crash.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
High
Impact
Denial Of Service
Component
Library
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Unbounded byte array allocations in OkPacket.parse() and parseWithInfo() using attacker-supplied lengths from OK packets before bounds validation, enabling repeated large heap allocations that trigger GC pressure or OutOfMemoryError.

Why it matters to the business

Client Java applications experience degraded performance or crashes, disrupting database-dependent services and requiring restarts or scaling adjustments; low EPSS and recent publication indicate limited active exploitation but still requires prompt attention for availability.

How an attack unfolds

An attacker acting as a malicious MariaDB/MySQL server or performing MITM intercepts the connection after CLIENT_SESSION_TRACK negotiation and sends a minimal OK packet declaring oversized lengths for info or session-state fields, forcing the client to allocate large byte arrays repeatedly until memory exhaustion occurs.

How to fix it

Upgrade MariaDB Connector/J to 3.3.7, 3.4.5, or 3.5.11 or later; disable CLIENT_SESSION_TRACK if upgrade is not immediately feasible.

How to confirm the fix worked

Verify connector version in pom.xml or jar manifests; test connectivity with a controlled server sending oversized OK declarations and confirm no excessive allocations or OOM.

Typical attack path

  1. Establish JDBC connection negotiating CLIENT_SESSION_TRACK
  2. Send crafted OK packet with small payload but large declared field lengths
  3. Trigger repeated allocations in parse paths before copy validation fails
  4. Induce cumulative heap pressure leading to OOM or GC thrashing

How to detect it

Search application and JVM logs for OutOfMemoryError or excessive GC activity occurring during database connection establishment or result processing; correlate with MariaDB Connector/J stack traces.

What your security team should do

  • Immediately upgrade all instances to fixed versions 3.3.7, 3.4.5, or 3.5.11
  • Review and restrict use of CLIENT_SESSION_TRACK in connection strings
  • Monitor Java heap metrics and GC logs for sudden spikes tied to database connections
  • Apply network controls to prevent MITM on database traffic

The record

MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.11, when CLIENT_SESSION_TRACK was negotiated, the OkPacket.parse() and OkPacket.parseWithInfo() paths allocated byte arrays using server-declared lengths for the OK packet info field and session-state variable names and values before confirming that the bytes remained in the packet. A malicious or compromised server, or a machine-in-the-middle attacker, could send a small OK packet declaring a much larger length and repeatedly force attacker-controlled heap allocations before the subsequent copy failed. This could create garbage-collection pressure or an OutOfMemoryError in the client application. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities