#Netzwerk & Sicherheit · 4 Min. Lesezeit · Tim Rinkel

MILLIONENFACH UNGEPATCHT! Dein WordPress-Backup-Plugin lässt Fremde Code ausführen — prüf es heute

MILLIONENFACH UNGEPATCHT! Dein WordPress-Backup-Plugin lässt Fremde Code ausführen — prüf es heute

Ein Backup-Plugin soll deine Seite retten, wenn etwas schiefgeht. Bei rund drei Millionen WordPress-Seiten ist ausgerechnet dieses Plugin gerade das offene Fenster.

Es geht um All-in-One WP Migration and Backup — eines der meistgenutzten Werkzeuge, um eine WordPress-Seite zu sichern oder auf einen anderen Server umzuziehen. Sicherheitsforscher Jack Taylor hat darin eine SQL-Injection gefunden, geführt unter CVE-2026-19949. Betroffen sind alle Versionen bis einschließlich 7.109. Repariert ist sie in 7.110, veröffentlicht am 20. August 2026.

Der Angriff wartet geduldig

Das Perfide an dieser Lücke ist ihr Zeitverzug. Es handelt sich um eine sogenannte Second-Order-Injection — der Schadcode wird nicht sofort ausgeführt, sondern erst einmal nur abgelegt.

Der Weg hinein führt über Trackbacks, jene alte WordPress-Funktion, mit der sich Blogs gegenseitig über Verlinkungen informieren. Ein Angreifer schickt einen präparierten Trackback an deine Seite. Der landet in der Datenbank und liegt dort still — kein Alarm, keine Fehlermeldung, nichts, was auffiele.

Losgetreten wird er erst, wenn du selbst etwas völlig Normales tust: einen Export anstoßen oder einen Import einspielen. In diesem Moment liest das Plugin die vergiftete Zeile aus der Datenbank, und der untergeschobene Befehl wird ausgeführt. Von dort ist es kein weiter Weg bis zu fremdem Code auf deinem Server. Es braucht dafür keinen Login — nur Geduld.

Das eigentliche Problem: kaum jemand updatet

Der Patch steht seit dem 20. August bereit. Trotzdem waren Anfang September erst rund 35 Prozent aller Installationen auf 7.110 oder neuer. Bleiben grob 3,2 Millionen Seiten, die weiterhin eine verwundbare Version fahren.

Das ist das bekannte Muster: Ein Plugin, das man einmal für den Umzug installiert hat, läuft danach jahrelang unbeachtet mit. Genau solche Kandidaten suchen automatisierte Scanner ab — nicht gezielt deine Seite, sondern einfach alles, was antwortet.

In fünf Minuten erledigt

1. Version prüfen. Im WordPress-Backend unter Plugins → Installierte Plugins nach „All-in-One WP Migration“ suchen. Steht dort eine Nummer kleiner als 7.110, bist du dran.

2. Aktualisieren. Update einspielen, fertig. Das Plugin ist beim Update unauffällig, ein vorheriges Datenbank-Backup schadet trotzdem nie.

3. Brauchst du es überhaupt noch? Wenn der Umzug längst durch ist: deaktivieren und löschen. Ein Plugin, das nicht installiert ist, kann auch nicht angegriffen werden. Das ist die wirksamste Maßnahme überhaupt — und die wird am seltensten ergriffen.

4. Nachsehen, ob schon jemand da war. Unter Benutzer nach Konten schauen, die du nicht angelegt hast. Danach das Kommentar- und Trackback-Aufkommen der letzten Wochen durchgehen. Wer Zugriff per SSH hat, sucht im Webroot nach PHP-Dateien mit auffällig frischem Änderungsdatum.

Und grundsätzlich

Trackbacks und Pingbacks braucht heute kaum noch jemand. Unter Einstellungen → Diskussion lässt sich die Annahme abschalten — das nimmt dieser und einigen künftigen Lücken die Eintrittstür. Automatische Updates für Plugins sind der zweite Hebel: Bei einem Werkzeug, das du ohnehin nur alle paar Monate anfasst, ist das Risiko eines automatischen Updates kleiner als das Risiko, es zu vergessen.

Häufige Fragen

Ist meine Seite betroffen, wenn ich das Plugin nur installiert, aber nie benutzt habe?
Ja. Entscheidend ist, dass das Plugin aktiv ist — dann ist der verwundbare Code geladen. Wenn du es nach einem Umzug nie wieder gebraucht hast, ist Deaktivieren und Löschen die sauberste Lösung.
Was ist eine Second-Order-SQL-Injection?
Bei einer klassischen SQL-Injection wirkt der eingeschleuste Befehl sofort. Bei der Second-Order-Variante wird er zunächst nur gespeichert und erst später ausgeführt, wenn eine andere Funktion die Daten wieder aus der Datenbank holt. Genau das macht sie so schwer zu entdecken: Zwischen Ablage und Wirkung können Wochen liegen.
Woran erkenne ich, ob jemand die Lücke bei mir ausgenutzt hat?
Sichere Zeichen gibt es nicht, aber typische Spuren: neue Administratorkonten, die du nicht angelegt hast, PHP-Dateien mit frischem Änderungsdatum im Webroot oder im Upload-Ordner, und ungewöhnlich viele Trackbacks in der Kommentar-Warteschlange. Bei begründetem Verdacht hilft nur ein sauberes Zurücksetzen aus einem Backup von vor dem Vorfall.
Reicht ein Sicherheits-Plugin als Schutz?
Eine Web Application Firewall kann bekannte Angriffsmuster abfangen und Zeit kaufen, sie ersetzt das Update aber nicht. Bei einer Lücke, deren Nutzlast erst Wochen später zündet, ist die zuverlässige Lösung die aktualisierte Plugin-Version.

Quellen

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert