<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-01T11:51:50.651710+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-119276</id>
    <title>fkie_cve-2026-119276</title>
    <updated>2026-11-01T11:51:50.654483+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-119276"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-h599-m3w5-9m7x</id>
    <title>GHSA-h599-m3w5-9m7x — MariaDB Connector/J: Rogue server can drive large heap allocations from server-declared lengths in OK packets</title>
    <updated>2026-11-01T11:51:50.654593+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Maven: org.mariadb.jdbc:mariadb-java-client</p>
<p>## Summary</p>
<p>MariaDB Connector/J sized heap allocations from lengths declared by the server
in OK packets before checking that those lengths fit in the packet. A rogue or
MitM server can make the client allocate megabytes from a packet of a few bytes.</p>
<p>## Details</p>
<p>When `CLIENT_SESSION_TRACK` is negotiated (the default), an OK packet carries an
info field followed by session-state blocks, each tracked variable being sent as a
length-encoded name and value. `OkPacket.parse()` and `parseWithInfo()` allocated
`new byte[len]` for the info field, the variable name and the value with the
server-declared `len`, then copied the packet data into it. The copy failed with an
`ArrayIndexOutOfBoundsException` when the packet was shorter, but only after the
allocation had taken place.</p>
<p>A server-declared length of 8 MiB in an 18-byte packet was enough to trigger an
8 MiB allocation; the integer-range validation of length-encoded values does not
help, since such lengths are valid positive integers.</p>
<p>The fix validates every server-declared length against the remaining packet bytes
before any allocation (`ReadableByteBuf.checkLength()` and a bounded
`readBytes(int)`), and stops reading the session state at the first inconsistent
entry.</p>
<p>## Impact</p>
<p>Availability only: a malicious or compromised server, or a MitM, can drive
attacker-controlled heap allocations on every OK packet, creating GC pressure up to
`OutOfMemoryError` in the client application. Exploitation requires control of the
server si…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-h599-m3w5-9m7x"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ubuntu-cve-2026-119276</id>
    <title>UBUNTU-CVE-2026-119276</title>
    <updated>2026-11-01T11:51:50.654683+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:18.04:LTS: mariadb-connector-java, Ubuntu:20.04:LTS: mariadb-connector-java, Ubuntu:22.04:LTS: mariadb-connector-java, Ubuntu:24.04:LTS: mariadb-connector-java, Ubuntu:26.10: mariadb-connector-java, Ubuntu:26.04:LTS: mariadb-connector-java</p>
<p>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.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ubuntu-cve-2026-119276"/>
  </entry>
</feed>
