Vom Update zum Exploit in Stunden: WordPress unter Beschuss
Kaum war der Patch draußen, klopften schon die ersten Angreifer an: Die kritische WordPress-Lücke CVE-2026-87902 zeigt, wie schnell aus einem Sicherheitsupdate ein Wettlauf gegen die Zeit wird. Was hinter der Schwachstelle steckt, wie die Angriffe in drei Stufen ablaufen und warum das Update jetzt dringend ist.
WordPress-Betreiber stehen aktuell unter Druck: Eine kritische Sicherheitslücke mit der Kennung CVE-2026-87902 steckt in der Auflösung von Seitentemplates und erlaubt eine unauthentifizierte Local File Inclusion. Der Sicherheitsanbieter Patchstack, der den Fall dokumentiert, bewertet die Schwachstelle mit einem CVSS-Score von 9.2 und stuft sie damit als kritisch ein.
Besonders brisant ist das Tempo. Nach Angaben von Patchstack trafen die ersten Angriffsversuche bereits am 22. September 2026 um 11:49 UTC ein, also am selben Tag, an dem die abgesicherte Version 7.1.2 erschien. Binnen eines Tages entwickelte sich die Kampagne von reiner Erkundung hin zu tatsächlicher Codeausführung.
Wie die Lücke funktioniert
Technisch geht es um eine Path-Traversal-Schwäche, die zu einer Local File Inclusion und unter bestimmten Bedingungen zu Remote Code Execution führt. Betroffen sind alle Versionen von 4.7.0 bis 7.1.1. Eine Anmeldung braucht es nicht, was die Angriffshürde denkbar niedrig hält.
Ein Detail im Angriffsmuster ist verräterisch. WordPress schickt den Slug durch einen eigenen Sanitizer, der einfache ../-Sequenzen aussortiert, prozentkodierte Varianten aber durchlässt. Deshalb trifft der Traversal-Pfad immer kodiert ein, und der Parameter page_id muss zusätzlich auf eine echte Seite verweisen, sonst läuft der verwundbare Code gar nicht erst an.
Vom Abtasten zur Codeausführung
Patchstack beschreibt drei klar erkennbare Angriffsstufen. In der ersten Stufe, die noch immer den Großteil des Traffics ausmacht, richten Angreifer die Inclusion auf harmlose Kerndateien wie wp-links-opml.php, um überhaupt zu prüfen, ob ein Host anfällig ist.
In der zweiten Stufe zielt der Angriff auf die Datei pearcmd.php des PEAR-Pakets. Ist in der PHP-Konfiguration register_argc_argv aktiv, landet die Query-Zeichenkette als Argument im eingebundenen Skript. In der dritten Stufe schreiben die Angreifer dann per config-create eigene PHP-Dateien auf die Platte, und genau das ist faktisch Codeausführung.
Die beobachteten Payloads teilen sich grob in zwei Lager. Ein Teil hinterlässt nur harmlose Markierungen, um verwundbare Hosts zu katalogisieren, ein anderer schreibt kurze Tags, die beim Aufruf Shell-Befehle ausführen. Die Dateien landen bislang in /tmp und /var/tmp und sind damit meist nicht über das Web erreichbar, belegen aber die vollständige Kompromittierung des Systems.
Massenhafte Ausnutzung und Gegenmaßnahmen
Aus dem Werk einiger weniger Akteure ist längst Massenware geworden. Ein benanntes Nuclei-Template kursiert öffentlich, die Zugriffe verteilen sich inzwischen auf mehrere Hundert IP-Adressen, und das Volumen erreichte laut Patchstack am Mittag des 23. September seinen bisherigen Höhepunkt. Auf den User Agent sollte man sich als Filter nicht verlassen, da die meisten Anfragen gefälschte Browserkennungen tragen.
Als Gegenmittel bleibt vor allem das Update: WordPress hat den Fix bis zurück zu Version 4.7.37 portiert, sodass auch ältere Installationen ohne großen Versionssprung abgesichert werden können. Wer nicht sofort aktualisieren kann, sollte Traversal-Sequenzen im Parameter pagename blockieren und register_argc_argv deaktivieren, was die pearcmd-Kette unterbricht. In den Logs lohnt der Blick auf Muster wie %2e%2e, auf die Kombination aus pagename und page_id sowie auf verdächtige PHP-Dateien in /tmp und /var/tmp.