CVE-2026-19949: SQL-Injection im Backup-Plugin All-in-One WP Migration bedroht Millionen WordPress-Seiten

Kurzfassung: Eines der meistinstallierten Backup-Plugins im WordPress-Ökosystem hat ein ernstes Problem. In All-in-One WP Migration and Backup des Herstellers ServMask steckt bis einschließlich Version 7.109 eine unauthentifizierte SQL-Injection, die als CVE-2026-19949 geführt wird. Das Besondere: Der Angriff läuft in zwei Akten. Der Angreifer legt seinen Schadcode ohne jede Anmeldung über WordPress-Trackbacks in der Datenbank ab. Dort passiert erst einmal gar nichts. Ausgelöst wird die Injection erst später, wenn ein Administrator ein Backup wiederherstellt. Genau das ist der Zweck eines Backup-Plugins, der Auslöser kommt also zwangsläufig. Am Ende der Kette steht die vollständige Übernahme der Website inklusive Codeausführung auf dem Server. Dieser Beitrag erklärt verständlich, wie der Angriff funktioniert, wer betroffen ist und was Sie jetzt konkret tun sollten.

Was ist passiert?

Wordfence hat am 1. September 2026 ein Advisory zu einer Schwachstelle veröffentlicht, die der Sicherheitsforscher Jack Taylor im Plugin All-in-One WP Migration and Backup gefunden hat. Die Lücke trägt die Kennung CVE-2026-19949 und ist mit einem CVSS-Score von 8,8 als „High Severity“ eingestuft, die Stufe direkt unter „kritisch“. Betroffen sind alle Plugin-Versionen bis einschließlich 7.109. Der Hersteller ServMask hat die Schwachstelle am 20. August 2026 mit Version 7.110 geschlossen.

Die Dimension ist erheblich. All-in-One WP Migration gehört mit über 5 Millionen aktiven Installationen zu den populärsten Plugins überhaupt. Viele Agenturen und Hoster nutzen es standardmäßig für Umzüge und Backups. Nach den Zahlen aus dem Wordfence-Advisory hatten Anfang September erst rund 35 Prozent der Installationen das Update eingespielt. Das heißt im Umkehrschluss: Etwa 3,25 Millionen Websites liefen zu diesem Zeitpunkt noch mit einer verwundbaren Version. Auch deutsche Fachmedien wie Golem und international BleepingComputer haben über die Lücke berichtet.

Dass ausgerechnet ein Backup-Plugin betroffen ist, macht den Fall besonders unangenehm. Backup-Werkzeuge haben naturgemäß weitreichende Rechte: Sie lesen die komplette Datenbank, schreiben Dateien ins Dateisystem und stellen im Ernstfall die gesamte Website wieder her. Wer ein solches Plugin kontrolliert, kontrolliert die Website.

All-in-One WP Migration ist dabei kein Nischenwerkzeug. Das Plugin hat sich über Jahre als Quasi-Standard für WordPress-Umzüge etabliert, weil es eine komplette Website samt Datenbank, Medien, Plugins und Themes in eine einzige Archivdatei packt und auf einem anderen Server mit wenigen Klicks wieder entpackt. Genau diese Einfachheit hat ihm die enorme Verbreitung eingebracht. Sie sorgt aber auch dafür, dass das Plugin auf unzähligen Websites installiert bleibt, obwohl der Umzug längst abgeschlossen ist. Solche vergessenen Installationen sind für Angreifer ein gefundenes Fressen, denn dort schaut erst recht niemand regelmäßig nach Updates.

Was ist eine Second-Order-SQL-Injection?

Bei einer klassischen SQL-Injection wird der Schadcode sofort ausgeführt, wenn der Angreifer ihn einschickt. Bei einer Second-Order-Variante wird der Code zunächst nur gespeichert und wirkt harmlos. Erst wenn die Anwendung die gespeicherten Daten später erneut verarbeitet, zum Beispiel bei einem Import oder einer Wiederherstellung, wird der versteckte SQL-Befehl zusammengesetzt und ausgeführt. Der Angriff zündet also zeitversetzt, oft Tage oder Wochen nach der eigentlichen Ablage.

