+61 2 9043 1246

Knowledge base

CVE-2026-85746: the MariaDB Server out-of-bounds write flaw, explained for website owners

Published · By , Co-Founder, BLACKBX

CVE-2026-85746 is a critical flaw in MariaDB Server, the database software, that lets someone with a low-level database login corrupt the server’s memory. It affects six release series before fixes MariaDB shipped in August and September 2026. No attacks are confirmed. Find out which database version your site runs and update it.

Key fact CVE-2026-85746
What An out-of-bounds write (CWE-787) in MariaDB Server’s ST_AsText feature, which turns stored map shapes into text.
Affected MariaDB Server 10.6.1 to 10.6.27, 10.11.1 to 10.11.18, 11.4.1 to 11.4.12, 11.8.1 to 11.8.8, 12.3.1 to 12.3.2, and 13.0.1. The fix versions themselves are not affected. Whether older or unlisted series are safe is not known.
Fixed in 10.6.28 (13 August 2026); 10.11.19, 11.4.13, 11.8.9 and 12.3.3 (24 August 2026); 13.0.2 (15 September 2026). Enterprise: 10.6.28-24, 11.4.13-10, 11.8.9-6 (7 September 2026). Latest stable today: 13.0.2.
Severity CVSS 3.1 score of 9.9, Critical, assigned by GitHub as the CVE issuer. MariaDB lists 9.9 too. NVD has not scored it yet.
Needs a login? Yes, but only a low-level database account, not an administrator.
Exploited? Not known. No confirmed attacks; one source reports public crash code from 18 October, another says none. Not on CISA’s KEV list according to two trackers.
Do now Ask whoever runs your server which MariaDB version your site uses, and have it moved to the fixed version in its series.

Facts checked on 21 October 2026 against copies of the CVE record at Vulners, OffSeq Radar, Strix and threatint, MariaDB’s release notes, change lists and Enterprise Server security page, Heart Internet, CVE Brief and TheHackerWire. Sources are listed at the end.

What is CVE-2026-85746?

MariaDB Server is database software. The official description calls it “a community developed fork of MySQL server”, which means it began as a copy of another well-known database and has been developed separately since. A database is the part of a system that stores information in an organised way so that software can look it up again later.

The flaw sits in a feature called ST_AsText. MariaDB can store map-style shapes, known as GIS data (geographic information system data: points, lines and areas). ST_AsText takes a stored shape and turns it into text. Shapes can be put into groups, and groups can sit inside other groups. When a group is nested very deeply inside other groups, ST_AsText goes wrong.

In plain terms, the database writes data past the end of the space it set aside for its answer. As it builds the text piece by piece, it does not keep track of how much room it has already used, and it does not reserve enough. The official classification is CWE-787, “Out-of-bounds Write”. CWE is a standard catalogue of software weakness types, and an out-of-bounds write means data spills into memory that belongs to something else.

The official title is “MariaDB: Out-of-bound buffer write on in ST_AsText of nested GeometryCollections”. MariaDB tracks it internally as bug MDEV-40329. Its bug tracker rates the issue “Blocker”, its highest priority, and lists it as closed. GitHub issued the CVE number, which was reserved on 4 September 2026 and published on 16 October 2026.

Who reported the flaw, and when, has not been published in any source we could check. The earliest date on record is the fix itself, written on 9 July 2026.

Do not confuse it with CVE-2026-85745 (MDEV-40328), a related bug in a different function called ST_Area. Two other MariaDB flaws rated 9.9, CVE-2026-85748 and CVE-2026-92262, were also published the same week. This post covers CVE-2026-85746 only.

Which versions are affected, and which are fixed?

For your site to be in scope, all of these must be true:

  1. Your website, or something it relies on, stores its data in MariaDB Server.
  2. That MariaDB is a version in one of these ranges:
    • 10.6.1 up to but not including 10.6.28
    • 10.11.1 up to but not including 10.11.19
    • 11.4.1 up to but not including 11.4.13
    • 11.8.1 up to but not including 11.8.9
    • 12.3.1 up to but not including 12.3.3
    • 13.0.1 (the only affected release in the 13.0 series)
  3. Someone who has a database account, even a low-level one, could misuse it.

