<?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>Sun, 01 Nov 2026 18:27:16 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-119281</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-119281</link>
      <description>&lt;p&gt;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, the connector assumed result bytes were UTF-8 but guarded only changes to character_set_client. It did not reject non-UTF-8 character_set_results changes and relied on the server&amp;#39;s global session_track_system_variables configuration to report character-set changes. A malicious or compromised server, or a machine-in-the-middle attacker, could suppress tracking or change the result charset so application strings differed from the returned bytes, potentially defeating application-side validation or escaping that depended on the decoded values. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.&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. From 3.0.0 until 3.3.7, 3.4.5, and 3.5.11, the connector assumed result bytes were UTF-8 but guarded only changes to character_set_client. It did not reject non-UTF-8 character_set_results changes and relied on the server&amp;#39;s global session_track_system_variables configuration to report character-set changes. A malicious or compromised server, or a machine-in-the-middle attacker, could suppress tracking or change the result charset so application strings differed from the returned bytes, potentially defeating application-side validation or escaping that depended on the decoded values. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-119281</guid>
    </item>
    <item>
      <title>GHSA-grfq-r75j-rw9x — MariaDB Connector/J: Server could switch character_set_results away from UTF-8 without the client noticing</title>
      <link>https://db.gcve.eu/vuln/ghsa-grfq-r75j-rw9x</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;MariaDB Connector/J decodes every result as UTF-8 and guards
`character_set_client` against a change to another charset, but did not guard
`character_set_results`, and relied on the server&amp;#39;s global
`session_track_system_variables` list to be told about charset changes at all.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;The connector learns about session variable changes through session tracking,
and closes the connection when `character_set_client` is switched away from UTF-8,
so that its UTF-8 decoding stays correct. Two gaps remained:&lt;/p&gt;
&lt;p&gt;- `character_set_results` was not guarded: a server could switch it to another
  charset, after which the bytes of every result were decoded as UTF-8 although
  encoded otherwise.
- the list of tracked variables came from the server&amp;#39;s global
  `session_track_system_variables`: a server configured, or made, not to track
  the character set variables could change them silently.&lt;/p&gt;
&lt;p&gt;The fix requests an explicit session tracking list that includes both character
set variables whatever the server&amp;#39;s global setting, and closes the connection
when `character_set_results` is changed to a charset other than `utf8`, `utf8mb3`
or `utf8mb4`, as it already did for `character_set_client`.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;Integrity: a malicious or compromised server, or a MitM, can make the strings an
application reads differ from the bytes the server returned (inappropriate
encoding for the output context), which can defeat application-side validation
or escaping built on those values. Exploitation…&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;MariaDB Connector/J decodes every result as UTF-8 and guards
`character_set_client` against a change to another charset, but did not guard
`character_set_results`, and relied on the server&amp;#39;s global
`session_track_system_variables` list to be told about charset changes at all.&lt;/p&gt;
&lt;p&gt;## Details&lt;/p&gt;
&lt;p&gt;The connector learns about session variable changes through session tracking,
and closes the connection when `character_set_client` is switched away from UTF-8,
so that its UTF-8 decoding stays correct. Two gaps remained:&lt;/p&gt;
&lt;p&gt;- `character_set_results` was not guarded: a server could switch it to another
  charset, after which the bytes of every result were decoded as UTF-8 although
  encoded otherwise.
- the list of tracked variables came from the server&amp;#39;s global
  `session_track_system_variables`: a server configured, or made, not to track
  the character set variables could change them silently.&lt;/p&gt;
&lt;p&gt;The fix requests an explicit session tracking list that includes both character
set variables whatever the server&amp;#39;s global setting, and closes the connection
when `character_set_results` is changed to a charset other than `utf8`, `utf8mb3`
or `utf8mb4`, as it already did for `character_set_client`.&lt;/p&gt;
&lt;p&gt;## Impact&lt;/p&gt;
&lt;p&gt;Integrity: a malicious or compromised server, or a MitM, can make the strings an
application reads differ from the bytes the server returned (inappropriate
encoding for the output context), which can defeat application-side validation
or escaping built on those values. Exploitation…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-grfq-r75j-rw9x</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-119281</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-119281</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;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, the connector assumed result bytes were UTF-8 but guarded only changes to character_set_client. It did not reject non-UTF-8 character_set_results changes and relied on the server&amp;#39;s global session_track_system_variables configuration to report character-set changes. A malicious or compromised server, or a machine-in-the-middle attacker, could suppress tracking or change the result charset so application strings differed from the returned bytes, potentially defeating application-side validation or escaping that depended on the decoded values. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;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, the connector assumed result bytes were UTF-8 but guarded only changes to character_set_client. It did not reject non-UTF-8 character_set_results changes and relied on the server&amp;#39;s global session_track_system_variables configuration to report character-set changes. A malicious or compromised server, or a machine-in-the-middle attacker, could suppress tracking or change the result charset so application strings differed from the returned bytes, potentially defeating application-side validation or escaping that depended on the decoded values. This issue is fixed in versions 3.3.7, 3.4.5, and 3.5.11.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-119281</guid>
    </item>
  </channel>
</rss>
