Live › vulnerability › CVE-2026-119277
Connector/J decodes server packets using lengths the server declares without checking the bytes exist, so a malformed packet raises unchecked exceptions. The result is a terminated connection and failed JDBC calls, which a malicious server or a machine-in-the-middle can trigger.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-29 21:26 UTC. All times on this page are UTC.
Applications that use Connector/J to talk to MariaDB or MySQL servers, where the server could be untrusted or traffic could be intercepted. Exposure is mostly a denial of service on the connection; the sources do not describe code execution or data theft. Teams that only connect to a trusted, network-protected database server are lower risk but should still upgrade.
No product ranges from the sources yet.
Unknown from the sources.
3.3.7 on the 3.3 line3.4.5 on the 3.4 line3.5.11 on the 3.5 lineEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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, decoders for OK packet session-state blocks, column definition packets, text row data, or binary row data used server-declared lengths without confirming that the requested bytes remained in the receive buffer. The decoders could position reads, create sub-buffers, or decode strings beyond the packet boundary. A malicious or compromised server, or a machine-in-the-middle attacker, could trigger unchecked ArrayIndexOutOfBoundsException or IllegalArgumentException failures inside JDBC calls and terminate connection handling. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.
This page as .md · .json · in your agent: get_signal("CVE-2026-119277")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.