Die Angriffskette im Detail: vier Schritte bis zur Übernahme

Der Angriff auf CVE-2026-19949 ist ein Lehrstück dafür, wie Angreifer heute mehrere unspektakuläre Einzelteile zu einer verheerenden Kette kombinieren. Man muss kein Entwickler sein, um das Muster zu verstehen. Gehen wir die Kette Schritt für Schritt durch.

Schritt 1: Der Schadcode kommt per Trackback ins Haus

Trackbacks sind eine Uralt-Funktion von WordPress. Sie stammen aus der Blütezeit der Blogs und benachrichtigen eine Website automatisch darüber, dass eine andere Seite auf sie verlinkt hat. Technisch ist ein Trackback nichts anderes als ein kleiner Datensatz, den jeder Beliebige von außen an Ihre Website schicken kann. Eine Anmeldung ist nicht nötig. Genau hier setzt der Angreifer an: Er schickt einen präparierten Trackback, dessen Inhalt speziell konstruierte Zeichenfolgen mit Backslashes und Anführungszeichen enthält. WordPress speichert diesen Datensatz brav in der Datenbank, wie es das seit über zwanzig Jahren tut.

An dieser Stelle ist noch nichts Schlimmes passiert. Der Datensatz sieht aus wie ein gewöhnlicher, etwas kryptischer Kommentar. Kein Malware-Scanner schlägt an, denn es liegt keine Schadsoftware im Dateisystem. Die Website funktioniert völlig normal weiter.

Schritt 2: Die Bombe liegt schlafend in der Datenbank

Der präparierte Datensatz wandert beim nächsten Backup ganz automatisch mit ins Backup-Archiv. Auch das ist erwartbares Verhalten, schließlich soll ein Backup die komplette Datenbank sichern. Der Angreifer muss jetzt nur noch warten. Seine Nutzlast liegt in der Datenbank und in jedem Backup, das ab diesem Zeitpunkt erstellt wird.

Schritt 3: Der Restore zündet die Injection

Der kritische Moment kommt, wenn ein Administrator ein Backup-Archiv wiederherstellt oder importiert. Beim Einspielen der Daten verarbeitet All-in-One WP Migration die gesicherten Datenbankinhalte und behandelt dabei escapte Backslashes und Anführungszeichen fehlerhaft. Die Zeichen, die den Schadcode bisher als harmlosen Text getarnt haben, werden beim Parsen falsch aufgelöst. Aus dem gespeicherten Text wird plötzlich ein ausführbarer SQL-Befehl, den das Plugin direkt gegen die Datenbank absetzt. Das ist der Second-Order-Effekt: Nicht die Eingabe war der Angriff, sondern die spätere Wiederverarbeitung.

Besonders perfide ist, was der eingeschleuste SQL-Befehl anstellen kann. Er kann den geheimen Import-Schlüssel des Plugins auslesen, den sogenannten ai1wm_secret_key, und ihn an einer öffentlich sichtbaren Stelle ablegen, etwa in einem Kommentar auf der Website. Der Angreifer muss danach nur die Seite aufrufen und den Schlüssel ablesen.

Schritt 4: Mit dem Schlüssel kommt der eigene Code

Der Import-Schlüssel ist die letzte Verteidigungslinie des Plugins. Wer ihn besitzt, darf eigene Backup-Archive im .wpress-Format auf die Website hochladen und einspielen. Der Angreifer baut sich also ein bösartiges Archiv, das ausführbaren PHP-Code enthält, und importiert es mit dem erbeuteten Schlüssel. Ab diesem Moment läuft sein Code auf Ihrem Server. Das Ergebnis ist eine vollständige Remote Code Execution und damit die komplette Übernahme der Website: Admin-Konten anlegen, Hintertüren verstecken, Daten abziehen, Malware verteilen, alles ist möglich.

