Am 6. August erschien WordPress 7.0.3 und schloss zwölf Lücken. Über die schwerste davon haben wir damals geschrieben: eine Schwachstelle auf der Anmeldeseite, ausnutzbar ohne eigenen Zugang, mit der Möglichkeit, am Ende fremden PHP-Code auszuführen. Sechs Tage später hat sich die Lage geändert — nicht technisch, sondern in der Dringlichkeit.
Die Lücke heisst jetzt CVE-2026-64638 und wird als «hoch» eingestuft. Sicherheitsforscher haben ihr den Namen XSS2Shell gegeben. Und das Canadian Centre for Cyber Security berichtet von Hinweisen darauf, dass sie bereits ausgenutzt wird. Aus «bitte einspielen» ist «es wird angegriffen» geworden.
An der Abhilfe ändert das nichts: WordPress 7.0.3 ist gegen diese Angriffe gerüstet, und das Update gibt es seit dem 6. August. Interessant ist deshalb nicht die Frage, was zu tun ist, sondern eine andere — ob es auf Ihrer Website tatsächlich passiert ist.
Warum ein Klick genügt
Der Ablauf ist ungewöhnlich, und er lohnt das Verständnis, weil er die übliche Vorstellung von einem Angriff auf den Kopf stellt. Angegriffen wird nicht Ihr Server von aussen. Angegriffen wird über den Browser von jemandem, der Zugang zu Ihrer Website hat.
Ein Angreifer baut eine harmlos wirkende Seite. Darin liegt ein unsichtbares Formular, das auf die Anmeldeseite Ihrer WordPress-Installation zeigt. Wer diese Seite besucht — etwa nach einem Klick in einer Phishing-Mail —, schickt das Formular ab, ohne etwas zu tun: Ein Skript erledigt das im Hintergrund.
Was dabei als «Benutzername» übermittelt wird, ist keiner, sondern präparierter HTML-Code. Ihre WordPress-Installation verarbeitet ihn und baut ihn in die Fehlermeldung der Anmeldeseite ein. Diese Fehlerseite sieht das Opfer nun im Browser — mitsamt dem eingeschleusten Code. Und weil sie von Ihrer echten Domain kommt, läuft der fremde Code mit allen Rechten und Cookies, die der Besucher auf Ihrer Website hat.
Hier trennt sich der Schaden. Bei einem gewöhnlichen Besucher bleibt es bei Code im Browser — unschön, aber begrenzt. Ist die betroffene Person dagegen als Administrator angemeldet, lässt sich über einen zusätzlichen Schritt ein Zugangstoken abgreifen. Damit kann der Angreifer eigenen PHP-Code hochladen und ausführen. An diesem Punkt gehört die Installation ihm.
Das Unangenehme daran: Es braucht keine Lücke in Ihrem Hosting, kein schwaches Passwort und keinen unachtsamen Moment beim Login. Es genügt, dass eine Person mit Administratorrechten irgendwann auf einen Link klickt.
Die Frage, die jetzt zählt
In unserem Beitrag zu WordPress 7.0.3 steht, dass Sicherheitsupdates in der Regel von selbst kommen. Das stimmt — und es ist der Grund, warum die meisten Installationen längst geschützt sind. Es stimmt aber nur, solange die Automatik auch läuft.
Sie scheitert still, und zwar häufiger als gedacht: wenn Dateirechte das Schreiben verhindern, wenn ein Sicherheits-Plugin oder ein Eintrag in der `wp-config.php` sie abgeschaltet hat, wenn die Installation keine Hintergrundprozesse ausführen kann, oder wenn eine Website so wenig besucht wird, dass der auslösende Aufruf schlicht ausbleibt. In keinem dieser Fälle bekommen Sie eine Meldung. Es passiert einfach nichts.
Der Nachweis dauert zehn Sekunden. Melden Sie sich im Backend an und schauen Sie unter Dashboard → Aktualisierungen nach, welche Version dort steht. Alles ab 7.0.3 ist in Ordnung. Steht dort eine ältere Nummer, ist Ihre Website für einen Angriff offen, der nachweislich stattfindet — dann ist das Update die dringlichste Aufgabe des Tages.
Wenn Sie zu spät prüfen
Ein Update schliesst eine Lücke. Es entfernt nicht, was vorher durch sie hindurchgekommen ist.
War eine Installation ungepatcht am Netz, während die Angriffe liefen, kann bereits etwas zurückgeblieben sein: eine getarnte Datei, ein zusätzliches Administratorkonto, ein manipuliertes Plugin. Solche Rückstände überstehen jedes weitere Update unbeschadet, weil sie zum normalen Bestand der Installation gehören, sobald sie einmal dort liegen. Wie eine solche Angriffswelle abläuft, haben wir bei der wp2shell-Welle im Juli beschrieben — eine andere Lücke, aber dasselbe Muster.
Wer den Verdacht hat, dass zwischen dem 6. August und dem Einspielen des Updates etwas passiert ist, sollte nicht die Version hochzählen, sondern den Einbruchsweg suchen. Genau das ist unsere Hack- und Malware-Bereinigung.
Für betreute Websites erledigt
Wo wir die Wartung übernehmen, ist dieser Fall abgedeckt: Wir spielen Sicherheitsupdates kontrolliert ein und prüfen danach, ob die neue Version tatsächlich aktiv ist — nicht ob das Update angestossen wurde, sondern ob es angekommen ist. Das ist der Unterschied, um den es in diesem Artikel geht. Für Joomla gilt dasselbe, dort mit eigener Update-Mechanik; beschrieben ist es unter Joomla-Wartung, CMS-übergreifend unter Wartung und Monitoring.
Unsicher, welche WordPress-Version bei Ihnen läuft — oder ob in den Tagen davor schon etwas passiert ist? Melden Sie sich, wir sehen nach.