MariaDB CVE-2026-92262 rated 9.9; fixed builds out since August 24

MariaDB has two critical bugs with public CVE records as of October 16, 2026, and the fixes for both shipped in August. CVE-2026-92262 is the one web servers should care about first: a CVSS 3.1 score of 9.9, no workaround, and an attack that needs only a database login allowed to create tables. The second, CVE-2026-85746, also scored 9.9, is an out-of-bounds write in the ST_AsText GIS function. On October 18 the exploit index Sploitus listed a proof-of-concept repository that claims to cover both. We have not seen that confirmed by a second source, and neither CVE is in CISA's Known Exploited Vulnerabilities catalog.

How the #mysql50# prefix bypasses filename encoding

MariaDB stores each table as files on disk and encodes any characters in the table name that are unsafe in a filename. A table called a-b is stored as a@002db. MySQL 5.0 and earlier did not encode names, so MariaDB still accepts a #mysql50# prefix that tells the server to use the raw name and reach tables created before encoding existed.

MariaDB's advisory (GHSA-65jj-h265-3m7h) says a #mysql50# name maps straight to the unencoded files. The bug report, MDEV-40362, shows the server's table cache confusing a table named #mysql50#t with a separate table named t and returning rows from the wrong one. The advisory lists the possible results as crashes, data corruption, data exfiltration and remote code execution. The CVSS vector marks the scope as changed, which means a successful attack affects resources beyond the database account the attacker started with. Ben Bidner of the Automattic security team reported the bug.

Fixed versions by branch

Every community branch from 10.6.1 onward is affected. The fixed community releases are:

• 10.6.28, released August 13, 2026
• 10.11.19, 11.4.13, 11.8.9 and 12.3.3, released August 24, 2026
• 13.0.2, released in mid-September 2026

The 11.4.13 release notes list 17 CVEs fixed in that build, and the CVE-2026-85746 advisory points to the same set of releases. Enterprise Server customers need 10.6.28-24, 11.4.13-10 or 11.8.9-6. The 10.6 branch left community support on July 6, 2026, so a server still on 10.6 should be patched now and moved to 10.11 or 11.4 soon after.

Two months between the fix and the CVE

• July 13, 2026: MDEV-40362 opened
• July 22: fix committed and the issue closed
• August 13 and 24: fixed releases published
• September 7: GitHub security advisory published
• October 16: CVE records published

Vulnerability scanners and distribution trackers key on CVE IDs, so servers that looked clean through September are only now being flagged as critical. Meanwhile the fix commits have been public on GitHub since the August releases at the latest, which gives anyone reading them a head start on administrators who wait for scanner alerts.

Accounts that can trigger the bug

The CVSS vector requires low privileges: a valid login with rights to create tables. On a typical web server that describes nearly every application account. WordPress, Drupal, Magento and Laravel all run schema changes during installs and updates, so their database users normally hold CREATE, ALTER and DROP. Anyone who reads those credentials out of wp-config.php or a Laravel .env file, through a plugin file-read bug or a backup left in the web root, has what the attack needs.

Shared hosting raises the stakes. Every customer with a database account on a shared MariaDB server can attempt this against the other tenants on that server. A phpMyAdmin or Adminer install reachable from the internet hands the same opportunity to anyone holding a working password.

Distribution packages lag behind upstream

If MariaDB comes from your operating system rather than from MariaDB's own repositories, check the package version, not the date of your last update. On October 19, Debian's security tracker still listed Debian 13 (trixie) as vulnerable, with the stable package at 11.8.6. Debian 12's security repository carries 10.11.19, the fixed upstream release, though the tracker had not yet marked it fixed. Servers that install from MariaDB's own repositories receive the fixed builds through a normal package update.

Checking and upgrading a server

Confirm the version of the running server. A package upgrade without a restart leaves the old binary in memory.

mariadb -e "SELECT VERSION();"

# Debian and Ubuntu
apt list --installed 'mariadb-server*'

# RHEL, AlmaLinux, Rocky
rpm -qa | grep -i mariadb-server

Take a fresh dump, then upgrade, restart and run the upgrade tool:

# Debian and Ubuntu
apt update && apt install --only-upgrade mariadb-server

# RHEL family (package names differ between distro and MariaDB repos)
dnf upgrade 'mariadb*' 'MariaDB-*'

systemctl restart mariadb
mariadb-upgrade

Then list any databases or tables the server knows only by a legacy name:

SELECT schema_name FROM information_schema.schemata
 WHERE schema_name LIKE '#mysql50#%';

SELECT table_schema, table_name FROM information_schema.tables
 WHERE table_name LIKE '#mysql50#%';

A hit is not proof of an attack. A data directory mounted as its own filesystem commonly shows a #mysql50#lost+found database, and very old installs may carry legacy table names. Anything else deserves a look at when it was created and which account created it. mariadb-check has --fix-db-names and --fix-table-names options that convert legacy names to the encoded form; run them only after a backup, since applications that reference the old names will break.

Reducing exposure before the upgrade window

• Set bind-address = 127.0.0.1 (or a private interface) in the [mysqld] section and confirm port 3306 is closed to the internet.
• Put phpMyAdmin and Adminer behind a VPN, an IP allow list or HTTP authentication.
• Rotate the database password for any site that has had a file-read bug, a leaked backup or a malware cleanup this year.

MariaDB states there is no workaround other than upgrading. These steps narrow who can log in to the database, but only the fixed release closes the bug.