<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 16 Oct 2026 14:13:34 +0000</lastBuildDate>
    <item>
      <title>CLEANSTART-2026-MO09576 — Security fix for CVE-2026-55856 applied in: keycloak 26.5.7-r8</title>
      <link>https://db.gcve.eu/vuln/cleanstart-2026-mo09576</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: keycloak&lt;/p&gt;
&lt;p&gt;Security vulnerability affects the keycloak package. This issue is resolved in later releases. See references for vulnerability details.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: keycloak&lt;/p&gt;
&lt;p&gt;Security vulnerability affects the keycloak package. This issue is resolved in later releases. See references for vulnerability details.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cleanstart-2026-mo09576</guid>
    </item>
    <item>
      <title>fkie_cve-2026-55856</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-55856</link>
      <description>&lt;p&gt;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, when a Java application connects with sslMode=verify-full or sslMode=verify-ca, supplies a password, and does not configure serverSslCert or trustStore, Connector/J can accept an untrusted self-signed certificate through the fallbackToSystemTrustStore=true ephemeral trust manager and record its certFingerprint for later identity binding. The OK-packet and authentication-switch paths enforce the certificate fingerprint, but the initial-handshake path does not. HandshakeResponse.encode() can therefore build and send a mysql_clear_password response before checking certFingerprint != null &amp;amp;&amp;amp; !isMitMProof(), sslMode, or whether the authentication plugin is resistant to a man-in-the-middle, and the initial path also bypasses restrictedAuth. An active man-in-the-middle or hostile server can present a self-signed certificate, claim to be MariaDB, select mysql_clear_password as the initial authentication plugin, and receive the full database password before the connection is rejected. This issue is fixed in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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, when a Java application connects with sslMode=verify-full or sslMode=verify-ca, supplies a password, and does not configure serverSslCert or trustStore, Connector/J can accept an untrusted self-signed certificate through the fallbackToSystemTrustStore=true ephemeral trust manager and record its certFingerprint for later identity binding. The OK-packet and authentication-switch paths enforce the certificate fingerprint, but the initial-handshake path does not. HandshakeResponse.encode() can therefore build and send a mysql_clear_password response before checking certFingerprint != null &amp;amp;&amp;amp; !isMitMProof(), sslMode, or whether the authentication plugin is resistant to a man-in-the-middle, and the initial path also bypasses restrictedAuth. An active man-in-the-middle or hostile server can present a self-signed certificate, claim to be MariaDB, select mysql_clear_password as the initial authentication plugin, and receive the full database password before the connection is rejected. This issue is fixed in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-55856</guid>
    </item>
    <item>
      <title>GHSA-g9jj-cgmh-9f38 — MariaDB has cleartext password disclosure to a MITM on the initial-handshake</title>
      <link>https://db.gcve.eu/vuln/ghsa-g9jj-cgmh-9f38</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.mariadb.jdbc:mariadb-java-client&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;When a Java application connects with sslMode=verify-full (or verify-ca) and a password but does not pin a server certificate, Connector/J deliberately accepts an untrusted/self-signed certificate at the TLS layer (the &amp;#34;MITM-proof without a CA&amp;#34; feature) and proves the server&amp;#39;s identity afterwards by binding the certificate fingerprint into the authentication exchange. That fingerprint enforcement is applied to the OK-packet and auth-switch paths but not to the initial-handshake path. An active man-in-the-middle that presents a self-signed certificate, claims to be MariaDB, and names the initial authentication plugin mysql_clear_password receives the victim&amp;#39;s database password in cleartext, before any fingerprint/identity check runs. The connection is torn down a moment later, but the credential is already gone.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;For sslMode=verify-full/verify-ca with a password and no serverSslCert/trustStore, the connector falls back to an ephemeral trust manager (default fallbackToSystemTrustStore=true) that accepts any non-expired certificate at the TLS layer and records its fingerprint. Identity is then meant to be enforced via that fingerprint.&lt;/p&gt;
