Am 22. September 2026, am Vorabend des Feiertags zum Nationalfeiertag, veröffentlichte WordPress das Sicherheitsupdate 7.1.2, um CVE-2026-87902 zu schließen. Die Lücke steckt nicht in einem Plugin oder Theme. Sie steckt im WordPress-Kern und betrifft jede Version von 4.7.0 bis 7.1.1. Am selben Tag um 11:49 UTC (2:49 Uhr nachmittags Riad-Zeit) sah das Sicherheitsunternehmen Patchstack den ersten Versuch, sie auszunutzen, und weniger als vier Stunden später den ersten Versuch, eine Datei auf den Server einer Website zu schreiben.

Wie sich der Angriff in fünf Tagen ausbreitete

Dann breitete er sich aus. Laut dem heute, am 28. September, veröffentlichten Bericht von CrowdSec registrierte dessen Netzwerk zwischen dem 23. und dem 27. September 322.680 Angriffssignale, die zur Lücke passten, von 30.813 verschiedenen IP-Adressen, mit einem Höhepunkt am 27. September bei 124.154 Signalen. Die saudische Nationale Behörde für Cybersicherheit (NCA) gab am 23. September eine kritische Warnung heraus, Nr. 2026-7873, und die US-Behörde CISA nahm die Lücke am 25. September in ihren Katalog bekannter ausgenutzter Schwachstellen auf.

Was die Lücke bewirkt, einfach erklärt

Wenn ein Besucher eine Seite aufruft, entscheidet WordPress, welche Template-Datei des Themes für die Darstellung verwendet wird. Der Fehler liegt in diesem Schritt: Ein nicht angemeldeter Angreifer kann ihn auf eine PHP-Datei lenken, die außerhalb des Theme-Ordners auf dem Server liegt, und WordPress führt sie aus. WordPress bewertet die Lücke mit 9.2 von 10; CISA mit 8.1.

Zur Kontrolle über die Website wird sie, wenn die in der WordPress-Sicherheitsmeldung und in den Berichten der Forscher genannten Bedingungen zusammentreffen:

  • Das Theme: Das aktive Theme enthält einen Ordner, dessen Name mit page- beginnt. Die Meldung nennt Twenty Twelve, Twenty Fourteen, Neve, Hestia und Sydney unter den Themes, bei denen das der Fall ist.
  • Eine PHP-Einstellung: register_argc_argv ist aktiviert, was laut CrowdSec die Standardeinstellung in den offiziellen PHP-Docker-Images und auf cPanel-Servern mit PHP älter als 8.5 ist.
  • Eine Hilfsdatei: pearcmd.php von PEAR liegt auf dem Server. Angreifer nutzen sie, um neue PHP-Dateien zu schreiben, also eine Hintertür, die das Update überlebt.

Die Lücke trifft also nicht jede Website gleich, aber Security Affairs fasst es so zusammen: Codeausführung erfordert, dass die Serverkonfiguration passt, und bei vielen Servern passt sie. Ein Unternehmer weiß meist nicht, welches Theme aktiv ist oder wie der Server konfiguriert ist, daher ist die sichere Annahme, dass die Website gefährdet ist, bis das Gegenteil bewiesen ist.

Warum der Angriff nach Stunden kam und nicht nach Wochen

Ein Sicherheitsupdate verrät naturgemäß, wo der Fehler liegt, denn die Codeänderung ist öffentlich. Patchstack zufolge entsprachen die ersten Payloads exakt dem Muster, das der Fix geschlossen hat, das heißt, wer sie geschrieben hat, ging vom Fix selbst aus und nicht von einer eigenständigen Entdeckung. Die ersten Versuche riefen gewöhnliche WordPress-Kerndateien wie wp-login.php und wp-cron.php auf, um zu sehen, wie die Websites reagierten, und gingen dann zum Schreiben von Dateien über.

Der Datenverkehr trägt zudem die Fingerabdrücke automatisierter Scanner und veröffentlichten Proof-of-Concept-Codes. Für einen Unternehmer bedeutet das: Niemand sucht sich gezielt Ihre Website aus. Die Werkzeuge durchkämmen jede WordPress-Website, die sie erreichen können, und der Unterschied zwischen einer kompromittierten und einer sauberen Website ist, ob das Update vor ihnen da war.

Aktualisiert sich Ihre Website selbst?

Wahrscheinlich, aber verlassen Sie sich nicht darauf. WordPress hat seit Version 3.7 automatische Hintergrund-Updates, und seit 5.6 aktualisieren neue Installationen sowohl Minor- als auch Major-Releases automatisch. Die Ankündigung zu 7.1.2 besagt, dass Websites, die automatische Hintergrund-Updates unterstützen, sich automatisch zu aktualisieren beginnen.

