Still on MariaDB 10.6? Why your next upgrade is a security decision
Last week was about PHP. This week, check your database.
On 21 October 2026, the PHP project shipped emergency fixes for two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, known together as PHP2Shell. Exploit details leaked before the patch, attacks started within hours, and the only real fix was to upgrade PHP or shut down your website. Anyone running PHP 7 or earlier had no official patch at all.
If you run a hosting platform, you probably spent last week patching PHP. Good. Now look one layer down the stack. In most LAMP deployments the database sits right behind the web tier, holds the data attackers actually want, and gets upgraded far less often than PHP does.
MariaDB Community Server 10.6 reached end of life on 6 July 2026. Its final release, 10.6.28, shipped on 13 August 2026. There will be no 10.6.29. Every security fix published from now on lands in 10.11, 11.4, 11.8 and 12.3, and never in 10.6.
This post is for hosting providers and platform teams: what end of life means in practice, which versions are maintained and for how long, what kind of vulnerabilities are being fixed right now, and how to move to a current LTS without drama.
Which MariaDB versions are still maintained
Four Community LTS series are maintained today. Everything older, including 10.6, 10.5 and 10.4, no longer receives bug fixes, security fixes or corrective releases from the MariaDB Foundation.
| Series | GA date | Community EOL (Binary/Source) | Status today | Latest release |
| MariaDB 12.3 LTS | 29 May 2026 | 29 May 2029 / 2031 | Maintained | 12.3.3 |
| MariaDB 11.8 LTS | 4 Jun 2025 | 4 Jun 2028 / 2030 | Maintained | 11.8.9 |
| MariaDB 11.4 LTS | 29 May 2024 | 29 May 2029 | Maintained | 11.4.13 |
| MariaDB 10.11 LTS | 16 Feb 2023 | 16 Feb 2028 | Maintained | 10.11.19 |
| MariaDB 10.6 LTS | 6 Jul 2021 | 6 Jul 2026 | End of life | 10.6.28 (final) |
| MariaDB 10.5 LTS | 24 Jun 2020 | 24 Jun 2025 | End of life | 10.5.29 (final) |
Two things to notice. First, 11.8 reaches EOL before 11.4: from 11.8 onward MariaDB Server has yearly LTS releases with only three years of Community binaries, while 11.4 still has the older five year lifespan. Second, maintenance releases for all four series come out together, roughly quarterly, with corrective releases in between when a security issue needs it. The Q3 2026 round (12.3.3, 11.8.9, 11.4.13, 10.11.19) shipped on 24 August.
For a hosting platform, the practical choice is 11.8 or 12.3. 11.8 has been GA for over a year, is in Debian and Ubuntu LTS repositories, and is what most control panels now target. 12.3 is the newest LTS and the right choice if you are standardising now and want the longest runway. Both accept a direct upgrade from 10.6 with no intermediate step.
Sources:
MariaDB Server 10.6 Reaches End of Life on July 6th
Q3 2026 Maintenance Releases, and Goodbye 10.6
What is actually being fixed right now
2026 has been a busy year for MariaDB security fixes, and the pattern matters more than any single CVE: most of these flaws need only a low privileged database login. On a shared hosting platform, every customer and every WordPress plugin has one of those.
| Disclosed | CVE | CVSS | What it is | Fixed in (Community) |
| 16 Oct 2026 | CVE-2026-92262 | 9.9 | Legacy #mysql50# table name prefix bypasses filename encoding, allowing direct file access and potential RCE | 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3 |
| 16 Oct 2026 | CVE-2026-85746 | 9.9 | Heap write overflow in ST_AsText() on deeply nested GIS objects | 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3 |
| 16 Oct 2026 | CVE-2026-85748 | 9.9 | Use after free in SYS_REFCURSOR handling (12.3 and 13.0 only) | 12.3.3 |
| 16 Oct 2026 | CVE-2026-97380 | 8.8 | GRANT PROXY flaw lets a low privileged user change another account’s password | 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3 |
| 16 Oct 2026 | CVE-2026-86047 | 7.7 | Bad quoting in SHOW CREATE and mariadb-dump output can plant SQL that runs on restore | 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3 |
| 16 Oct 2026 | CVE-2026-85985 | 5.4 | CONNECT engine file functions skip the FILE privilege check | 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3 |
| Oct 2026 | CVE-2026-107823 (with 107814, 107815, 107818, 107821) | 7.2 | Crafted username smuggles view metadata into the parser, escalating privileges | 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3 |
| 2 Jun 2026 | CVE-2026-49261 | Critical | Command injection via wsrep_notify_cmd in Galera Cluster | 10.6.27, 10.11.18, 11.4.12, 11.8.8 |
| 2 Jun 2026 | CVE-2026-48165, CVE-2026-48163 | 8.0 | Unsafe parameter handling in Galera SST (donor and joiner side), OS command execution | 10.6.27, 10.11.18, 11.4.12, 11.8.8, 12.3.2 |
| 2 Jun 2026 | CVE-2026-44172 | High | Connector/C mysql_real_escape_string() bypass with big5 charset, SQL injection despite correct escaping | Connector/C 3.3.19, 3.4.9 |
| 20 Mar 2026 | CVE-2026-32710 | 8.6 | Heap buffer overflow in JSON_SCHEMA_VALID(), demonstrated as full RCE at ZeroDay.Cloud 2025 | 11.4.10, 11.8.6 |
The October set is the important one for this argument. 10.6.28 was the last Community 10.6 build and it did get those fixes, because it shipped on 13 August with the patches already in. That is the end of the line. The next corrective release, whenever it comes, will go to 10.11, 11.4, 11.8 and 12.3. A 10.6 server will stay vulnerable to whatever those corrections fix, permanently.
And a lot of 10.6 servers are not even on 10.6.28. A platform still on 10.6.21 or 10.6.24, which is common on hosting images that were built two years ago and never rebuilt, is already exposed to every item in the table above.
What the Galera entries show is a second point: these are not theoretical. CVE-2026-32710 came with a working exploit at a public contest. The PHP incident showed how fast leaked details turn into mass exploitation. A database CVE with a public proof of concept on a platform full of EOL instances is the same situation one layer down.
Sources:
MariaDB Community Server Corrective Releases
Security Vulnerabilities (CVE) Fixed in MariaDB Community Server
MariaDB security advisories on GitHub
Daily CyberSecurity on the October set
ZeroDay.Cloud on CVE-2026-32710
How the upgrade actually works
MariaDB supports upgrading directly from 10.6 to 11.8 or 12.3 in one step. No hop through 10.11 or 11.4 is needed. The data files are upgraded in place; there is no dump and reload. On a typical hosting node the downtime is the time it takes to stop the old server, swap packages and start the new one, usually a few minutes.
- Take a backup you have tested restoring. mariadb-backup or a consistent mariadb-dump. This is your rollback: a downgrade of in place upgraded data files is not supported.
- Read the two upgrade pages for your path: Upgrading from 10.6 to 11.4 (https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/upgrading/upgrading-to-11.4) and 11.4 to 11.8 (https://mariadb.com/docs/server/server-management/install-and-upgrade-mariadb/upgrading/upgrading-to-11.8) cover the incompatible changes between them.
- Clean my.cnf before you start the new binary. The usual suspects: innodb_change_buffering (removed in 11.x), innodb_log_write_ahead_size, and anything that referenced TokuDB or old authentication plugins. The 11.8 server ignores them, so while they won’t stop the server from starting, they won’t have any effect either.
- Fix COMPRESSED InnoDB tables. ROW_FORMAT=COMPRESSED has been read only since 10.6. Convert those tables to DYNAMIC with PAGE_COMPRESSED=1 before you move.
- Stop 10.6 cleanly, with innodb_fast_shutdown=1 or 0, but never a kill.
- 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.
- Start the new server and run mariadb-upgrade. On 11.x, the server runs it automatically on first start in most packaged installations; running it by hand is harmless and confirms the system tables are current.
- Check TLS. From 11.4 the server generates a certificate and clients use TLSby default.
- Retest the usual customer paths. WordPress, Laravel, Magento and phpMyAdmin all run on 11.8. The thing to test is your own control panel integration and any monitoring that parses SHOW STATUS output.
Galera users follow the same sequence node by node, with one note: in 12.3 Galera moves to a separate mariadb-server-galera package.
What still works: the wire protocol, the connectors, and the SQL that applications wrote against 10.6. The compatibility story from 10.6 to 11.8 is an application compatible upgrade. Applications keep running; the database underneath them stops being a liability.
Sources:
Upgrading from 10.6 to 11.8 (Enterprise guide, same steps for Community)
If you run a hosting platform: three things this week
MariaDB powers more WordPress sites than MySQL does, and WordPress core’s own numbers from 2025 showed over 37% of sites on a database version that had already reached end of life, 11% of them on EOL MariaDB. Since 6 July that EOL group includes every 10.6 install. Public software lists from large shared hosting providers still advertise MariaDB 10.6, and some still list MySQL 5.6 and 5.7, which have been unmaintained for years. The customers on those plans have no way to fix this themselves. Only the platform can.
- Find out what you are actually running. SELECT VERSION() across the fleet. If the answer is anything below 10.11, you are on an unmaintained server. If it is 10.6 and below 10.6.28, you are missing fixes for three CVSS 9.9 flaws published this month.
- Pick 11.8 or 12.3 and schedule it. Both are LTS, both upgrade directly from 10.6, both have years of maintenance ahead. If your policy is to avoid the newest LTS, 11.8 is maintained until June 2028 and is the version in Debian and Ubuntu LTS. If you want the longest runway from one migration, 12.3 runs to May 2029.
- Put the database on the same patch cadence as PHP. Maintenance releases land for all LTS series together, roughly every quarter, with corrective releases when a critical CVE needs one. Subscribe to the MariaDB Foundation newsletter (https://mariadb.org/newsletter/) and watch the GitHub security advisories (https://github.com/MariaDB/server/security) so a database CVE reaches your ops team the same day it reaches the attackers.
For hosting providers managing upgrades across a large fleet, some customer environments may need a longer transition period while continuing to meet security and contractual obligations. MariaDB plc offers commercial support options, including continued maintenance through MariaDB Enterprise Server 10.6, that can help providers manage that transition. Ralf Gebhardt outlines these options in his guide to the next steps after MariaDB Community Server 10.6 EOL.
The MariaDB Foundation exists to keep MariaDB Server open and maintained as a community project, and it works with hosting providers directly: on upgrade planning, on packaging for your platform, and on telling your success’ stories. If you are a hosting provider planning a move off 10.6 and want to talk it through, get in touch (https://mariadb.org/contact/). If you are already on 11.8 or 12.3, say so publicly. Your customers should know their data is on a maintained database.
Sources:
Leave a Reply