Wenn Ihre Website auf WordPress läuft, sollten Sie jetzt nicht nur nach Updates suchen, sondern die gesamte Angriffsfläche prüfen. CISA nahm am 25. September 2026 mit CVE-2026-87902 eine WordPress-Core-Schwachstelle in den Katalog bekannter ausgenutzter Sicherheitslücken (KEV) auf. Laut Katalog kann eine nicht authentifizierte Person über eine Remote-File-Inclusion-Schwachstelle lokalen PHP-Code außerhalb der aktiven Theme-Verzeichnisse einbinden, was zu Remote Code Execution führen kann.

Für KMU und Tech-Teams im DACH-Raum ist die sinnvolle Reaktion kein hektisches Plugin-Update nach dem Motto „wird schon passen“. Prüfen Sie in den nächsten 48 Stunden Version, Erreichbarkeit, Rechte, Backups und Logdaten – und dokumentieren Sie das Ergebnis. So wird aus einem aktuellen Security-Hinweis ein belastbarer Betriebsablauf.

Was der KEV-Eintrag bedeutet – und was nicht

Der KEV-Katalog der US-Cybersicherheitsbehörde CISA führt Schwachstellen, für die es Hinweise auf aktive Ausnutzung gibt. Die Aufnahme ist kein Beweis, dass jede WordPress-Installation betroffen oder kompromittiert ist. Sie ist aber ein klares Priorisierungssignal: Das Thema gehört vor geplante Optimierungen, Content-Arbeit oder ein gewöhnliches Wartungsfenster.

Entscheidend ist die Abgrenzung. Prüfen Sie zuerst, ob tatsächlich WordPress Core eingesetzt wird, welche Version produktiv läuft und ob ein vom Hersteller bereitgestelltes Sicherheitsupdate verfügbar ist. Verwechseln Sie den Kern nicht mit Themes oder Plugins: Auch wenn der aktuelle Eintrag den Core betrifft, können veraltete Erweiterungen, schwache Admin-Zugänge oder zu weitreichende Dateirechte den gleichen Vorfall deutlich schwerer beherrschbar machen.

Die ersten 48 Stunden: eine pragmatische Reihenfolge

Beginnen Sie nicht am Server mit Änderungen auf Verdacht. Eine kurze, nachvollziehbare Bestandsaufnahme verhindert, dass wichtige Spuren verschwinden oder ein funktionierender Dienst unnötig ausfällt.

  • Instanzen erfassen: Listen Sie alle produktiven WordPress-Seiten auf – Hauptdomain, Microsites, Landingpages, Staging und historische Installationen. Gerade vergessene Kampagnenseiten liegen oft auf derselben Infrastruktur.
  • Version und Patchstand prüfen: Erfassen Sie Core-Version, aktive Themes und Plugins. Prüfen Sie anschließend die offiziellen Herstellerhinweise und spielen Sie freigegebene Sicherheitsupdates zuerst in einer kontrollierten Umgebung ein, sofern Ihr Ablauf das zulässt.
  • Öffentliche Erreichbarkeit reduzieren: Nicht benötigte Testsysteme vom Internet nehmen, Admin-Zugänge einschränken und sensible Verwaltungswege zusätzlich absichern. Eine Website muss öffentlich erreichbar sein; das Backend nicht zwingend von überall.
  • Backups nicht nur abhaken: Prüfen Sie, ob ein aktuelles, getrennt gespeichertes Backup vorhanden ist und ob ein Restore getestet wurde. Ein Backup ohne Wiederherstellungsnachweis ist keine belastbare Rückfalloption.
  • Logs sichern und auf Auffälligkeiten prüfen: Webserver-, PHP-, WAF- und Authentifizierungslogs vor größeren Bereinigungen sichern. Suchen Sie nach unerwarteten Admin-Logins, neuen PHP-Dateien, ungewöhnlichen POST-Requests und Änderungen an Themes oder Upload-Verzeichnissen.

Warum ein Update allein nicht genügt

Ein Security-Update schließt eine bekannte Schwachstelle, beantwortet aber zwei andere Fragen nicht: War die Instanz vor dem Update bereits betroffen? Und kann ein Angreifer über einen anderen Weg wieder hinein? Deshalb gehören Patchen, forensische Ersteinschätzung und Härtung zusammen.

Bei WordPress sind einige Kontrollen besonders wirksam: individuelle Admin-Konten statt gemeinsamer Zugänge, Multi-Faktor-Authentifizierung für alle privilegierten Accounts, minimale Rollenrechte, getrennte Deployments statt Änderungen im Produktionssystem und regelmäßige Updates mit klarer Zuständigkeit. Ebenso wichtig sind restriktive Dateirechte und eine saubere Trennung zwischen Webprozess, Datenbank und Backup-Ziel.

Für Teams mit mehreren Websites lohnt sich ein kleines Asset-Register: Domain, Verantwortliche, Hosting, WordPress-Version, letzte Aktualisierung, Backup-Status und Notfallkontakt. Diese Liste ist kein Compliance-Projekt. Sie verkürzt im Ernstfall die Zeit bis zur ersten verlässlichen Entscheidung erheblich.

Der Blick auf Hosting, Agentur und interne Zuständigkeiten

Viele Unternehmen betreiben ihre Website nicht selbst. Das ändert die Verantwortung nicht, aber den Ablauf. Klären Sie schriftlich, wer Sicherheitsupdates einspielt, wer Zugriff auf Logs und Backups hat, wie schnell bei kritischen Hinweisen reagiert wird und wer eine Website im Zweifel temporär abschalten darf. „Das macht unsere Agentur“ ist ohne Reaktionsweg und Kontaktperson keine Incident-Response-Strategie.

Auch Managed-Hosting ist keine pauschale Entlastung. Der Anbieter kann Infrastruktur und teilweise Updates absichern; Theme-Code, individuelle Integrationen, Redaktionskonten und externe Formulare bleiben oft beim Website-Betreiber. Ein kurzer Abgleich des Leistungsumfangs ist daher sinnvoller als Annahmen über Zuständigkeiten.

Wann externe Hilfe sinnvoll ist

Holen Sie Unterstützung, wenn die WordPress-Version unklar ist, verdächtige Dateien oder Logeinträge auftauchen, Administratoren unerwartet hinzugefügt wurden oder die Website geschäftskritisch ist. Dann sollte die Reihenfolge von Sicherung, Analyse, Eindämmung, Bereinigung und kontrollierter Wiederinbetriebnahme geführt erfolgen. Unkoordinierte „Clean-up“-Aktionen können Belege zerstören und die Ursache verdecken.

FEHMER TECH unterstützt DACH-Teams bei der strukturierten Bewertung von Internet-Angriffsflächen, Zugängen, Backups, Härtung und Monitoring. Ein Security Quick Audit startet ab 490 € und liefert ein priorisiertes Risikobild statt eines unkommentierten Scanner-Exports. Bei einer Webanwendung mit klar definiertem Scope kann anschließend ein Pentest sinnvoll sein – nicht als Ersatz für Patch-Management, sondern als unabhängige Prüfung der realen Angriffsfläche.

Die dauerhafte Lehre aus dem aktuellen Hinweis

Aktive Ausnutzung ist kein Anlass für Panik, aber ein Test für die eigene Betriebsreife. Wer binnen eines Arbeitstags sagen kann, welche WordPress-Instanzen existieren, wer sie verantwortet, wie ihr Patchstand aussieht und ob ein Restore funktioniert, hat bereits viel gewonnen. Für alle anderen ist genau jetzt der richtige Zeitpunkt, diesen Ablauf aufzubauen.

Quellen