MariaDB 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3: 10.6 EOL

MariaDB 10.6.28 Is the Final 10.6 Build #

10.6.28 is the last Community 10.6 release, shipped on 13 August 2026. The post states that it already carried the October fixes, because it shipped with those patches in. It is also explicit about what follows:

There will be no 10.6.29.

MariaDB.org

Every later security fix lands in 10.11, 11.4, 11.8 and 12.3, and never in 10.6, so a 10.6 server stays vulnerable to whatever those corrections fix. The post says this exposure is permanent. Not every 10.6 server is on 10.6.28, either: the post names 10.6.21 and 10.6.24 as common on hosting images built two years ago and never rebuilt, and says such platforms are already exposed to every item in the October records.

Shared Hosting Logins Reaching Database Files and Memory #

The post argues that most of these flaws need only a low privileged database login, and that on a shared hosting platform every customer and every WordPress plugin has one. It also cites WordPress core figures from 2025: over 37% of sites ran a database version that had already reached end of life, and 11% ran EOL MariaDB. Since 6 July, every 10.6 install falls into that EOL group.

CVE-2026-92262 (CWE-706, 9.9 CRITICAL, assigned by GitHub_M) concerns the legacy #mysql50# prefix, which lets a table name bypass normal filesystem encoding. Its record describes a low-privileged attacker reaching files under an unencoded legacy name, with crashes, data corruption, data exfiltration or remote code execution as outcomes. CISA's SSVC assessment, dated 21 October 2026, rates exploitation as none.

CVE-2026-85746 (CWE-787, 9.9 CRITICAL, assigned by GitHub_M) is a write beyond an output buffer in ST_AsText when it converts deeply nested GeometryCollections. The record says code execution is possible when combined with another vulnerability. CVE-2026-85748 (CWE-416, 9.9 CRITICAL, assigned by GitHub_M) is a use-after-free in SYS_REFCURSOR handling, which the record says can be triggered by opening a large number of cursors and fetching one.

CVE-2026-85985 (CWE-862, 5.4 MEDIUM, assigned by GitHub_M) affects the CONNECT file-access functions json_file(), bson_file(), jfile_make(), bfile_make() and jbin_file(). The record says they do not enforce the FILE privilege or secure_file_priv, so a low-privileged account can read or write files its database account is not authorized to access, subject to operating-system permissions.

Account Takeover and Privilege Escalation Through GRANT PROXY and View Metadata #

CVE-2026-97380 (CWE-620 and CWE-863, 8.8 HIGH, assigned by GitHub_M) is an authorization error in GRANT PROXY. An IDENTIFIED clause with an empty password is treated as if no authentication were specified, so the statement checks the wrong grantor's privileges. A low-privileged attacker who can name another account can set another account's password.

CVE-2026-107823 (CWE-116 and CWE-144, 7.2 HIGH, assigned by GitHub_M, published 9 October 2026) involves a username with embedded newline characters. An account with CREATE USER and CREATE VIEW WITH GRANT OPTION can create such a name, and the view FRM parser then reads part of it as security metadata, which can escalate database privileges. The post groups CVE-2026-107814, CVE-2026-107815, CVE-2026-107818 and CVE-2026-107821 with this record.

Restore Scripts and SHOW Output Carrying Injected SQL #

CVE-2026-86047 (CWE-89, 7.7 HIGH, assigned by GitHub_M) affects SHOW CREATE SERVER, SHOW CREATE USER and mariadb-dump, which do not consistently quote identifiers and values when they write SQL. A low-privileged attacker can plant crafted identifiers or values in an object that appears in SHOW output or a dump, and the generated SQL then carries injected statements that run when the poisoned output is applied. This suggests that a restore job replaying an affected dump is exposed in the same way as a session that reads the SHOW output.

Galera Cluster Command Injection and SST Flaws #

The post lists two Galera rows dated 2 June 2026, and it names no CVSS assigner for them. CVE-2026-49261 is command injection through wsrep_notify_cmd in Galera Cluster, rated Critical in the post. CVE-2026-48165 and CVE-2026-48163 are unsafe parameter handling in SST on the donor and joiner sides, leading to OS command execution, rated 8.0 in the post. The fixed release for the 10.6 line is 10.6.27.

The Galera rows name 10.6.27 and do not name 10.6.28, so the post alone does not settle whether a Galera node on 10.6.28 carries these fixes.

JSON_SCHEMA_VALID Overflow and Connector/C Escaping Bypass #

CVE-2026-32710 is a heap buffer overflow in JSON_SCHEMA_VALID(). The post rates it 8.6 without naming an assigner, and it is fixed in 11.4.10 and 11.8.6. The post's row is dated 20 March 2026 and describes it as demonstrated at full RCE at ZeroDay.Cloud 2025, and says it came with a working exploit at a public contest.

