CVE-2026-123488: SQL-Injection in Craft CMS

Unter der Kennung CVE-2026-123488 ist seit dem 6. November 2026 eine SQL-Injection-Lücke in Craft CMS registriert, die es in sich hat: Über den Such-Endpunkt für Elemente lässt sich laut CVE-Eintrag die Datenbank lesen und beschreiben – bis hin zum Setzen des Admin-Flags oder zum Überschreiben von Passwort-Hashes. Die CVE-vergebende Stelle VulnCheck bewertet das mit CVSS 3.1 9,8 und CVSS 4.0 9,3. Die gute Nachricht: Der Fix ist bereits seit dem 17. September in Craft CMS 4.18.9 und 5.11.2 enthalten. Wer seitdem aktualisiert hat, ist geschützt. Wer noch auf älteren Versionen sitzt, hat jetzt einen sehr konkreten Grund für ein Update.

Bemerkenswert ist, wie unterschiedlich die Quellen die Lücke einordnen. Craft selbst stuft sie als „high“ ein, VulnCheck als „critical“ – und bei der Frage, ob ein Login nötig ist, widerspricht sich sogar der Hersteller-Advisory.

Was hinter CVE-2026-123488 steckt

Craft CMS ist ein PHP-basiertes Content-Management-System, das vor allem bei Agenturen und für individuell gebaute Websites verbreitet ist. Das zugehörige GitHub-Advisory GHSA-qcvp-ggx3-97r6 trägt den Titel „SQL injection leading to privilege escalation“ und beschreibt den Mechanismus in wenigen Sätzen:

• Im Such-Endpunkt für Elemente wird der Parameter attribute ungefiltert in die Datenbankabfrage eingesetzt.
• Weil PDO mit emulierten Prepared Statements läuft, werden dabei auch gestapelte Abfragen („stacked statements“) ausgeführt – also mehrere SQL-Befehle hintereinander.
• Das ergibt laut Advisory Lese- und Schreibzugriff auf die Anwendungsdatenbank.

Die Folgen beschreibt der Hersteller ebenfalls konkret. Mit dem Schreibzugriff wurde das Admin-Flag des Nutzers mit der ID 1 in der Nutzertabelle gesetzt und durch Zurücklesen bestätigt. Weil Craft seine Rechteprüfung bei genau dieser Spalte abkürzt, waren keine weiteren Änderungen nötig, um Administratorrechte zu erlangen. Auf demselben Weg ließe sich der Passwort-Hash jedes Kontos überschreiben. Das Advisory trägt die interne Report-ID 1900; Credits für den Finder nennt es nicht.

Warum gerade die emulierten Prepared Statements so viel Gewicht haben: Bei echten Prepared Statements schickt PHP die Abfrage und die Werte getrennt an den Datenbankserver, gestapelte Befehle lassen sich so in der Regel nicht einschleusen. Bei der Emulation baut PDO die fertige Abfrage selbst als Text zusammen und übergibt sie in einem Stück. Gelangt ein ungefilterter Wert in diesen Text, kann ein Angreifer hinter einem Semikolon einen zweiten Befehl anhängen – etwa ein UPDATE auf die Nutzertabelle. Genau diese Kombination beschreibt das Advisory. Dass PDO beim MySQL-Treiber standardmäßig emuliert, ist seit Jahren bekannt und ein Grund, warum Framework-Code Parameter wie Spaltennamen streng gegen eine Positivliste prüfen sollte.

Angemeldet oder nicht? Ein Widerspruch im Advisory

Für Betreiber ist das die entscheidende Frage – und die Primärquellen beantworten sie nicht einheitlich. Die Kurzbeschreibung im Craft-Advisory GHSA-qcvp-ggx3-97r6 spricht von einer „authenticated SQL injection“, also einer Lücke, die eine Anmeldung voraussetzt. Im Abschnitt „Impact“ desselben Advisorys heißt es dagegen, die Injection gebe „unauthenticated read and write access“ auf die Datenbank.

Der CVE-Eintrag von VulnCheck (NVD-Eintrag CVE-2026-123488, zuletzt geändert am 6. November 2026) folgt der zweiten Lesart. Er beschreibt die Lücke ausdrücklich als „unauthenticated SQL injection“ und bewertet sie mit Privileges Required: None – Angriff über das Netzwerk, geringe Komplexität, keine Rechte und keine Nutzerinteraktion nötig. Daraus ergeben sich CVSS 3.1 9,8 und CVSS 4.0 9,3. Craft selbst hat im Advisory keine CVSS-Werte hinterlegt und listet den Fix im Changelog unter „high-severity permission escalation vulnerabilities“. Beides passt eher zu einem Szenario, in dem ein gewisser Zugang vorausgesetzt wird.

