All-in-One WP Migration: Die Lücke zündet erst beim Zurückspielen — wer wirklich betroffen ist

Im Backup-Plugin All-in-One WP Migration steckt eine Lücke, die nicht beim Sichern zuschlägt, sondern beim Zurückspielen. Ein Angreifer hinterlegt den Schadcode Monate im Voraus über eine harmlose Kommentarfunktion; ausgelöst wird er erst in dem Moment, in dem Sie ein Backup einspielen — also genau dann, wenn ohnehin etwas schiefgegangen ist. Die Korrektur ist seit dem 20. August verfügbar. Sechs von zehn Installationen haben sie bis heute nicht eingespielt. Dieser Beitrag erklärt den Ablauf, grenzt ein, wer wirklich betroffen ist, und korrigiert zwei Angaben, die derzeit durch die Berichterstattung laufen.

Das Wichtigste in Kürze

Betroffen ist «All-in-One WP Migration and Backup» bis einschliesslich 7.109. Die Korrektur steckt in 7.110, veröffentlicht am 20. August 2026. Ein Blick in Plugins → Installierte Plugins klärt Ihren Fall in einer Minute.
Die Lücke zündet beim Zurückspielen, nicht im Normalbetrieb. Der Schadcode wird unangemeldet über einen Trackback hinterlegt und bleibt reglos in der Datenbank liegen. Ausgeführt wird er erst, wenn jemand mit Administratorrechten ein Archiv importiert oder wiederherstellt. Das macht die Lücke nicht harmlos — es verschiebt nur den Zeitpunkt.
Aktive Angriffe sind bisher nicht belegt. Eine verbreitete Schlagzeile spricht von «aktivem Exploit-Code». Weder Wordfence noch SecurityWeek noch BleepingComputer berichten von Angriffen in freier Wildbahn oder von veröffentlichtem Angriffscode. Öffentlich ist die Beschreibung des Ablaufs — das ist etwas anderes.
Die Zahl «3,2 Millionen» ist eine Hochrechnung, keine Messung. Sie stammt aus der Versionsstatistik von wordpress.org, nicht aus einem Scan echter Websites. Unsere eigene Abfrage derselben Quelle vom 7. September ergibt: 39,8 Prozent laufen auf 7.110, rund 60 Prozent nicht.
Zwei Handgriffe, nicht einer. Plugin aktualisieren — und danach prüfen, ob Ihre Website Trackbacks überhaupt annehmen muss. WordPress schaltet sie bei jeder Neuinstallation von sich aus ein.

Was passiert ist

All-in-One WP Migration and Backup ist eines der meistgenutzten WordPress-Plugins überhaupt. Das offizielle Verzeichnis auf wordpress.org weist für den Stand vom 7. September 2026 fünf Millionen aktive Installationen aus. Es sichert eine Website in eine einzelne .wpress-Datei und spielt sie andernorts wieder ein — das Werkzeug, mit dem unzählige Websites den Hoster gewechselt haben.

Am 14. August 2026 meldete der Sicherheitsforscher Jack Taylor über das Bug-Bounty-Programm von Wordfence einen Fehler in der Wiederherstellungsfunktion. Er erhielt dafür 5761 US-Dollar. Der Hersteller ServMask bestätigte den Bericht am 17. August und veröffentlichte am 20. August die Version 7.110. Die technischen Einzelheiten machte Wordfence am 2. September öffentlich — die übliche Reihenfolge, damit zwischen Korrektur und Beschreibung Zeit zum Aktualisieren liegt.

Datum 2026	Ereignis
14. August	Meldung an Wordfence durch Jack Taylor, Prämie 5761 US-Dollar
16. August	Firewall-Regel für zahlende Wordfence-Kunden
17. August	ServMask bestätigt den Bericht
20. August	Version 7.110 erscheint — die Korrektur
2. September	Wordfence veröffentlicht die technischen Einzelheiten
15. September	Firewall-Regel auch für Nutzer der Gratisversion

Der Ablauf von der Meldung bis zur Veröffentlichung. Zwischen Korrektur und Beschreibung des Angriffs liegen dreizehn Tage.

Die Lücke trägt die Kennung CVE-2026-19949 und den Schweregrad 8,8 von 10 — «hoch», nicht «kritisch», aber nah an der Grenze. Betroffen sind alle Versionen bis einschliesslich 7.109.

Wie der Angriff abläuft