CVE-2026-44172 is a Connector/C bypass of mysql_real_escape_string() with the big5 charset, which allows SQL injection despite correct escaping. The post rates it High. Its fixed versions are Connector/C 3.3.19 and 3.4.9, which are connector releases rather than server releases.

Affected and Fixed MariaDB Versions in the October 2026 CVE Records #

Six of the seven October records list the 10.6, 10.11, 11.4 and 11.8 series; CVE-2026-85748 does not. The post says a 10.6 server below 10.6.28 is missing fixes for two of the three 9.9 flaws, as the records show. The post counts three, which suggests its count includes CVE-2026-85748, whose record lists 12.3 and 13.0 only.

The post's series table covers the four LTS series from 10.11 to 12.3, so the 13.0 row comes from the CVE records alone.

Also in this release #

Maintenance releases for the four current series ship together, roughly quarterly, with corrective releases in between when a security issue needs one.

• Q3 2026 maintenance round: 12.3.3, 11.8.9, 11.4.13 and 10.11.19, shipped on 24 August.
• 12.3 LTS: GA 29 May 2026; Community EOL 29 May 2029 (binary) and 2031 (source); latest release 12.3.3.
• 11.8 LTS: GA 4 Jun 2025; Community EOL 4 Jun 2028 (binary) and 2030 (source); latest release 11.8.9. From 11.8, LTS releases are yearly, with three years of Community binaries.
• 11.4 LTS: GA 29 May 2024; Community EOL 29 May 2029; latest release 11.4.13.
• 10.11 LTS: GA 16 Feb 2023; Community EOL 16 Feb 2028; latest release 10.11.19.
• 10.6 LTS: GA 6 Jul 2021; end of life 6 Jul 2026; final release 10.6.28.
• 10.5 LTS: end of life 24 Jun 2025; final release 10.5.29.
• Complete series table and release details: MariaDB.org post.

Choosing 11.8 or 12.3 as the Upgrade Target #

For a hosting platform, the post calls the practical choice 11.8 or 12.3. It describes 11.8 as GA for over a year, in the Debian and Ubuntu LTS repositories, and as the series most control panels now target; 11.8 is maintained until June 2028. It describes 12.3 as the newest LTS and the right choice for a platform standardising now that wants the longest runway, maintained until May 2029.

In-Place Upgrade Path Without a Dump and Reload #

MariaDB supports upgrading directly from 10.6 to 11.8 or 12.3 in one step, with no hop through 10.11 or 11.4. The data files are upgraded in place, so there is no dump and reload. On a typical hosting node, the post estimates the downtime as the time to stop the old server, swap packages and start the new one, usually a few minutes.

Because a downgrade of in-place upgraded data files is not supported, the backup in the first checklist step is the rollback the post names. According to the post, the wire protocol, the connectors and the SQL that applications wrote against 10.6 still work, which the post calls an application-compatible upgrade.

Upgrade Checklist #

1. Take a backup you have tested restoring, using mariadb-backup or a consistent mariadb-dump.
2. Read the upgrade pages for your path: Upgrading from 10.6 to 11.4 and 11.4 to 11.8. They cover the incompatible changes between them.
3. Clean my.cnf before the new binary starts. The post names innodb_change_buffering (removed in 11.x), innodb_log_write_ahead_size, and any settings that refer to TokuDB or old authentication plugins. The 11.8 server ignores them, so they do not stop startup, but they also have no effect.
4. Convert ROW_FORMAT=COMPRESSED InnoDB tables to DYNAMIC with PAGE_COMPRESSED=1 before the move. The post says these tables have been read-only since 10.6.
5. Stop 10.6 cleanly with innodb_fast_shutdown=1 or 0. Never kill the process.
6. Install the 11.8 or 12.3 packages from the MariaDB repositories or your distribution. Debian 13 and Ubuntu 26.04 carry 11.8 natively.
7. Start the new server and run mariadb-upgrade. On 11.x, most packaged installations run it automatically on first start, and running it by hand is harmless.
8. Check TLS. From 11.4 the server generates a certificate, and clients use TLS by default.
9. Retest your control panel integration and any monitoring that parses SHOW STATUS output. WordPress, Laravel, Magento and phpMyAdmin run on 11.8. Galera nodes follow the same sequence node by node; in 12.3, Galera moves to a separate mariadb-server-galera package.
10. Watch the GitHub security advisories for MariaDB so that database CVEs reach your operations team on the day they are published.

Checking Your MariaDB Version with SELECT VERSION() #

Run the query on every server in the fleet. A result below 10.11 means the server is on an unmaintained series. A 10.6 result below 10.6.28 falls inside the 10.6 affected range of the October records, and a result below 10.6.27 also lacks the Galera fixes listed for that release.

SELECT VERSION();