Last week was about PHP. This week, check your database.
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.
MariaDB security advisories on GitHub
Sources:
Galera 10.6 to 11.8
Which MariaDB versions are still maintained
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.
| 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) |
Sources:
CSA Singapore AL-2026-144
MariaDB Server 10.6 Reaches End of Life on July 6th
MariaDB Server 10.6 Reaches End of Life on July 6th
MariaDB Community Server Corrective Releases
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.
Maintenance Policy
ZeroDay.Cloud on CVE-2026-32710
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.
Galera users follow the same sequence node by node, with one note: in 12.3 Galera moves to a separate mariadb-server-galera package.
How the upgrade actually works
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.
- 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.
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.
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.
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.
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.
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.
MariaDB Health Checks plugin for WordPress