Der Fachbegriff lautet Second-Order SQL Injection — eine Einschleusung zweiter Ordnung. Der Unterschied zur gewöhnlichen Variante ist der Zeitpunkt: Bei der gewöhnlichen SQL-Injection wird die Eingabe sofort ausgeführt. Hier wird sie zunächst nur gespeichert. Sie liegt als vollkommen unauffälliger Datensatz in der Datenbank und wird erst dann zu einem Befehl, wenn ein zweites, ganz anderes Programmstück sie später weiterverarbeitet.

Ein Bild dafür: Jemand hinterlegt bei Ihnen einen Zettel mit einer Notiz. Der Zettel liegt monatelang im Ordner und tut nichts. Erst wenn Sie irgendwann alle Zettel im Ordner der Reihe nach abarbeiten, stellt sich heraus, dass auf einem davon nicht eine Notiz stand, sondern eine Anweisung.

Ablegen. Ein Angreifer schickt Ihrer Website zwei Trackbacks — jenen automatischen Benachrichtigungen, mit denen sich Blogs gegenseitig auf Verlinkungen hinweisen. Dafür braucht er kein Konto und kein Passwort. Die Trackbacks enthalten sorgfältig gesetzte Rückstriche und Anführungszeichen.
Warten. Die Daten liegen in der Kommentartabelle. Nichts passiert. Kein Fehler im Protokoll, keine Auffälligkeit im Betrieb.
Auslösen. Irgendwann exportiert und importiert jemand die Website mit dem Plugin. Beim Einspielen schreibt das Plugin in den gesicherten SQL-Daten Adressen und Tabellenpräfixe um. An dieser Stelle rechnet es die Rückstriche falsch ab — und aus dem abgelegten Text wird ein ausgeführter Befehl.
Ausleiten. Der eingeschleuste Befehl liest den geheimen Importschlüssel des Plugins aus (ai1wm_secret_key) und schreibt ihn in einen Kommentar, der freigegeben und damit öffentlich sichtbar wird. Der Angreifer muss ihn nur noch abholen.
Übernehmen. Mit diesem Schlüssel darf er selbst ein Archiv importieren. In dem Archiv steckt ausführbarer Code. Damit gehört die Website ihm.

Die Kette ist elegant und unangenehm, weil sie an der Stelle zuschlägt, an der man am wenigsten damit rechnet: bei der Wiederherstellung. Ein Backup spielt man selten aus Vergnügen ein. Man tut es, wenn etwas kaputt ist — unter Zeitdruck, oft nachts, oft mit dem Gefühl, das Schlimmste schon hinter sich zu haben.

Wer betroffen ist — und wer nicht

Hier lohnt Genauigkeit, weil ein Teil der Berichterstattung den Eindruck erweckt, drei Millionen Websites stünden unmittelbar vor der Übernahme. Das trifft nicht zu. Die Bedingungen sind:

Bedingung	Bedeutung für Ihre Website
Plugin-Version bis 7.109	Notwendige Bedingung. Ab 7.110 ist die Kette unterbrochen.
Jemand spielt ein Archiv ein	Ohne Wiederherstellung oder Import kein Auslöser. Der Export allein genügt nicht.
Ein passender Datensatz liegt bereits vor	Der Angreifer muss den Trackback vorher abgelegt haben — auch Monate vorher.

Alle drei Bedingungen müssen zusammenkommen. Die dritte lässt sich nicht mehr rückgängig machen — die zweite tritt früher oder später bei jeder Website ein.

Zwei Schlussfolgerungen daraus. Erstens: Eine Website, die das Plugin installiert hat, es aber seit Jahren nicht benutzt, ist heute nicht in akuter Gefahr. Zweitens — und das ist der Grund, warum die Sache trotzdem dringend ist: Die Ablage ist bereits geschehen oder nicht, daran ändert ein Update nichts. Was das Update ändert, ist die Zündung. Wer erst nach dem nächsten Notfall aktualisiert, aktualisiert zu spät.

Ein wirklich unangenehmer Sonderfall verdient eigene Erwähnung: Umzüge zwischen Umgebungen. Wer eine Produktionsseite regelmässig auf eine Testumgebung klont, spielt genau die Datenbank ein, in der ein solcher Datensatz liegen könnte — und tut das mit denselben Rechten.

Woher die Zahl «3,2 Millionen» kommt

SecurityWeek berichtete am 3. September, nur 35 Prozent der Installationen liefen auf 7.110, es blieben also «rund 3,2 Millionen» verwundbare Websites. Diese Zahl wird seither überall zitiert. Sie ist plausibel, aber sie ist keine Messung an echten Websites. Sie ist die Hochrechnung aus zwei Angaben, die wordpress.org selbst veröffentlicht: der gerundeten Zahl aktiver Installationen und der prozentualen Versionsverteilung.