The fixed versions, with the dates in MariaDB’s own documentation:

  • 10.6 series: 10.6.28, released 13 August 2026
  • 10.11 series: 10.11.19, released 24 August 2026
  • 11.4 series: 11.4.13, released 24 August 2026
  • 11.8 series: 11.8.9, released 24 August 2026
  • 12.3 series: 12.3.3, released 24 August 2026
  • 13.0 series: 13.0.2, released 15 September 2026

MariaDB Enterprise Server, the paid edition, is also covered. Its fixes are 10.6.28-24, 11.4.13-10 and 11.8.9-6, all released on 7 September 2026.

One point of confusion: the written description says “From 10.6.1 until 10.6.28”, which one tracking site has read as including 10.6.28. The official version list makes clear that each fix version is not affected.

Another: a press source, Heart Internet, says the fixes appear to be releases that shipped on 13 October, but it says it could confirm its dates from only one source. We have used MariaDB’s own dates.

What is not affected is less clear than it should be. No source says outright which versions are safe. Versions older than 10.6.1, and the series 11.0 to 11.3, 11.5 to 11.7 and 12.0 to 12.2, are simply not on the affected list. Whether that is because they are unaffected or because they are no longer supported is not known. If your database runs one of those, do not treat its absence from the list as a clean bill of health.

The newest stable release today is 13.0.2, labelled “Latest” on GitHub. Test versions 13.1.1 (a release candidate) and 13.2.0 (a preview) also exist; they are not meant for a live website. Whether anything newer came out after mid-September is not known. Whether Linux distributions such as Ubuntu and Debian have released their own fixed packages is also not known, and neither is how many servers run the affected versions.

If your site uses a MariaDB database and nobody has confirmed its version since August, assume you are in scope until someone checks the version.

Why this matters for a website owner

Someone with a basic database login can corrupt the memory of the database server. The public code reported by one source crashes the server outright. The official description adds that an attacker could “potentially achieve code execution when combined with another vulnerability”: in plain terms, running their own code on the server would need a second flaw as well.

If your website depends on that database, a crashed database means a website that cannot show its pages, take its orders or log anyone in. A database that has had its memory corrupted is not one you can fully trust until someone has looked at it.

Three things shape how serious this is:

  • A login is needed, but only a low-level one. Heart Internet describes these flaws as needing “a low-privileged database account rather than an administrator”. Any account that can send a shape to the database may be enough.
  • No interaction is needed. Nobody on your side has to click a link or open a file.
  • It can be reached over a network. The score treats it as attackable across a network and easy to carry out. Whether it can be reached through a website’s public pages, or only by someone connecting to the database directly, has not been published.

The score is CVSS 3.1 9.9 out of 10, rated Critical. CVSS is the standard scale used to rate how severe a vulnerability is. GitHub assigned the score as the issuer of the CVE number, and MariaDB lists the same 9.9 on its Enterprise Server security page. In plain terms, the score says: network reach, easy to do, a low-level login, no help from a user, and damage that can reach beyond the database itself with serious effects on data and service. The score assumes the worst realistic case, including the code execution that needs a second flaw.

NVD, the United States government’s vulnerability database, has not finished its analysis and has no score of its own yet. CISA, the US cyber security agency, has an entry for this CVE in its added-analysis programme, but its contents are not known. One tracking site labels the flaw “OS Command Injection”. That does not match the official type, which is an out-of-bounds write.

Is it being exploited?

Not as far as anyone has confirmed. Heart Internet says it “found no confirmed attacks”. TheHackerWire lists “No Known Campaign” for ransomware. Nobody has published who might be attacking, since when, or how many servers.

