WordPress: Wenn das Backup-Plugin zum Einfallstor wird

Ein Backup ist das Werkzeug, mit dem man sich absichert. Es läuft im Hintergrund, meldet sich nie, und genau deshalb schaut niemand hin. Anfang September 2026 hat sich diese Logik umgedreht: Ausgerechnet eines der meistgenutzten Backup- und Migrations-Plugins für WordPress hat eine Sicherheitslücke, über die Angreifer eine komplette Website übernehmen können — und ausgelöst wird der Angriff durch die Backup-Routine selbst.

Betroffen sind je nach Zählung drei bis über fünf Millionen aktive Installationen. Die Wahrscheinlichkeit, dass Ihre WordPress-Seite dazugehört, ist damit alles andere als gering. Dieser Beitrag ordnet ein, was genau passiert ist, warum diese WordPress-Sicherheitslücke besonders unangenehm ist und welche fünf Punkte Sie diese Woche im Backend prüfen sollten.

Was in den letzten Wochen passiert ist

Die Schwachstelle trägt die Kennung CVE-2026-19949 und betrifft das Plugin All-in-One WP Migration and Backup in allen Versionen bis einschließlich 7.109. Sie wird mit einem CVSS-Wert von 8.8 als kritisch eingestuft — der Bereich, in dem eine Übernahme des Systems realistisch ist, nicht nur ein Datenleck.

Der Ablauf in Kürze:

• 14. August 2026: Der Sicherheitsforscher Jack Taylor meldet die Lücke über das Bug-Bounty-Programm von Wordfence.
• 17. August: Der Hersteller ServMask bestätigt den Befund.
• 20. August: Version 7.110 erscheint und schließt die Lücke.
• 2. September: Wordfence veröffentlicht die vollständige technische Analyse.
• 15. September: Nutzer der kostenlosen Wordfence-Version erhalten die passende Firewall-Regel — Premium-Kunden bereits seit dem 16. August.

Der entscheidende Punkt an dieser Chronologie: Seit dem 2. September sind die technischen Details öffentlich. Erfahrungsgemäß tasten automatisierte Scanner Websites innerhalb weniger Tage nach genau solchen Mustern ab. Wer erst im Oktober aktualisiert, hat zwei Monate lang mit offener Tür gearbeitet — und je nach Konfiguration bis Mitte September nicht einmal Schutz durch die kostenlose Firewall.

Warum diese Lücke besonders tückisch ist

Die meisten Sicherheitslücken funktionieren nach dem Muster: Angreifer schickt eine manipulierte Anfrage, Server reagiert falsch, Schaden entsteht sofort. Hier ist es anders — es handelt sich um eine sogenannte Second-Order-SQL-Injection, und die läuft in zwei Etappen ab.

Etappe eins: Ein Angreifer hinterlegt präparierte Inhalte auf Ihrer Seite, etwa über öffentlich erreichbare Funktionen wie Trackbacks. Zu diesem Zeitpunkt passiert nichts. Der Datensatz liegt harmlos in der Datenbank, taucht in keinem Log als Angriff auf und ist auch bei einem Sicherheitsscan unauffällig.

Etappe zwei: Irgendwann exportiert jemand aus Ihrem Team die Website mit dem Plugin und spielt sie wieder ein — beim Umzug auf einen neuen Server, beim Aufsetzen einer Testumgebung, beim Zurückspielen eines Backups. Beim Verarbeiten des Archivs interpretiert das Plugin die hinterlegten Zeichen falsch, und die eingeschleuste Datenbankabfrage wird ausgeführt. Ausgelesen wird dabei unter anderem der interne Schlüssel ai1wm_secret_key, der die Import-Funktion des Plugins absichert. Mit diesem Schlüssel kann ein Angreifer anschließend ohne Login ein eigenes Archiv einspielen — inklusive ausführbarem Code. Ab da gehört die Seite ihm.

Für die Praxis heißt das zweierlei. Erstens: Die gefährliche Handlung ist eine völlig normale, sogar vorbildliche Wartungsaufgabe. Zweitens: Zwischen dem Setzen der Falle und dem Schaden können Wochen liegen. Ein aufgeräumtes Backend und “bei uns war nie was” sind deshalb kein Beleg dafür, dass nichts hinterlegt wurde.

“Wir haben doch nie etwas verändert”