Diese Quelle kann jeder abfragen. Unser Abruf vom 7. September 2026 über api.wordpress.org/stats/plugin/1.0/all-in-one-wp-migration ergab:

Version	Anteil am 7. September 2026
7.110 (korrigiert)	39,83 Prozent
7.105	6,08 Prozent
alle übrigen, zusammengefasst	54,06 Prozent

Versionsverteilung laut der offiziellen Statistik-Schnittstelle von wordpress.org. Vier Tage nach dem Bericht von SecurityWeek liegt der Anteil der korrigierten Version bei knapp 40 statt 35 Prozent.

Auf fünf Millionen Installationen gerechnet sind das rund drei Millionen Websites, die nicht auf 7.110 laufen. Die Richtung stimmt also, und die Grössenordnung auch. Was man aus der Zahl nicht ablesen kann: wie viele dieser Websites das Plugin tatsächlich benutzen, wie viele davon jemals ein Archiv einspielen werden und wie viele bereits einen passenden Datensatz in der Datenbank haben. Wer eine dieser drei Fragen mit einer Zahl beantwortet, rechnet nicht, sondern rät.

Bemerkenswert ist ohnehin weniger die absolute Zahl als der Verlauf: Achtzehn Tage nach einer Korrektur, die per Klick im Dashboard verfügbar ist, hat sie noch keine Mehrheit eingespielt. Das ist kein Befund über dieses Plugin. Das ist der Normalfall.

Was über aktive Angriffe bekannt ist

Eine viel geteilte Schlagzeile vom 3. September lautet sinngemäss: «3,25 Millionen Websites betroffen, Exploit-Code aktiv». Der zweite Teil hält der Prüfung nicht stand. Wir haben die Berichte von Wordfence, SecurityWeek und BleepingComputer gelesen: Keiner davon nennt Angriffe in freier Wildbahn, und keiner nennt veröffentlichten Angriffscode.

Was es gibt, sind ausführliche Beschreibungen des Ablaufs — die technische Analyse von Wordfence und daraus abgeleitete Fachbeiträge. Eine Beschreibung ist kein lauffähiges Werkzeug. Sie senkt den Aufwand für einen Angreifer, aber sie ist nicht dasselbe wie ein fertiges Programm, das reihenweise Websites abklappert.

Warum diese Unterscheidung nicht bloss Wortklauberei ist: Wer heute «aktive Angriffe» sagt und morgen bei einem Fall, in dem tatsächlich Angriffe laufen, dieselben Worte benutzt, hat keine Sprache mehr für den Unterschied. Und Website-Betreiber, die schon dreimal alarmiert wurden und jedes Mal nichts vorfanden, reagieren beim vierten Mal nicht mehr. Die Dringlichkeit hier ergibt sich aus der Sache selbst — sie muss nicht aufgeladen werden.

In fünf Minuten selbst prüfen

Version feststellen. Melden Sie sich in WordPress an und öffnen Sie Plugins → Installierte Plugins. Suchen Sie «All-in-One WP Migration». Steht dort eine Versionsnummer kleiner als 7.110, ist Handlung nötig. Ist das Plugin gar nicht aufgeführt, sind Sie an dieser Stelle fertig.
Aktualisieren. Über Dashboard → Aktualisierungen oder direkt in der Plugin-Liste. Wer eine Testumgebung hat, spielt das Update dort zuerst ein — bei einem Plugin dieser Grösse ist das kein Übermass an Vorsicht.
Deaktivierte Altbestände entfernen. Ein deaktiviertes Plugin wird oft übersehen und trotzdem selten aktualisiert. Wenn Sie das Werkzeug nur für einen einmaligen Umzug gebraucht haben, gehört es gelöscht, nicht deaktiviert.
Kommentare durchsehen. Schauen Sie unter Kommentare nach Trackbacks und Pingbacks aus den vergangenen Monaten, die inhaltlich keinen Sinn ergeben. Wer eine solche Spur findet, hat noch keinen Beweis für einen Angriff — aber einen guten Grund, genauer hinzusehen.
Nach einem bereits erfolgten Import: Schlüssel wechseln. Haben Sie in den vergangenen Wochen mit einer Version bis 7.109 ein Archiv eingespielt, wechseln Sie das Administratorpasswort, prüfen Sie die Benutzerliste auf unbekannte Konten und sehen Sie das Plugin-Verzeichnis auf Unbekanntes durch. Wie eine gründliche Bereinigung aussieht, steht in unserem Beitrag WordPress gehackt — so bereinigen Sie Ihre Website.