The sources disagree on whether attack code is public. Heart Internet says public code appeared on 18 October that “demonstrates a server crash”, and warns that “attackers may follow quickly”. TheHackerWire says “No Public PoC Detected”, though the date of its page is unclear. A PoC, or proof of concept, is code that shows a flaw can be triggered. We cannot tell you which report is right.

The flaw has an EPSS score of 0.00627 according to Vulners. EPSS is a statistical estimate of how likely a vulnerability is to be exploited, on a scale from 0 to 1.

It is not on CISA’s Known Exploited Vulnerabilities (KEV) catalogue, the US government list of flaws seen in real attacks, according to two sites that track it. We could not confirm that against CISA’s own catalogue today.

For an Australian site, the KEV list is a useful signal but not a safety certificate. It records attacks that have been seen, and it is maintained in the United States. A database that can be reached over a network can be reached from anywhere. If crash code is public, the realistic near-term risk is a site knocked offline, even if nothing more serious follows.

What should you do now?

In this order:

  1. Find out the version. Ask your host, your developer or whoever manages the server two questions: does my website use MariaDB, and which exact version? None of the sources we checked give owner-level instructions for this, so the person who runs the server is the right one to ask.
  2. Update. Move to the fixed version in your series: 10.6.28, 10.11.19, 11.4.13, 11.8.9, 12.3.3 or 13.0.2. For Enterprise Server, that is 10.6.28-24, 11.4.13-10 or 11.8.9-6. If your database runs a series that is not on either list, ask about moving to one that has received this fix. No workaround, such as switching the feature off, has been published, so the update is the fix.
  3. Check for trouble. Neither MariaDB nor any researcher has published signs of compromise. The only related fact is that the reported public code crashes the server. If your database has crashed or restarted without explanation since mid-October, tell whoever runs it.
  4. If something looks wrong, treat it as an incident rather than a glitch. Have a qualified person investigate before anyone assumes the server is clean, and keep a copy of anything they find. MariaDB has not published specific recovery steps.
  5. Record what you did: the version before, the version after, the date and who did it. If anything goes wrong later, this is the first thing anyone will ask for.
  6. Reduce exposure. The attack needs a database account. Ask for a list of who and what has a login to your database, and have any account that is no longer needed removed. Ask, too, whether the database can be reached from the open internet, and whether it needs to be.

If step one is already beyond what you can find out about your own website, that is the problem this blog exists to talk about. Skip to the bottom.

Why updating is not the whole fix

The fix for the 10.6 series has been out since 13 August 2026, and for most other series since 24 August. The CVE was not published until 16 October, and crash code was reported two days later. Any server still on an affected version today has been exposed for every one of those days, and has been exposed in public since 16 October.

The update stops the flaw from being triggered again. It does nothing about any crash or memory corruption that may already have happened, and it does nothing about the database accounts that make the attack possible. A low-level login that was misused before the update still works after it, until someone removes it or changes its password.

There is also the question of the second flaw. The worst case here needs this bug and another one together. Updating MariaDB closes this half. Whether the rest of the server is up to date is a separate question that the update does not answer.

Then there is the question nobody likes to ask: who is actually watching the site? The host looks after the server, but the database version may sit in a grey area depending on how the hosting is set up. The agency that built the site has moved on to other projects. The plugin updates, the database updates and the security advisories belong to no one in particular, so nobody reads them.

That is the pattern with most serious vulnerabilities. The fix arrives quietly, the public notice arrives weeks later, and the gap between the two is filled by whoever is actually watching the site.

What this looks like with BLACKBX

BLACKBX scans every site it looks after daily against published security advisories. When a client’s site matches a critical advisory like CVE-2026-85746, our developers patch it immediately; lower-severity items are done at the next service. Every update is dated and recorded in the client’s logbook, so the question “which version were we on, and when did it change?” always has an answer.