Wer ist betroffen und wie groß ist das Risiko wirklich?

Betroffen ist jede WordPress-Website, auf der All-in-One WP Migration and Backup in Version 7.109 oder älter aktiv ist. Bei über 5 Millionen Installationen und einer Patch-Quote von nur rund 35 Prozent Anfang September reden wir über Millionen erreichbarer Ziele. Die Einschleusung über Trackbacks erfordert keinerlei Anmeldung und lässt sich automatisieren. Angreifer können also in großem Stil präparierte Daten auf verwundbaren Seiten ablegen und darauf warten, dass irgendwo ein Restore läuft.

Situation	Risiko	Sofortmaßnahme
Version 7.109 oder älter, Plugin aktiv	Vollständige Übernahme möglich, sobald ein Restore läuft	Sofort auf 7.110 oder neuer updaten
Version 7.109 oder älter, Plugin deaktiviert	Geringeres Risiko, aber angreifbar bei jeder vorübergehenden Aktivierung	Trotzdem updaten oder Plugin ganz entfernen
Version 7.110 oder neuer	Nicht betroffen	Aktuell halten

Besonders betroffen sind Agenturen und Freelancer, die viele Kundenprojekte betreuen. All-in-One WP Migration ist das Standardwerkzeug für Seiten-Umzüge zwischen Entwicklungs-, Staging- und Live-Umgebungen. Wer regelmäßig Projekte überträgt, führt genau die Aktion aus, die den Angriff auslöst, und das oft auf Installationen, die zwischen zwei Aufträgen monatelang niemand angefasst hat. Prüfen Sie deshalb nicht nur Ihre eigene Website, sondern die komplette Liste der von Ihnen betreuten Installationen. Auch stillgelegte Staging-Kopien zählen: Sie laufen häufig unter vergessenen Subdomains weiter, sind öffentlich erreichbar und stehen auf keiner Update-Liste.

Man könnte einwenden: Der Exploit feuert doch erst, wenn ein Administrator aktiv eine Wiederherstellung anstößt. Das stimmt, greift aber zu kurz. Der Restore ist die Kernfunktion dieses Plugins. Wer es installiert hat, wird es früher oder später benutzen, sei es beim Umzug auf einen neuen Hoster, beim Aufsetzen einer Staging-Umgebung oder ironischerweise bei der Wiederherstellung nach einem anderen Sicherheitsvorfall. Der Auslöser ist keine exotische Randbedingung, sondern der normale Betrieb.

Auch ein deaktiviertes Plugin ist kein Freifahrtschein. Solange es deaktiviert bleibt, sinkt das Risiko deutlich, weil weder Trackback-Verarbeitung durch das Plugin noch Restores stattfinden. Viele Betreiber aktivieren das Plugin aber genau dann kurzzeitig, wenn sie es brauchen, also für Umzug oder Restore. In diesem Moment ist die Lücke wieder voll ausnutzbar, sofern nicht vorher aktualisiert wurde.

Die Timeline: von der Meldung bis zum Patch

Der Ablauf der Veröffentlichung zeigt einen gut funktionierenden Responsible-Disclosure-Prozess. Vom Eingang der Meldung bis zum fertigen Patch vergingen keine sieben Tage, und die technischen Details wurden erst veröffentlicht, als das Update bereits knapp zwei Wochen verfügbar war:

• 14. August 2026: Sicherheitsforscher Jack Taylor meldet die Schwachstelle über das Wordfence Bug Bounty Programm und erhält dafür eine Prämie von 5.761 US-Dollar.
• 15. August 2026: Wordfence informiert den Hersteller ServMask.
• 16. August 2026: Wordfence rollt eine Firewall-Regel für Premium-Kunden aus.
• 17. August 2026: ServMask bestätigt die Schwachstelle.
• 20. August 2026: Version 7.110 mit dem Fix erscheint.
• 1. September 2026: Wordfence veröffentlicht das vollständige Advisory.
• 15. September 2026: Nutzer der kostenlosen Wordfence-Version erhalten die Firewall-Regel.