Die zweite Baustelle: Trackbacks

Der Einlieferungsweg dieses Angriffs ist eine WordPress-Funktion aus einer anderen Zeit. Trackbacks und Pingbacks stammen aus den frühen 2000er-Jahren, als Blogs sich gegenseitig automatisch über Verlinkungen benachrichtigten. Für eine Unternehmenswebsite hat diese Funktion heute in aller Regel keinen Nutzen — sie ist praktisch ausschliesslich eine Quelle für Spam.

Trotzdem ist sie fast überall aktiv. Der Grund steht im Quelltext von WordPress: In der Datei, die eine frische Installation einrichtet, ist default_ping_status auf open gesetzt. Jede neu angelegte Website nimmt Trackbacks also von sich aus an, ohne dass jemand das je entschieden hätte.

Abschalten geht unter Einstellungen → Diskussion mit dem Häkchen «Link-Benachrichtigungen von anderen Blogs (Pingbacks und Trackbacks) zu neuen Artikeln erlauben». Wichtig: Diese Einstellung gilt nur für künftige Beiträge. Bestehende Beiträge behalten ihren eigenen Status und müssen über die Massenbearbeitung in der Beitragsliste umgestellt werden.

Zwei Einschränkungen, damit hier kein falscher Eindruck entsteht. Erstens ersetzt das Abschalten das Update nicht: Es schliesst den beschriebenen Einlieferungsweg, nicht den zugrunde liegenden Fehler. Zweitens entfernt es keine Datensätze, die schon in der Datenbank liegen. Es ist eine sinnvolle Verkleinerung der Angriffsfläche — und die gehört ohnehin zu einer Härtung, nicht in die Notfallmappe.

Was daraus für die Wartung folgt

Der Satz «Plugins sind das Sicherheitsrisiko» wird oft gesagt und stimmt so nicht. Dieses Plugin ist gut gepflegt: Zwischen Meldung und Korrektur lagen sechs Tage, der Hersteller reagierte innerhalb von drei Tagen. Das ist überdurchschnittlich schnell. Der Fehler lag nicht in der Reaktionszeit des Herstellers.

Er liegt in den achtzehn Tagen danach. Eine Korrektur, die niemand einspielt, ist wirkungslos — und «niemand» ist hier keine Nachlässigkeit einzelner Personen, sondern die vorhersehbare Folge davon, dass für eine Website niemand zuständig ist. Die Website läuft ja. Sie meldet sich nicht. Genau das ist die Bauart des Problems.

Was in der Praxis hilft, ist unspektakulär: ein fester Termin, an dem jemand hinsieht; eine Testumgebung, damit ein Update nicht zwischen Risiko und Stillstand zwingt; und ein geprüftes Backup, das nicht dasselbe Werkzeug voraussetzt, dessen Lücke gerade das Problem war. Wie das konkret aussieht, steht in WordPress-Updates sicher durchführen und in WordPress-Backup richtig einrichten.

Fazit

Prüfen Sie die Version, aktualisieren Sie auf 7.110, löschen Sie das Plugin, wenn Sie es nicht mehr brauchen. Das ist die ganze Handlungsanweisung, und für die allermeisten Websites ist die Sache damit erledigt.

Was bleibt, ist die unbequemere Frage dahinter: Wenn diese Korrektur achtzehn Tage lang unbemerkt bereitlag — welche liegt sonst noch bereit? Auf einer typischen Unternehmenswebsite sind zwanzig bis dreissig Plugins installiert. Die Frage ist nie, ob eines davon eine Lücke hat, sondern wie lange sie offen bleibt.

Wenn Sie nicht sicher sind, wie es um Ihre Website steht: Schicken Sie uns die Adresse. Wir sehen uns an, welche Versionen laufen und ob etwas Auffälliges darin steckt, und Sie erhalten innert einem Werktag eine verständliche Einschätzung — auch dann, wenn sie lautet, dass alles in Ordnung ist. Was wir laufend übernehmen, steht unter WordPress-Support und Wartung; der direkte Weg führt über das Kontaktformular.

Häufige Fragen

Ich benutze das Plugin nur zum Sichern, nie zum Wiederherstellen. Bin ich sicher?

Vorläufig ja — der Auslöser ist das Einspielen, nicht das Sichern. Nur ist ein Backup, das nie eingespielt wird, kein Backup, sondern eine Datei. Irgendwann kommt der Tag, an dem Sie es brauchen, und dann wollen Sie nicht zusätzlich über eine bekannte Lücke nachdenken müssen. Aktualisieren Sie jetzt, solange kein Zeitdruck herrscht.