&lt;p&gt;The enforcement guard is present on two of the three paths, the OK-packet fingerprint check and the auth-switch handler (where the clear-password plugin is only allowed when the fingerprint is already verified). It is absent on the initial-handshake send: HandshakeResponse.encode() builds the mysql_clear_password respon…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: org.mariadb.jdbc:mariadb-java-client&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;When a Java application connects with sslMode=verify-full (or verify-ca) and a password but does not pin a server certificate, Connector/J deliberately accepts an untrusted/self-signed certificate at the TLS layer (the &amp;#34;MITM-proof without a CA&amp;#34; feature) and proves the server&amp;#39;s identity afterwards by binding the certificate fingerprint into the authentication exchange. That fingerprint enforcement is applied to the OK-packet and auth-switch paths but not to the initial-handshake path. An active man-in-the-middle that presents a self-signed certificate, claims to be MariaDB, and names the initial authentication plugin mysql_clear_password receives the victim&amp;#39;s database password in cleartext, before any fingerprint/identity check runs. The connection is torn down a moment later, but the credential is already gone.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;For sslMode=verify-full/verify-ca with a password and no serverSslCert/trustStore, the connector falls back to an ephemeral trust manager (default fallbackToSystemTrustStore=true) that accepts any non-expired certificate at the TLS layer and records its fingerprint. Identity is then meant to be enforced via that fingerprint.&lt;/p&gt;
&lt;p&gt;The enforcement guard is present on two of the three paths, the OK-packet fingerprint check and the auth-switch handler (where the clear-password plugin is only allowed when the fingerprint is already verified). It is absent on the initial-handshake send: HandshakeResponse.encode() builds the mysql_clear_password respon…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-g9jj-cgmh-9f38</guid>
    </item>
    <item>
      <title>RHSA-2026:83082 — Red Hat Security Advisory: Red Hat build of Quarkus 3.27.6 release and security update</title>
      <link>https://db.gcve.eu/vuln/rhsa-2026:83082</link>
      <description>&lt;p&gt;com.fasterxml.jackson.core/jackson-databind: tools.jackson.core/jackson-databind: Jackson-databind: Uncontrolled URI scheme resolution in Path deserialization org.mariadb.jdbc/mariadb-java-client: MariaDB Connector/J: Cleartext password disclosure via man-in-the-middle during initial handshake org.mariadb.jdbc/mariadb-java-client: MariaDB Connector/J: Information Disclosure via Insecure PAM Dialog Authentication org.mariadb.jdbc/mariadb-java-client: MariaDB Connector/J: Silent data corruption due to character set mismatch io.micrometer/micrometer-core: Micrometer Instrumentation for Apache HttpAsyncClient: Denial of Service via asynchronous request failures io.micrometer/micrometer-registry-statsd: io.micrometer/micrometer-core: Micrometer: Line-protocol and log injection via unsanitized input allows metric and log spoofing lz4-java: lz4-java: Denial of Service via insufficient validation in XXHash JNI implementations com.fasterxml.jackson.core/jackson-databind: tools.jackson.core/jackson-databind: jackson-databind: CPU Denial of Service via unbounded numeric parsing org.bouncycastle/bcpkix-jdk18on: org.bouncycastle/bcpkix-fips: org.bouncycastle/bcpkix-jdk15on: org.bouncycastle/bcpkix-lts8on: bouncycastle: Bouncy Castle: Certificate validation bypass via missing name constraint checks com.fasterxml.jackson.core/jackson-databind: tools.jackson.core/jackson-databind: jackson-databind: Path traversal via incomplete type validation org.apache.freemarker/freemarker: Apache FreeMa…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;com.fasterxml.jackson.core/jackson-databind: tools.jackson.core/jackson-databind: Jackson-databind: Uncontrolled URI scheme resolution in Path deserialization org.mariadb.jdbc/mariadb-java-client: MariaDB Connector/J: Cleartext password disclosure via man-in-the-middle during initial handshake org.mariadb.jdbc/mariadb-java-client: MariaDB Connector/J: Information Disclosure via Insecure PAM Dialog Authentication org.mariadb.jdbc/mariadb-java-client: MariaDB Connector/J: Silent data corruption due to character set mismatch io.micrometer/micrometer-core: Micrometer Instrumentation for Apache HttpAsyncClient: Denial of Service via asynchronous request failures io.micrometer/micrometer-registry-statsd: io.micrometer/micrometer-core: Micrometer: Line-protocol and log injection via unsanitized input allows metric and log spoofing lz4-java: lz4-java: Denial of Service via insufficient validation in XXHash JNI implementations com.fasterxml.jackson.core/jackson-databind: tools.jackson.core/jackson-databind: jackson-databind: CPU Denial of Service via unbounded numeric parsing org.bouncycastle/bcpkix-jdk18on: org.bouncycastle/bcpkix-fips: org.bouncycastle/bcpkix-jdk15on: org.bouncycastle/bcpkix-lts8on: bouncycastle: Bouncy Castle: Certificate validation bypass via missing name constraint checks com.fasterxml.jackson.core/jackson-databind: tools.jackson.core/jackson-databind: jackson-databind: Path traversal via incomplete type validation org.apache.freemarker/freemarker: Apache FreeMa…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/rhsa-2026:83082</guid>
    </item>
  </channel>
</rss>