Stand 9. November 2026 (erneute Prüfung der Primärquellen): Craft hat den Widerspruch im Advisory nicht aufgelöst – die Kurzbeschreibung sagt weiterhin „authenticated“, der Impact-Abschnitt weiterhin „unauthenticated“. Der NVD-/CVE-Text ist unverändert bei „unauthenticated“. Welche Lesart stimmt, lässt sich aus den öffentlichen Unterlagen deshalb weiterhin nicht abschließend klären. Für die Praxis bleibt die vorsichtige Annahme die richtige: Wer verwundbare Versionen betreibt, sollte von einem Angriff ohne Login ausgehen.

Betroffene und gepatchte Versionen

Laut Advisory und CVE-Eintrag sind betroffen:

• Craft CMS 4.0.0 bis vor 4.18.9
• Craft CMS 5.0.0 bis vor 5.11.2

Beide Fix-Versionen sind laut den offiziellen Changelogs am 17. September 2026 erschienen. Sie schlossen nicht nur diese Lücke, sondern ein ganzes Bündel: In 4.18.9 listet Craft unter anderem eine weitere SQL-Injection (GHSA-mjj9-pjh4-r48g), eine RCE-Lücke (GHSA-9hp6-3565-gvh5), eine Informationspreisgabe und eine zweite Rechteausweitung – alle als „high“. In 5.11.2 kommen weitere Fixes hinzu, darunter eine zweite RCE-Lücke und mehrere Autorisierungsprobleme mittlerer und niedriger Schwere.

Die zeitliche Abfolge ist typisch für koordinierte Offenlegung: Patch am 17. September, Veröffentlichung des GitHub-Advisorys am 22. Oktober, CVE-Eintrag am 6. November. Aktuell ist in der 5er-Linie inzwischen Version 5.12.0.1 vom 3. November; die neueste 4er-Version im Changelog ist weiterhin 4.18.9.

Im KEV-Katalog der US-Behörde CISA, der aktiv ausgenutzte Lücken führt, steht CVE-2026-123488 nicht (Stand Katalog-Version 2026.11.06). Ein öffentlicher Exploit ist in den Primärquellen nicht verlinkt.

Was Craft-Betreiber jetzt tun sollten

1. Version prüfen. Im Control Panel (System Report unter „Utilities“) oder per composer show craftcms/cms. Alles unter 4.18.9 bzw. 5.11.2 ist verwundbar.
2. Aktualisieren. Mindestens auf 4.18.9 oder 5.11.2, besser auf den jeweils neuesten Stand der Linie. Da die Fix-Releases mehrere weitere Lücken schließen, lohnt das Update auch unabhängig von dieser CVE.
3. Nutzer prüfen. Die naheliegenden Spuren eines erfolgreichen Angriffs sind unerwartete Administratorkonten oder geänderte Passwörter. Als allgemeine Praxis – nicht als Vorgabe aus dem Advisory – empfiehlt sich ein Blick in die Nutzertabelle auf gesetzte Admin-Flags und verdächtige Änderungsdaten.
4. Logs auswerten. Auffällige Anfragen an den Such-Endpunkt mit ungewöhnlichen Werten im Parameter attribute können ein Hinweis sein.

Wer Hinweise auf eine Kompromittierung findet, sollte Passwörter zurücksetzen, Sitzungen beenden und – weil die Lücke Schreibzugriff auf die gesamte Datenbank erlaubt – Inhalte und Konfiguration gegen ein sauberes Backup abgleichen.

Einordnung

Die Lücke zeigt ein bekanntes Muster: Ein einzelner ungefilterter Parameter reicht, wenn die Datenbankschicht gestapelte Abfragen zulässt. Die Kombination aus emulierten Prepared Statements und String-Verkettung macht aus einer Leselücke eine Schreiblücke – und damit aus einem Datenleck eine Kontoübernahme. Ähnliche Probleme haben wir bei den SQL-Injection-Lücken im MariaDB-Connector für Node.js beschrieben. Für PHP-Entwickler ist auch der Fix im Symfony Serializer (CVE-2026-118515) lesenswert, und wie schnell CMS-Lücken in die Liste aktiv ausgenutzter Schwachstellen wandern können, zeigt der Fall des WordPress-Updaters im CISA-KEV.

Für Craft-Nutzer ist die Lage dennoch überschaubar: Der Patch ist seit fast acht Wochen verfügbar. Wer regelmäßig aktualisiert, muss nichts weiter tun. Wer das nicht tut, sollte jetzt nachziehen – bevor aus der neuen CVE-Nummer ein Eintrag im KEV-Katalog wird.