Muss ich meine bestehenden Backups verwerfen?

Nein. Ein bestehendes Archiv wird durch die Lücke nicht unbrauchbar, und es enthält auch keinen Schadcode. Es kann allenfalls den abgelegten Kommentar-Datensatz enthalten — der aber unter Version 7.110 beim Einspielen nicht mehr zum Befehl wird. Wichtig ist die Reihenfolge: erst das Plugin aktualisieren, dann einspielen.

Mein Hoster sagt, seine Firewall fange das ab. Reicht das?

Als Übergangslösung womöglich, als Dauerzustand nicht. Eine Firewall-Regel erkennt bekannte Muster im eingehenden Verkehr. Bei einem Angriff in zwei Schritten müsste sie den unauffälligen ersten Schritt erkennen — Monate bevor irgendetwas passiert. Wordfence hat für diese Lücke eine Regel ausgeliefert, zahlende Kunden am 16. August, Nutzer der Gratisversion am 15. September. Das ist eine Absicherung für die Zeit bis zum Update, kein Ersatz dafür.

Woran erkenne ich, ob bei mir schon etwas abgelegt wurde?

Mit Bordmitteln zuverlässig kaum. Der Datensatz sieht aus wie ein gewöhnlicher Trackback. Ein Blick in die Kommentarliste auf sinnlose Trackbacks der vergangenen Monate ist ein erster Anhaltspunkt, mehr nicht — Trackback-Spam gibt es auch ohne Angriff massenhaft. Die belastbare Antwort liefert eine Durchsicht der Kommentartabelle auf die konkreten Muster. Das ist Handarbeit und der Grund, warum die Reihenfolge lautet: erst aktualisieren, dann in Ruhe nachsehen.

Sollte ich auf ein anderes Backup-Plugin wechseln?

Nicht wegen dieses Vorfalls. Der Hersteller hat sauber und schnell reagiert, und das ist das Kriterium, auf das es ankommt — nicht die Frage, ob ein Plugin je eine Lücke hatte. Ein Wechsel lohnt aus anderen Gründen: wenn Sie automatische, planbare Sicherungen an einen externen Ort brauchen oder wenn die Wiederherstellung regelmässig geprüft werden soll. Diese Kriterien behandeln wir in WordPress-Backup richtig einrichten.

Was bedeutet der Schweregrad 8,8?

Das ist der CVSS-Wert, eine Bewertung von 0 bis 10, die sich aus Merkmalen wie «ohne Anmeldung ausnutzbar» und «vollständiger Kontrollverlust möglich» zusammensetzt. 8,8 liegt in der Stufe «hoch», ab 9,0 beginnt «kritisch». Der Wert beschreibt das Schadenspotenzial im ungünstigsten Fall, nicht die Wahrscheinlichkeit, dass es Sie trifft. Wie man solche Zahlen einordnet, steht in WordPress-Schwachstellen richtig einordnen.

Quellen

SecurityWeek: Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability ↗ — Bericht vom 3. September 2026; Quelle für CVSS 8,8, das Erscheinungsdatum von 7.110 und die Angabe «35 Prozent aktualisiert»
BleepingComputer: WordPress backup plugin flaw exposes millions of sites to takeover attacks ↗ — Bericht vom 2. September 2026 mit dem vollständigen Ablauf und der Bedingung, dass die Nutzlast bis zur Wiederherstellung reglos bleibt
wordpress.org: All-in-One WP Migration and Backup ↗ — offizielles Verzeichnis; Quelle für fünf Millionen aktive Installationen, Version 7.110 und das Veröffentlichungsdatum 20. August 2026
api.wordpress.org: Versionsstatistik des Plugins ↗ — die offene Schnittstelle, aus der die Werte der Tabelle stammen; eigener Abruf am 7. September 2026
WordPress-Kern: wp-admin/includes/schema.php ↗ — die Datei, die eine neue Installation einrichtet; dort steht 'default_ping_status' => 'open'
TechTimes: WordPress Backup Plugin Flaw: 3.25 Million Sites Exposed, Exploit Code Active ↗ — die Meldung, auf die sich die im Abschnitt «Aktive Angriffe» korrigierte Aussage bezieht

Stand: 7. September 2026. Die Versionsanteile in der Tabelle stammen aus einem eigenen Abruf der offiziellen Statistik-Schnittstelle von wordpress.org am 7. September 2026; sie ändern sich täglich. Sollten Angriffe in freier Wildbahn belegt werden oder der Hersteller weitere Angaben veröffentlichen, ergänzen wir den Beitrag.