MariaDB Schwachstellen: BSI-Advisory mit CVSS 10.0 im Galera-Cluster

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat am 12. Oktober 2026 den Sicherheitshinweis WID-SEC-2026-3856 veröffentlicht und darin mehrere MariaDB Schwachstellen als Risiko „hoch" eingestuft. Die Beschreibung nennt fünf Ziele, die ein Angreifer erreichen kann: beliebigen Programmcode ausführen, Privilegien erhöhen, einen Denial of Service herbeiführen, Informationen offenlegen und Sicherheitsvorkehrungen umgehen.

Admins erfahren daraus allerdings nicht, welche Versionen betroffen und welche Releases gepatcht sind. Der abgerufene Advisory-Text enthielt außer dem Titel „Warn- und Informationsdienst" keine weiteren Angaben — keine CVE-Liste, keine Versionsstände, keine CVSS-Werte. Genau diese Lücke entscheidet aber darüber, ob der eigene Datenbankstand gefährdet ist.

MariaDB Schwachstellen: Was das Advisory tatsächlich aussagt

WID-SEC-2026-3856 bleibt in dem abgerufenen Umfang bei der generischen Beschreibung der Angriffsklassen. Diese Knappheit ist kein Einzelfall: Schon 2022 listete ein BSI-Hinweis zu MariaDB unter der Kennung CB-K22/0171 „nicht näher spezifizierte Angriffe", ohne technische Details nachzuliefern. Die Formulierung ist damit ein wiederkehrendes Muster der BSI-MariaDB-Warnungen — und kein Beleg dafür, dass die Lücken harmlos wären.

Konkreter war ein früherer Hinweis aus dem Juni 2026: Die Warnung WID-SEC-2026-1744 trug ebenfalls das Risiko „hoch" und nannte ausdrücklich CVE-2026-48163. Zwischen dieser Meldung und dem aktuellen Advisory besteht ein thematischer Zusammenhang — ein belegter ist es nicht.

Galera-Cluster im Fokus: CVSS 10.0 und dreimal 8.0

Die belastbaren technischen Details stammen aus parallelen Quellen zur MariaDB-Update-Welle. Das CSA Singapore beschreibt in Advisory AL-2026-078 vier Schwachstellen im Umfeld des Galera-Clusters, also der Synchronisationsschicht für MariaDB-Replikation:

CVE-2026-49261 — CVSS 10.0. Ist wsrep_notify_cmd aktiviert, kann ein Angreifer Shell-Befehle im Namen eines beitretenden Knotens einschleusen und ausführen.
CVE-2026-48165 — CVSS 8.0. Betroffen sind die Systemvariablen wsrep_sst_receive_address und wsrep_sst_donor. Ein hochprivilegierter Datenbanknutzer kann darüber Shell-Befehle mit der UID des mariadbd-Prozesses auf dem Joiner-Knoten ausführen.
CVE-2026-48163 — CVSS 8.0. Beim State Snapshot Transfer kann ein bösartiger Joiner unvalidierte Parameter senden, die auf der Donor-Seite über die rsync-SST-Methode in die Kommandozeile interpoliert werden.
CVE-2026-44168 — CVSS 8.0. Derselbe Mechanismus über die mariabackup-SST-Methode.

Command Injection durch fehlendes Quoting

Die Analyse der SentinelOne-Schwachstellendatenbank zu CVE-2026-48165 ordnet die Lücke als OS Command Injection nach CWE-78 ein. Ursache ist demnach, dass die wsrep-Variablen ohne Quoting und ohne Escaping in Shell-Kommandostrings konkateniert werden. Ein Anführungszeichen in einer Konfigurationsvariablen genügt damit, um aus einer Option einen Befehlskanal zu machen.

Bemerkenswert ist die Kombination aus hohem Score und der Voraussetzung, dass ein Angreifer bereits privilegierten Datenbankzugang benötigt. Die Lücken sind damit vor allem für kompromittierte Konten und für Umgebungen mit geteilter Cluster-Infrastruktur gefährlich — nicht für den anonymen Angriff von außen.

Gepatchte Versionen: Wann MariaDB die Lücken schließt

Für die Galera-CVEs sind Fixes dokumentiert. Belegt sind die korrigierten Releases 10.6.27, 10.11.18, 11.4.12, 11.8.8 und 12.3.2. Die von MariaDB gepflegte CVE-Übersicht für den Community Server datiert die Fixes auf den 27. Mai 2026 für 11.8.8, 11.4.12, 10.11.18 und 10.6.27 sowie auf den 28. Mai 2026 für 12.3.2.

Wer einen Galera-Cluster betreibt, sollte den Versionsstand gegen diese fünf Releases prüfen. Für WID-SEC-2026-3856 selbst liegen keine Versions- oder Patchangaben vor. Ob die genannten Fixes die aktuelle Meldung abdecken, lässt sich aus dem Advisory nicht ableiten — die Zuordnung bleibt offen.

CVE-2026-32710 und die generische Meldepraxis des BSI

Neben den Galera-Lücken ist eine zweite MariaDB-Schwachstelle relevant: CVE-2026-32710 trägt einen CVSS-Score von 8.6. Ein authentifizierter Nutzer kann MariaDB 11.4 vor 11.4.10 und 11.8 vor 11.8.6 über einen Fehler in der Funktion JSON_SCHEMA_VALID() zum Absturz bringen. Der Angriff ist technisch einfach, die Wirkung auf einen produktiven Dienst erheblich.

Die drei Meldungen zusammengenommen zeigen ein Muster: Das BSI veröffentlicht bei MariaDB regelmäßig Hinweise mit dem Risiko „hoch", ohne die zugrunde liegenden CVEs zum Abrufzeitpunkt mitzuliefern. Betreiber müssen den Versionsstand deshalb aus den Herstellerangaben ableiten, nicht aus dem Advisory. Ob und in welchem Umfang Angreifer die Galera-Lücken bereits ausnutzen, ist aus keiner der vorliegenden Quellen belegbar — Hinweise auf Exploits oder Angriffe in freier Wildbahn finden sich dort nicht.

Fazit: Versionsstand prüfen statt auf Details warten

Admins sollten sich nicht an der schmalen Faktenlage von WID-SEC-2026-3856 orientieren, sondern an den belegten Fixes. Konkret: Wer MariaDB im Community-Zweig 10.6, 10.11, 11.4, 11.8 oder 12.3 betreibt, prüft, ob der Stand auf 10.6.27, 10.11.18, 11.4.12, 11.8.8 beziehungsweise 12.3.2 läuft. Ist er älter, bleibt das Update der wirksamste Schritt.

In Cluster-Umgebungen lohnt zusätzlich der Blick auf die Konfiguration. Da CVE-2026-49261 nur bei aktiviertem wsrep_notify_cmd greift, ist die Option ein naheliegender Härtungspunkt für Setups, die sie nicht benötigen — und wsrep_sst_*-Variablen sollten auf beiden Seiten des Transfers kontrolliert gesetzt sein. Dass ungeprüfte Konfigurationswerte in einer Shell landen können, ist kein Galera-spezifisches Problem, sondern taucht in der Geschichte von Datenbanksystemen immer wieder auf, weil die Grenze zwischen Konfiguration und Ausführung fließend bleibt. Solange der BSI-Hinweis keine vollständigen CVE-Angaben enthält, bleibt die Herstellerdokumentation die belastbare Quelle für Patchstände.

Quellen