Automatische Updates lassen sich aber mit einer einzigen Zeile in wp-config.php abschalten. Manche Entwickler schalten sie absichtlich ab, damit ein Update kein angepasstes Theme beschädigt, und manche Hoster verwalten Updates auf ihrer Seite. Eine Website, die ein Freelancer vor Jahren gebaut hat und deren Vertrag inzwischen ausgelaufen ist, kann unbemerkt auf einer alten Version stehen bleiben. So prüfen Sie es:

  • Melden Sie sich im Admin-Bereich der Website an, öffnen Sie die Seite Aktualisierungen im Menü Dashboard, und dort sehen Sie die aktuelle Version.
  • Die sichere Version ist 7.1.2 oder neuer. Läuft Ihre Website auf einem älteren Zweig, hat der Fix jeden Zweig bis zurück zu 4.7 erreicht, darunter 7.0.6, 6.9.9, 6.8.10 und 4.7.37; die vollständige Liste steht in der in den Quellen verlinkten WordPress-Sicherheitsmeldung.
  • Beachten Sie, dass laut WordPress nur die neueste Version aktiv unterstützt wird. Eine Website, die auf einem alten Zweig belassen wurde, hat diesen Fix erhalten, lebt aber auf geliehene Zeit. Was die neue Version einer Unternehmenswebsite bringt, haben wir in WordPress 7.1: die wichtigsten Neuerungen beschrieben.

Auch Elementor: ein Link genügt

In derselben Woche behob Elementor, der beliebte Page Builder für WordPress, eine Lücke, die nur die Versionen 4.3.0 und 4.3.1 betrifft. Öffnet ein Website-Administrator einen präparierten Link, während er angemeldet ist, kann ein Angreifer ein Administratorkonto anlegen, das er kontrolliert, und der Link kann per E-Mail, Chat oder Kommentar kommen. Laut BleepingComputer laufen diese Versionen auf bis zu 2 Millionen Websites. Der Fix erschien am 24. September in 4.3.2, und die Seite meldete zum Zeitpunkt der Veröffentlichung keine aktive Ausnutzung.

Stellen Sie sicher, dass Elementor auf 4.3.2 oder neuer läuft, und machen Sie es zur Teamregel: keine Links aus Nachrichten oder Kommentaren öffnen, während man im Admin-Bereich der Website angemeldet ist.

Wenn Ihre Website seit dem 22. September nicht aktualisiert wurde

  • Jetzt aktualisieren: Fürchtet der Entwickler, dass das Update etwas beschädigt, lässt sich laut Patchstack der Weg vorübergehend schließen, indem Directory-Traversal-Versuche im Parameter pagename blockiert werden oder register_argc_argv abgeschaltet wird. Das ist Aufgabe des Hosters oder Entwicklers und ersetzt nicht das Update.
  • Gehen Sie davon aus, dass Ihre Website abgetastet wurde: Bitten Sie den Entwickler oder Hoster, nach PHP-Dateien zu suchen, die niemand hinzugefügt hat, besonders in /tmp und /var/tmp, wo Patchstack Dateien wie poc87902.php und wp-pear-rce-flag.php als Anzeichen erfolgreicher Codeausführung nennt.
  • Wenn etwas gefunden wird: Behandeln Sie es als Sicherheitsvorfall, nicht als Update. Ändern Sie die Passwörter für Admin-Konten, Datenbank und Hosting, stellen Sie die Website aus einem sauberen Backup wieder her und aktualisieren Sie sie dann.
  • Wenn die Website Kundendaten enthält: Speichert sie Bestellungen, Kontaktformulare oder Konten, verpflichtet der Leitfaden der Saudischen Behörde für Daten und Künstliche Intelligenz (SDAIA) zu Verletzungen personenbezogener Daten den Verantwortlichen, die zuständige Behörde innerhalb von 72 Stunden zu benachrichtigen, nachdem er von einer Verletzung erfahren hat, die den Daten oder den betroffenen Personen schaden könnte.

Die Sicht von Origami

Viele Unternehmenswebsites werden auf WordPress gebaut und dann wie eine gedruckte Broschüre behandelt: Der Entwickler übergibt sie, der Inhaber zahlt, und niemand fragt, wer sie aktuell hält. Diese Lücke erinnert daran, dass eine Website ein lebendes System auf einem mit dem Internet verbundenen Server ist und dass die Spanne zwischen der Veröffentlichung eines Fixes und dem Eintreffen eines Angreifers heute in Stunden gemessen wird. Die eigentliche Frage ist nicht, ob WordPress sicher ist, denn es hat den Fehler behoben und den Fix an jeden Zweig bis zurück zu 4.7 verteilt. Sie lautet, wer in Ihrem Unternehmen dafür verantwortlich ist, ihn zu installieren.

Deshalb sind wir der Meinung, dass ein Wartungsvertrag für eine Website eine Höchstfrist für die Installation kritischer Sicherheitsupdates festlegen, eine Staging-Kopie vorschreiben sollte, auf der Updates vor der Live-Website getestet werden, und regelmäßige Backups vorsehen sollte, die außerhalb des Servers selbst gespeichert werden. Und wenn Updates immer wieder verschoben werden, weil das Theme so angepasst ist, dass es bei jedem Update bricht, ist das ein Problem der Bauweise der Website, nicht von WordPress, und es verdient eine Lösung vor der nächsten Lücke.

Fazit: drei Schritte

  • Heute: Öffnen Sie den Admin-Bereich und bestätigen Sie, dass die Version 7.1.2 oder das korrigierte Release Ihres Zweigs ist und dass Elementor auf 4.3.2 oder neuer läuft.
  • Diese Woche: Bitten Sie den Entwickler oder Hoster, den Server nach unbekannten PHP-Dateien zu durchsuchen und schriftlich zu bestätigen, dass automatische Updates aktiviert sind.
  • Diesen Monat: Nehmen Sie eine Höchstfrist für die Installation von Sicherheitsupdates in den Wartungsvertrag auf und benennen Sie die verantwortliche Person.

Quellen