Ein Detail verdient Aufmerksamkeit: Zwischen der Firewall-Regel für zahlende Wordfence-Kunden und der Regel für Free-Nutzer liegen vier Wochen. Wer die kostenlose Version einsetzt, ist in diesem Zeitfenster allein auf das Plugin-Update angewiesen. Das ist ein weiteres Argument, Updates nicht von einer vorgelagerten Firewall abhängig zu machen.

Sofortmaßnahmen: das sollten Sie jetzt tun

Die gute Nachricht zuerst: Der Fix ist verfügbar, kostenlos und in wenigen Minuten eingespielt. Wichtig ist die Reihenfolge. Aktualisieren Sie zuerst das Plugin und räumen Sie erst danach auf, damit Sie nicht versehentlich mit einer verwundbaren Version arbeiten. Gehen Sie die folgenden Punkte der Reihe nach durch.

1. Update auf Version 7.110 oder neuer. Prüfen Sie im WordPress-Backend unter Plugins die installierte Version von All-in-One WP Migration and Backup. Alles bis 7.109 ist verwundbar. Spielen Sie das Update sofort ein, auch wenn das Plugin gerade deaktiviert ist.
2. Trackbacks und Pingbacks deaktivieren. Unter Einstellungen, Diskussion können Sie die Annahme von Link-Benachrichtigungen abschalten. Für bestehende Beiträge lässt sich die Trackback-Annahme per Massenbearbeitung deaktivieren. Kaum eine Website braucht diese Funktion heute noch, sie ist seit Jahren vor allem ein Spam- und Angriffskanal.
3. Kommentare und Trackbacks prüfen. Sehen Sie die Kommentar-Übersicht durch, inklusive Spam- und Papierkorb-Ordner. Verdächtig sind Einträge mit ungewöhnlichen Zeichenfolgen, vielen Backslashes, Anführungszeichen oder SQL-Fragmenten wie SELECT oder UNION. Löschen Sie solche Einträge endgültig.
4. Vor dem nächsten Restore innehalten. Wenn Sie eine verwundbare Version im Einsatz hatten, behandeln Sie vorhandene Backup-Archive mit Vorsicht. Sie können die schlafende Nutzlast enthalten. Führen Sie einen Restore erst durch, nachdem das Plugin aktualisiert ist. Bei konkretem Verdacht: Restore stoppen und die Datenbank vorher prüfen lassen.
5. Nach Spuren einer Übernahme suchen. Kontrollieren Sie, ob unbekannte Administrator-Konten, neue Application Passwords oder fremde Plugins existieren. Prüfen Sie auch, ob in öffentlichen Kommentaren Ihrer Seite eine lange zufällige Zeichenkette auftaucht. Das könnte der geleakte Import-Schlüssel sein und wäre ein deutliches Zeichen, dass die Injection bereits gezündet hat.
6. Bei Verdacht professionelle Hilfe holen. Eine kompromittierte Website lässt sich mit Bordmitteln selten zuverlässig bereinigen, weil Angreifer Hintertüren an mehreren Stellen verstecken. Unsere Notfall-Bereinigung für gehackte WordPress-Websites übernimmt Analyse und Bereinigung.

Einschätzung von CMS ADMINS

Second-Order-Schwachstellen wie diese sind aus unserer Sicht die unangenehmste Kategorie im WordPress-Umfeld, und zwar aus einem einfachen Grund: Sie unterlaufen die gängige Sicherheitslogik. Klassische Malware-Scanner suchen nach Schadcode im Dateisystem. Firewalls prüfen eingehende Anfragen auf bekannte Angriffsmuster. Beides läuft hier ins Leere. Der Trackback sieht beim Eintreffen wie Datenmüll aus, nicht wie ein Angriff. Die Datenbank enthält keinen ausführbaren Code, sondern nur Text. Erst die fehlerhafte Wiederverarbeitung beim Restore macht aus dem Text einen Befehl. Wer seine Sicherheit allein auf Scanning stützt, hat gegen dieses Muster schlicht keinen Sensor.