Das ist der Satz, den wir in solchen Situationen am häufigsten hören — und er beschreibt genau das Problem. Eine typische WordPress-Seite im Mittelstand läuft mit 15 bis 30 Plugins. Jedes davon ist fremder Code mit vollem Zugriff auf Datenbank und Dateisystem. Wer nichts verändert, verändert nicht das Risiko, sondern nur den eigenen Kenntnisstand darüber.

Der aktuelle Fall steht dabei nicht allein. Allein im August 2026 gab es zwei WordPress-Sicherheitsreleases im Kern sowie gemeldete Schwachstellen in mehreren weit verbreiteten Plugins. Das ist kein Zeichen dafür, dass WordPress unsicher wäre — es ist die normale Betriebsrealität eines Systems, das rund 40 Prozent des Webs antreibt und entsprechend gründlich untersucht wird. Sicher ist an WordPress nicht die Software, sondern der Umgang damit: Ein WordPress-Update, das innerhalb von Tagen eingespielt wird, macht aus einer kritischen Lücke ein Nicht-Ereignis. Dasselbe Update, das ein halbes Jahr wartet, macht daraus einen Vorfall mit Meldepflicht.

Und der ist teuer. Wird über eine gekaperte Website Schadcode ausgeliefert oder werden Kundendaten abgegriffen, greifen die Meldepflichten der DSGVO — 72 Stunden, Dokumentation, im Zweifel Kommunikation an Betroffene. Der technische Aufwand für die Bereinigung ist dabei meist der kleinere Posten.

Fünf Punkte, die Sie diese Woche prüfen sollten

1. Plugin-Version kontrollieren. Unter Plugins → Installierte Plugins nachsehen, ob “All-in-One WP Migration and Backup” aktiv ist. Alles unterhalb von 7.110 sofort aktualisieren. Auch eine deaktivierte, aber installierte Version gehört aktualisiert oder gelöscht — Code, der auf dem Server liegt, kann unter Umständen angesprochen werden.
2. Nicht ungeprüft ein altes Archiv einspielen. Wenn Sie in den vergangenen Wochen ein Backup zurückspielen wollten: erst das Plugin aktualisieren, dann importieren. Andersherum ist genau der Ablauf, der die Lücke ausnutzt.
3. Nutzerkonten und geplante Aufgaben durchsehen. Unbekannte Administratorkonten, kürzlich geänderte Passwörter oder neue Cronjobs sind die typischen Spuren nach einer Übernahme.
4. Ungenutzte Plugins entfernen, nicht nur deaktivieren. Jedes Plugin, das Sie nicht wirklich brauchen, ist eine Angriffsfläche weniger und ein Update weniger, das Sie im Blick behalten müssen.
5. Automatische Sicherheitsupdates aktivieren. Für den WordPress-Kern ist das Standard, für Plugins muss es pro Plugin eingeschaltet werden. Bei sicherheitskritischen Erweiterungen ist das in aller Regel die bessere Wahl — das Risiko eines Update-Konflikts ist deutlich kleiner als das Risiko einer offenen kritischen Lücke.

Fazit: Wartung ist kein Projekt, sondern eine Routine

Der konkrete Fall ist schnell erledigt: Version prüfen, auf 7.110 oder höher aktualisieren, kurz kontrollieren, ob jemand Spuren hinterlassen hat. Das ist eine halbe Stunde Arbeit.

Die eigentliche Frage ist die dahinter: Wer schaut bei Ihnen eigentlich regelmäßig nach — und wie schnell erfahren Sie überhaupt, dass eine Lücke Sie betrifft? In den meisten mittelständischen Unternehmen lautet die ehrliche Antwort: niemand systematisch, und meistens erst dann, wenn etwas nicht mehr funktioniert. Eine feste WordPress-Wartung ändert daran mehr als jedes einzelne Sicherheits-Plugin: monatliches Update-Fenster, Backups außerhalb des Webservers, ein kurzer Blick auf Nutzerkonten und Serverprotokolle. Das ist unspektakulär und genau deshalb wirksam.

Wenn Sie nicht sicher sind, in welchem Zustand Ihre Website gerade ist, oder Ihnen intern schlicht die Zeit für diese Routine fehlt: Wir übernehmen Betrieb und Wartung von WordPress-Seiten für Unternehmen aus der Region Hannover — inklusive Update-Zyklus, Backup-Konzept und einer Einschätzung, welche Plugins Sie sich sparen können. Mehr dazu auf unserer Seite zur Web & Software Entwicklung.