On the Monitor plan, the finding goes to the client’s own developer with the version numbers and our advice, so they can act on it. On Maintenance and Full service, BLACKBX does the work. All plans are monthly, with no minimum term.

Timeline

Date Event
9 July 2026 MariaDB writes the fix (MDEV-40329, revision 5c04ca5524)
13 August 2026 MariaDB 10.6.28 released with the fix
24 August 2026 MariaDB 10.11.19, 11.4.13, 11.8.9 and 12.3.3 released
4 September 2026 CVE-2026-85746 reserved by GitHub
7 September 2026 MariaDB Enterprise Server 10.6.28-24, 11.4.13-10 and 11.8.9-6 released
15 September 2026 MariaDB 13.0.2 released
13 October 2026 Release date given by Heart Internet, which conflicts with MariaDB’s own dates and rests on one source
16 October 2026 CVE published at 16:27 UTC; NVD entry appears the same day
17 October 2026 CVE Brief covers the flaw
18 October 2026 Heart Internet reports public proof-of-concept code that crashes the server
20 October 2026 Heart Internet’s weekly summary published (approximate date)
21 October 2026 This article published; no KEV listing known

Sources

Common questions

Is my website affected by CVE-2026-85746?

Only if the database behind your website runs MariaDB Server in an affected version: 10.6.1 to 10.6.27, 10.11.1 to 10.11.18, 11.4.1 to 11.4.12, 11.8.1 to 11.8.8, 12.3.1 to 12.3.2, or 13.0.1. Whether yours does depends on how the site is hosted, and it cannot be seen from the outside. BLACKBX scans every site it looks after daily against published advisories, so clients get that answer without having to ask.

Which MariaDB versions fix CVE-2026-85746?

CVE-2026-85746 is fixed in MariaDB 10.6.28 (13 August 2026), 10.11.19, 11.4.13, 11.8.9 and 12.3.3 (24 August 2026), and 13.0.2 (15 September 2026). Enterprise Server users need 10.6.28-24, 11.4.13-10 or 11.8.9-6, released 7 September 2026. When a BLACKBX client’s site matches a critical advisory like this one, our developers patch it immediately and record the update in the client’s logbook.

Is CVE-2026-85746 being exploited?

No attacks using CVE-2026-85746 have been confirmed as of 21 October 2026. One source reports public code from 18 October that crashes the server; another says no public code exists. Two trackers say it is not on CISA’s Known Exploited Vulnerabilities list. BLACKBX does not wait for attacks to be confirmed: a critical match on a client’s site is patched immediately.

Does CVE-2026-85746 need a password to exploit?

Yes, but only a low-level database account, not an administrator, and no user has to click anything. That is why it is rated 9.9 out of 10. Reviewing who has database logins is a sensible step alongside the update. On BLACKBX’s Maintenance and Full service plans, BLACKBX does that update work; on Monitor, the finding goes to your own developer with the version numbers and advice.

How do I check which MariaDB version my website uses?

None of the published sources on CVE-2026-85746 give owner-level instructions, so the simplest route is to ask your host or developer which database software your site uses and its exact version number. Ask them to put it in writing with the date. BLACKBX records every update, dated, in each client’s logbook, so that question always has an answer.

Is CVE-2026-85746 the same as CVE-2026-85745?

No. CVE-2026-85745 (MDEV-40328) is a related MariaDB bug in a different function, ST_Area. CVE-2026-85746 (MDEV-40329) is in ST_AsText. Two other 9.9-rated MariaDB flaws, CVE-2026-85748 and CVE-2026-92262, were published the same week. BLACKBX checks client sites against each published advisory separately, so nothing is assumed fixed because a neighbouring bug was.

Is this your site?

Do you know which database your website runs on?

Tell us your website address and we will tell you whether CVE-2026-85746 applies to it. If it does, we will fix it and record exactly what we did.

Ask us if this applies to you (opens in a new tab) Get these alerts by email (opens in a new tab)

Or call +61 2 9043 1246. Monthly plans, no minimum term.