Der zweite Punkt, der uns an diesem Fall beschäftigt: Backup-Plugins sind Kronjuwelen-Ziele. Sie vereinen alles, was ein Angreifer sich wünscht. Vollzugriff auf die Datenbank, Schreibrechte im Dateisystem, eine Import-Funktion, die per Design fremde Archive entgegennimmt und entpackt. Dazu kommt der psychologische Faktor: Ein Backup-Plugin genießt Vertrauen. Niemand rechnet damit, dass ausgerechnet die Wiederherstellung, also der Rettungsanker schlechthin, zum Einfallstor wird. Wir erwarten, dass Angreifer und Sicherheitsforscher diese Plugin-Kategorie in den kommenden Monaten noch deutlich intensiver unter die Lupe nehmen.

Ein Wort zur Bedrohungslage: Hinweise auf aktive Angriffe gibt es bislang nicht, zur Entwarnung taugt das aber nicht. Die technische Analyse ist öffentlich, und mit KI-Unterstützung entstehen aus solchen Beschreibungen heute erheblich schneller einsatzfähige Exploits als noch vor wenigen Jahren, während automatisierte Scanner das Netz permanent nach ungepatchten Installationen durchkämmen. Wer heute noch auf Version 7.109 sitzt, wettet darauf, schneller zu sein als ein Skript. Die Reaktionszeit auf Sicherheitsupdates ist damit zum entscheidenden Faktor geworden.

Das eigentliche Problem steht aber in einer einzigen Zahl: 35 Prozent. Nur gut ein Drittel der Installationen hatte zwei Wochen nach Erscheinen des Patches aktualisiert. Die Lücke war zu diesem Zeitpunkt verantwortungsvoll gemeldet, bestätigt, gepatcht und dokumentiert. Am Prozess der Sicherheitsforschung lag es also nicht. Es scheitert am letzten Meter, am Einspielen des Updates auf Millionen von Websites, um die sich niemand aktiv kümmert. Diese Update-Lücke ist seit Jahren die mit Abstand größte Schwachstelle im WordPress-Ökosystem, größer als jede einzelne CVE. Wir haben dasselbe Muster in diesem Jahr schon bei wp2shell und XSS2Shell beschrieben: Der Patch ist da, aber er kommt bei einem großen Teil der Betreiber schlicht nicht an.

Für unsere Arbeitsweise bestätigt der Fall zwei Grundsätze. Erstens: Updates sind keine Aufgabe, die man „bei Gelegenheit“ erledigt, sondern ein laufender Prozess mit Priorisierung nach Risiko. In unserer WordPress-Wartung beobachten wir Sicherheitsmeldungen kontinuierlich und spielen kritische Patches priorisiert ein, ohne dass unsere Kunden die Advisories selbst verfolgen müssen. Zweitens: Backups gehören aus unserer Sicht nicht in die Hände eines Plugins innerhalb der Website, die sie schützen sollen. Wir setzen auf serverseitige Echtzeit-Backups mit 60 Tagen Aufbewahrung auf deutschen Servern. Die laufen außerhalb von WordPress, sind für einen Angreifer auf Anwendungsebene nicht erreichbar und vergrößern die Angriffsfläche der Website nicht. Der aktuelle Fall zeigt ziemlich genau, warum diese Trennung sinnvoll ist.

Häufig gestellte Fragen zu CVE-2026-19949

