<?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://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T11:59:11.288316+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" 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://vulnerability.circl.lu/vuln/cleanstart-2026-gm04260</id>
    <title>CLEANSTART-2026-GM04260 — Security fix for CVE-2026-55858 applied in: keycloak 26.5.7-r8</title>
    <updated>2026-09-28T11:59:12.027496+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> CleanStart: keycloak</p>
<p>Security vulnerability affects the keycloak package. This issue is resolved in later releases. See references for vulnerability details.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cleanstart-2026-gm04260"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/fkie_cve-2026-55858</id>
    <title>fkie_cve-2026-55858</title>
    <updated>2026-09-28T11:59:12.027612+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. Prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9, the connector encodes and decodes protocol text and performs client-side escaping under the assumption that the connection character set is UTF-8. The server can report a mid-session change to character_set_client through OK-packet session-state tracking, including a change caused by SET NAMES, a stored routine or trigger, server configuration, or a hostile server. If character_set_client changes to a non-UTF-8 value, the driver continues to read and write UTF-8 while the server interprets the same bytes under another encoding, causing silent data corruption and a client/server charset-confusion mismatch that can defeat byte-wise quoting or escaping. The fix accepts only utf8, utf8mb3, or utf8mb4 after initialization; any other value causes SQLException with SQLState 08000 and closes the connection. This issue is fixed in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9.</p>
      </div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/fkie_cve-2026-55858"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-xvr9-35cr-46v9</id>
    <title>GHSA-xvr9-35cr-46v9 — org.mariadb.jdbc:mariadb-java-client has Inappropriate Encoding for Output Context</title>
    <updated>2026-09-28T11:59:12.027677+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>The connector encodes and decodes all character data assuming the connection character set is UTF-8. A server can change character_set_client mid-session to a non-UTF-8 charset, after which the driver and server interpret the same bytes under different encodings, causing silent data corruption and a client/server charset-confusion mismatch.</p>
<p>### Details</p>
<p>The driver encodes and decodes all character data on the assumption that the connection character set is UTF-8. 
Charset can be changed by commands like SET NAMES... commands.</p>
<p>If the new charset is not UTF-8, the driver continues to read and write UTF-8 while the server interprets the same bytes under a different encoding. The result is silent data corruption and a client/server charset-confusion mismatch. Charset confusion of this kind is also the primitive that can defeat byte-wise quoting/escaping when client and server disagree on a multi-byte encoding.</p>
<p>### Impact</p>
<p>Silent data corruption and a client/server encoding mismatch once the connection's charset diverges from UTF-8. Because the mismatch undermines the assumption that quoting/escaping operates on UTF-8 bytes, it belongs to the charset-confusion class that can lead to SQL injection.</p>
<p>### Patches</p>
<p>Fixed in 2.7.14, 3.3.5, 3.4.3, and 3.5.9. Upgrade to the patched release on your branch (3.5.x → 3.5.9, 3.4.x → 3.4.3, 3.0/3.1/3.2/3.3.x → 3.3.5, 2.x → 2.7.14). Once the connection is fully initialized, any subsequent charset change to a value that is not u…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-xvr9-35cr-46v9"/>
  </entry>
</feed>
