MariaDB patched CVE-2026-35549 on April 3, 2026. Seven weeks later, the fixed packages haven’t landed in the official repositories of RHEL 8, 9, and 10, Ubuntu LTS releases, or CentOS 8. If you’re running distro-packaged MariaDB and have the caching_sha2_password authentication plugin in use, your database server can be crashed by any authenticated user with a single oversized packet.

What the Bug Is

The vulnerability lives in the caching_sha2_password authentication plugin — MariaDB’s compatibility layer for the plugin MySQL 8.0 made default. When processing an authentication request, the plugin calls sha256_crypt_r, which allocates memory via alloca(). Unlike malloc(), alloca() grabs memory directly from the stack with no size check whatsoever. Feed it a packet that’s large enough, and the function attempts to allocate more stack space than exists, causing the server process to crash immediately.

The CVSS 3.1 score is 6.5 Medium (vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H). No data is leaked, nothing is modified — but availability impact is rated High, which is the right call: a crashed database takes down every application that depends on it until someone restarts the service. The underlying weakness is CWE-789, memory allocation with an excessive size value.

Who’s Actually Exposed

The trigger condition is specific: the caching_sha2_password plugin must be installed and at least one user account must be configured to use it. This narrows the exposure considerably compared to, say, an unauthenticated network bug.

Where does that condition appear in practice? The most common scenario is shops that migrated from MySQL 8.0 or MySQL 8.4 to MariaDB and carried their authentication configuration with them. MySQL 8.0 made caching_sha2_password the default authentication plugin, so any user created under it uses the plugin automatically. After a migration, those accounts land on MariaDB still carrying the same plugin specification — and MariaDB’s compatibility layer picks it up.

You can check whether you’re affected:

SELECT user, host, plugin
FROM mysql.user
WHERE plugin = 'caching_sha2_password';

If that query returns rows, you’re running the plugin with active accounts. You’re potentially affected.

The Distro Patching Gap

MariaDB’s own package repositories have carried the fix since the patched versions were released: 11.4.10 for the LTS branch, 11.8.6 for the 11.5–11.8 range, and 12.2.2 for the 12.x branch. Tracked in MDEV-38365.

The problem is that most hosting servers don’t install from MariaDB’s own repositories. They use whatever the OS vendor ships — and as of this writing, Tenable’s Nessus plugin 305108 explicitly flags RHEL 8/9/10, CentOS 8, Ubuntu 18.04 LTS through 25.10, and Azure Linux 3.0 as carrying unpatched MariaDB packages. Microsoft’s own CSAF advisory for Azure Linux 3.0 confirms that azl3 mariadb 10.11.16-1 has no fix available as of the advisory date. The NVD status for the CVE is still “Awaiting Analysis” — which doesn’t help the downstream packaging pipeline move any faster.

This is the real-world patch lag that security advisories rarely emphasize: upstream ships the fix, the CVE gets published, and then weeks pass while the distro maintainers triage, build, test, and push the updated package through their release process. In the meantime, apt upgrade and yum update do nothing to close the gap.

What to Do Now

Option 1 — Upgrade MariaDB from the official MariaDB repositories. If you need a patched package today, the fastest path is switching your repository source to mariadb.org and installing the fixed version directly. This is the cleanest fix.

Option 2 — Disable the plugin and switch authentication. If you’re not specifically relying on caching_sha2_password, migrate affected accounts to mysql_native_password (or ed25519 if you want something genuinely modern):

ALTER USER 'someuser'@'%' IDENTIFIED WITH mysql_native_password BY 'newpassword';
FLUSH PRIVILEGES;

Then uninstall the plugin:

UNINSTALL SONAME 'auth_caching_sha2_password';

Option 3 — Network-level restriction. If you can’t patch immediately, ensure that port 3306 is not reachable from untrusted hosts. This doesn’t fix anything but it does eliminate the remote attack vector. On a shared hosting server this is almost certainly already the case; on a VPS where you’ve opened MySQL to the internet for some reason, close it.

Option 4 — Monitor MariaDB crash logs. If exploitation is attempted, the server crashes. mysqld.err (or journalctl -u mariadb) will show a segmentation fault during the authentication phase. Set up alerting on unexpected MariaDB restarts.

There is no known active exploitation of CVE-2026-35549 at this time. The EPSS probability as of late May 2026 is 0.057% — very low. But “no current exploitation” and “no patch from your OS vendor” is an uncomfortable combination to sit with.

What This Means for kalfaoglu.net Customers

Our servers run MariaDB installed from the MariaDB project’s own repositories, not from OS vendor packages. We have already verified that the versions in production are at or above the patched thresholds. If you’re managing your own VPS or dedicated server with a shared hosting control panel that uses distro-packaged MariaDB, check which version you’re running with mariadb --version and compare against 11.4.10, 11.8.6, or 12.2.2 depending on your branch. If you’re on an older branch entirely (10.x, for instance), check the MariaDB security page for whether your branch is still receiving security fixes at all.

The vulnerability itself is medium severity, requires authentication, and has no confidentiality or integrity impact. It’s not a fire. But a database crash on a production server is never a minor inconvenience, and the fix has existed for seven weeks.