Bin ich betroffen, wenn ich das Plugin installiert, aber deaktiviert habe?
Das Risiko ist deutlich geringer, aber nicht null. Sobald Sie das Plugin für einen Umzug oder Restore vorübergehend aktivieren, ist die Lücke in Version 7.109 und älter wieder ausnutzbar. Aktualisieren Sie deshalb auch deaktivierte Installationen auf 7.110 oder entfernen Sie das Plugin ganz, wenn Sie es nicht brauchen.

Reicht es, einfach keinen Restore mehr auszuführen?
Als Dauerlösung nein. Der Restore ist der Auslöser, aber genau dafür haben Sie das Plugin ja installiert. Spätestens im Ernstfall, etwa nach einem Crash oder Hack, müssen Sie wiederherstellen. Dann wollen Sie nicht vor der Wahl stehen, entweder auf Ihr Backup zu verzichten oder eine SQL-Injection zu riskieren. Das Update löst das Problem dauerhaft.

Woran erkenne ich, ob meine Website bereits angegriffen wurde?
Prüfen Sie Kommentare und Trackbacks auf Einträge mit auffälligen Zeichenfolgen, Backslashes oder SQL-Fragmenten, auch im Spam-Ordner. Verdächtig sind außerdem unbekannte Administrator-Konten, fremde Plugins und lange zufällige Zeichenketten in öffentlichen Kommentaren, die auf einen geleakten Import-Schlüssel hindeuten können. Im Zweifel hilft eine professionelle Prüfung.

Schützt mich meine Firewall oder mein Security-Plugin?
Nur bedingt. Wordfence hat eine passende Firewall-Regel am 16. August 2026 zunächst an Premium-Kunden verteilt, Nutzer der kostenlosen Version erhalten sie erst ab dem 15. September 2026. Andere Lösungen erkennen das Muster möglicherweise gar nicht, weil der eingehende Trackback für sich genommen unauffällig ist. Verlassen Sie sich nicht auf vorgelagerte Filter, spielen Sie das Update ein.

Sind meine alten Backup-Archive jetzt gefährlich?
Möglicherweise. Backups, die nach einem präparierten Trackback erstellt wurden, enthalten die schlafende Nutzlast. Gefährlich wird das nur beim Wiederherstellen mit einer verwundbaren Plugin-Version. Aktualisieren Sie das Plugin, bevor Sie ein älteres Archiv einspielen, und prüfen Sie bei konkretem Verdacht vorher die Kommentar-Tabellen des Backups.

Muss ich Trackbacks wirklich abschalten?
Wir empfehlen es klar. Trackbacks und Pingbacks stammen aus der Blog-Ära und werden heute fast ausschließlich für Spam und als Angriffskanal missbraucht. Der Nutzen ist für die allermeisten Websites gleich null, das Abschalten kostet zwei Klicks unter Einstellungen, Diskussion und reduziert Ihre Angriffsfläche dauerhaft.

Fazit

CVE-2026-19949 ist keine Lücke, die man aussitzen kann. Die Einschleusung funktioniert ohne Anmeldung, der Auslöser ist der normale Betrieb des Plugins und am Ende der Kette steht die komplette Übernahme der Website. Gleichzeitig ist die Abhilfe so einfach wie selten: Update auf 7.110 einspielen, Trackbacks abschalten, Kommentare prüfen. Wer das heute erledigt, hat das Thema vom Tisch. Wer sich um solche Meldungen grundsätzlich nicht mehr selbst kümmern will, findet in unserer WordPress-Wartung die passende Dauerlösung mit gemanagten Updates und serverseitigen Backups. Und falls Sie den Verdacht haben, dass Ihre Website bereits kompromittiert ist: Zögern Sie nicht und melden Sie sich über unsere Notfall-Seite.

---

Quellen: Wordfence-Advisory vom 1. September 2026 · BleepingComputer, 2. September 2026 · Golem.de (Marc Stöckel, 03.09.2026) · NVD: CVE-2026-19949. Entdeckung: Jack Taylor via Wordfence Bug Bounty. CVSS 8,8. Letzte Aktualisierung: 3. September 2026.