Ein einziges MySQL-Flag kann jahrelang unbemerkt Daten zerstören – und niemand merkt es, bis ein Kunde sich über kaputte Umlaute oder verschwundene Formular-Einträge beschwert. Genau dieses Szenario hat das WordPress-Core-Team dazu bewogen, mit WordPress 7.2 eine Änderung einzuführen, die auf den ersten Blick unscheinbar wirkt, in der Praxis aber stille Datenkorruption und Sicherheitslücken verhindert. Der neue WordPress 7.2 SQL-Modus deaktiviert automatisch NO_BACKSLASH_ESCAPES bei jeder Datenbankverbindung – ein Detail, das Entwickler kennen sollten, bevor die finale Version am 8. Dezember 2026 erscheint.
Dieser Artikel erklärt, was hinter der Änderung steckt, warum sie notwendig wurde, wer betroffen ist und welche konkreten Schritte Plugin-Autoren und Backend-Entwickler jetzt einplanen sollten.
Inhaltsverzeichnis
Key Takeaways
- WordPress 7.2 fügt NO_BACKSLASH_ESCAPES zur Liste der automatisch deaktivierten SQL-Modi in wpdb::set_sql_mode() hinzu.
- Ist der Modus auf Serverseite aktiv, interpretiert MySQL Backslashes als normale Zeichen statt als Escape-Zeichen – das führt zu doppelt gespeicherten Backslashes, SQL-Fehlern bei Apostrophen und geschwächtem Schutz vor SQL-Injection.
- Die Änderung betrifft ausschliesslich die WordPress-eigene Datenbankverbindung über wpdb, nicht die globale Serverkonfiguration.
- Eigene Datenbankverbindungen von Plugins (mysqli, PDO) sowie eigene db.php-Drop-ins profitieren NICHT automatisch von der Korrektur.
- Wer NO_BACKSLASH_ESCAPES bewusst benötigt, kann dies nur über den Filter incompatible_sql_modes in einer db.php-Drop-in-Datei zurückholen – normale Plugins greifen dafür zu spät.
Was bedeutet der neue WordPress 7.2 SQL-Modus konkret
Um die Tragweite zu verstehen, lohnt sich ein Blick auf die Funktion wpdb::set_sql_mode(). Sie läuft bei jeder Verbindung zur Datenbank und entfernt bestimmte SQL-Modi, die mit WordPress nicht kompatibel sind. Bisher standen sechs Modi auf dieser Liste:
- NO_ZERO_DATE
- ONLY_FULL_GROUP_BY
- STRICT_TRANS_TABLES
- STRICT_ALL_TABLES
- TRADITIONAL
- ANSI
Mit WordPress 7.2 kommt NO_BACKSLASH_ESCAPES als siebter Eintrag hinzu. Das Tracking-Ticket dazu ist #66185 auf core.trac.wordpress.org, dokumentiert in einem offiziellen Dev-Note vom 9. Oktober 2026 auf make.wordpress.org. Eine unabhängige technische Analyse auf attowp.com hat das Verhalten zusätzlich auf MySQL 8.0.46 überprüft und bestätigt die praktischen Auswirkungen.
Der WordPress 7.2 SQL-Modus ist damit kein neues Feature im klassischen Sinn, sondern eine defensive Härtungsmaßnahme: WordPress sorgt aktiv dafür, dass die eigene Datenbankverbindung immer in einem Zustand läuft, der zu den internen Escaping-Mechanismen passt – unabhängig davon, was der Hosting-Server global konfiguriert hat.
Warum NO_BACKSLASH_ESCAPES überhaupt ein Problem ist
WordPress nutzt den Backslash () als Escape-Zeichen, um Sonderzeichen in SQL-Queries sicher zu behandeln. Ein Apostroph in einem Benutzernamen, ein Anführungszeichen in einem Kommentar oder ein Backslash in einem Dateipfad – all das muss vor dem Einfügen in die Datenbank "entschärft" werden, damit die Query nicht abbricht oder missbraucht werden kann.
Ist der SQL-Modus NO_BACKSLASH_ESCAPES auf dem MySQL-Server aktiv, ändert sich das grundlegend: MySQL behandelt den Backslash dann als ganz normales Zeichen – nicht mehr als Steuerzeichen. Das klingt nach einer kleinen technischen Nuance, hat aber handfeste Folgen.
"Mit aktivem NO_BACKSLASH_ESCAPES schützen escapete Anführungszeichen nicht mehr zuverlässig vor SQL-Injection – ein stiller Sicherheitsverlust, der auf den ersten Blick nicht auffällt."
Die technische Analyse von attowp.com auf MySQL 8.0.46 hat drei konkrete Fehlerbilder identifiziert:
- Doppelte Backslashes als stille Datenkorruption. Werte, die WordPress vor dem Speichern escaped, werden mit verdoppelten Backslashes abgelegt. Das fällt oft erst Monate später auf, etwa wenn Pfadangaben oder Serialisierungen plötzlich nicht mehr korrekt gelesen werden.
- SQL-Syntaxfehler bei Apostrophen. Werte mit einfachen Anführungszeichen – etwa Namen wie "O'Brien" oder Texte mit typografischen Zeichen – führen zu fehlerhaften Queries, die ganz abbrechen können.
- Geschwächter Schutz vor SQL-Injection. Da escapete Anführungszeichen ihre schützende Wirkung verlieren, sinkt die Sicherheit von Queries, die sich auf dieses Escaping verlassen.
Zusätzlich funktionieren esc_like()-basierte LIKE-Abfragen mit aktivem NO_BACKSLASH_ESCAPES nicht mehr zuverlässig. Das betrifft typischerweise Suchfunktionen, Filterlogik in Plugins oder individuelle Admin-Reports, die auf Teilstring-Suche setzen.
Wie Websites ungewollt in diesen Modus geraten
Der Knackpunkt: WordPress selbst aktiviert NO_BACKSLASH_ESCAPES nicht. Das Problem entsteht, wenn Hosting-Provider oder Serveradministratoren diesen Modus auf Ebene der MySQL- oder MariaDB-Konfiguration serverseitig setzen – oft im Rahmen allgemeiner SQL-Mode-Presets, die für andere Anwendungen gedacht waren.
Für Website-Betreiber ist das besonders tückisch, weil es keine sichtbare Fehlermeldung im WordPress-Dashboard gibt. Stattdessen zeigen sich die Symptome schleichend: verfälschte Textinhalte, kaputte Serialisierungen in Postmeta-Feldern, fehlschlagende Formular-Einreichungen oder seltsame Suchresultate. Genau solche "schwer auffindbaren Datenbankprobleme" beschreibt auch der offizielle Dev-Note als Auslöser für die Änderung.
Was der WordPress 7.2 SQL-Modus NICHT abdeckt
Hier ist Präzision wichtig, denn die Reichweite der Änderung ist bewusst begrenzt. Die folgende Tabelle zeigt, was abgesichert ist und was nicht:
| Bereich | Durch WordPress 7.2 abgesichert | Hinweis |
|---|---|---|
| Globale Server-SQL-Modi | Nein | Serverkonfiguration bleibt unverändert |
| WordPress-Kernverbindung (wpdb) | Ja | set_sql_mode() entfernt NO_BACKSLASH_ESCAPES automatisch |
| Plugin mit eigener mysqli-Verbindung | Nein | Eigene Verbindung umgeht wpdb komplett |
| Plugin mit eigener PDO-Verbindung | Nein | Gleiches Problem wie bei mysqli |
| Plugins mit eigenem db.php Drop-in | Nein, sofern nicht angepasst | Muss manuell nachgezogen werden |
| SQL per addslashes() statt prepare() | Nein | addslashes() ist kein Ersatz für wpdb::prepare() |
Die meisten Websites werden laut Dev-Note keinen Unterschied bemerken, weil NO_BACKSLASH_ESCAPES bei den allermeisten Hosting-Setups ohnehin nicht aktiv ist. Für die Minderheit, bei der es doch der Fall ist, ist die Änderung jedoch hoch relevant.
Wer jetzt besonders genau hinschauen sollte
Vier Entwickler-Gruppen sollten den WordPress 7.2 SQL-Modus nicht ignorieren:
- Plugin-Autoren mit eigener Datenbankverbindung. Wer aus Performance- oder Architekturgründen eine eigene mysqli- oder PDO-Verbindung aufbaut, statt die globale $wpdb-Instanz zu nutzen, profitiert nicht automatisch von der Korrektur. Hier muss der SQL-Modus manuell geprüft und gegebenenfalls selbst korrigiert werden.
- Entwickler, die eigene sql_mode-Einstellungen setzen. Manche Plugins oder Frameworks setzen beim Verbindungsaufbau eigene SQL-Modi, etwa um bestimmte Legacy-Verhaltensweisen zu erzwingen. Das kann die WordPress-Korrektur wieder überschreiben.
- Teams mit eigenem db.php Drop-in. Wer bereits eine eigene db.php-Datei im wp-content-Verzeichnis betreibt, muss die neue Logik selbst integrieren, da WordPress die Datei nicht überschreibt.
- Code, der SQL per addslashes() statt wpdb::prepare() baut. addslashes() ist eine generische PHP-Funktion und kein MySQL-sicheres Escaping. Bei aktivem NO_BACKSLASH_ESCAPES versagt dieser Ansatz vollständig, unabhängig von der WordPress-Core-Korrektur.
Generell gilt: Je näher ein Plugin am WordPress-Standard bleibt und je konsequenter wpdb::prepare() für alle dynamischen Queries genutzt wird, desto automatischer profitiert der Code von der neuen Absicherung.
So funktioniert die Fix-Mechanik im Detail
Technisch greift die Änderung direkt in wpdb::set_sql_mode() ein. Bei jedem Verbindungsaufbau prüft WordPress die aktuell aktiven SQL-Modi und filtert die bekannten inkompatiblen Werte heraus, darunter nun auch NO_BACKSLASH_ESCAPES. Das Ergebnis: WordPress arbeitet intern immer mit einem SQL-Modus, der zum eigenen Escaping-Mechanismus passt – selbst wenn der Server global etwas anderes vorgibt.
Wichtig für alle, die den Modus aus triftigen Gründen dennoch beibehalten wollen – etwa wegen Kompatibilitätsanforderungen einer Drittanbieter-Integration: Der Filter incompatible_sql_modes erlaubt es, einzelne Modi von der automatischen Entfernung auszunehmen. Entscheidend ist dabei der richtige Ort für diesen Code.
WordPress baut die Datenbankverbindung auf, bevor Plugins und Must-Use-Plugins geladen werden. Das bedeutet: Code in einem normalen Plugin oder in einem Must-Use-Plugin greift schlicht zu spät, weil die Verbindung zu diesem Zeitpunkt bereits steht. Der einzige funktionierende Weg ist eine eigene db.php Drop-in-Datei im wp-content-Verzeichnis, die den Filter incompatible_sql_modes vor dem eigentlichen Verbindungsaufbau registriert.
Zeitplan bis zur finalen Version
Die Änderung ist Teil des regulären Release-Zyklus von WordPress 7.2. Der Feature Freeze fand bereits am 22. September 2026 statt, das heisst der Funktionsumfang steht fest und es folgen nur noch Fehlerkorrekturen. Der weitere Fahrplan sieht so aus:
| Meilenstein | Datum |
|---|---|
| Feature Freeze | 22. September 2026 |
| Beta 1 | 20. Oktober 2026 |
| Beta 2 | 27. Oktober 2026 |
| Beta 3 | 3. November 2026 |
| Beta 4 | 10. November 2026 |
| Release Candidate 1 | 17. November 2026 |
| Release Candidate 2 | 24. November 2026 |
| Release Candidate 3 | 1. Dezember 2026 |
| Finale Version | 8. Dezember 2026 |
Entwickler haben damit bis zur finalen Veröffentlichung noch ausreichend Zeit, eigene Plugins und individuelle Datenbankzugriffe auf Kompatibilität mit dem neuen WordPress 7.2 SQL-Modus zu prüfen – idealerweise bereits während der Beta-Phasen.
Praktische Schritte für Entwickler
Folgende Checkliste hilft bei der Vorbereitung auf die Umstellung:
- Prüfen, ob eigene Plugins eine eigene mysqli- oder PDO-Verbindung öffnen, statt $wpdb zu verwenden.
- Alle Stellen im Code identifizieren, die addslashes() statt wpdb::prepare() nutzen, und auf prepare() umstellen.
- Falls ein eigenes db.php Drop-in im Einsatz ist, prüfen, ob dort eigene sql_mode-Logik hinterlegt ist, die angepasst werden muss.
- Bei Bedarf, NO_BACKSLASH_ESCAPES beizubehalten, den Filter incompatible_sql_modes ausschliesslich in einer db.php Drop-in-Datei implementieren – nicht in einem regulären Plugin.
- Auf einem Staging-System mit MySQL und aktivem NO_BACKSLASH_ESCAPES testen, ob Formulare, Suchfunktionen und serialisierte Daten korrekt gespeichert und gelesen werden.
- Die Beta-Phasen von WordPress 7.2 nutzen, um Plugins frühzeitig gegen die neue Version zu testen.
Auch bei anderen WordPress-Updates lohnt ein genauer Blick auf Sicherheits- und Kompatibilitätsaspekte – etwa bei der Next.js-Sicherheitslücke CVE-2026-94483, die zeigt, wie schnell scheinbar kleine technische Details zu echten Risiken werden können.
Fazit und nächste Schritte
Der neue WordPress 7.2 SQL-Modus ist eine unscheinbare, aber wichtige Härtungsmaßnahme. Er löst ein Problem, das viele Websites nie bewusst wahrgenommen haben, weil sich stille Datenkorruption erst nach Monaten zeigt – wenn überhaupt. Für die Mehrheit der WordPress-Installationen ändert sich praktisch nichts, weil die zugrunde liegende Serverkonfiguration den Modus gar nicht aktiv hat.
Relevant wird die Änderung vor allem für Plugin-Autoren, die eigene Datenbankverbindungen pflegen, eigene SQL-Modi setzen oder noch mit addslashes() statt wpdb::prepare() arbeiten. Diese Entwickler sollten die verbleibende Zeit bis zur finalen Version am 8. Dezember 2026 nutzen, um den eigenen Code zu prüfen, Tests mit aktivem NO_BACKSLASH_ESCAPES durchzuführen und gegebenenfalls eine eigene db.php Drop-in-Datei mit dem Filter incompatible_sql_modes vorzubereiten. Wer jetzt handelt, vermeidet spätere, schwer nachvollziehbare Supportfälle und stellt sicher, dass Plugins auch unter restriktiven SQL-Modi zuverlässig funktionieren.
