WP2Shell: Wenn WordPress plötzlich zur Hintertür für Angreifer wird

WordPress gilt als ausgereiftes und grundsätzlich sicheres Content-Management-System. Sicherheitsprobleme entstehen in der Praxis häufig durch veraltete Plugins, unsichere Themes, schwache Passwörter oder schlecht gewartete Installationen.

Beim aktuell bekannt gewordenen WP2Shell-Sicherheitsproblem ist die Situation jedoch deutlich ernster: Die zugrunde liegenden Schwachstellen befinden sich direkt im WordPress-Core. Damit können auch WordPress-Installationen betroffen sein, auf denen keine unsicheren Plugins oder Themes installiert sind.

WordPress veröffentlichte deshalb am 17. Juli 2026 ein außerplanmäßiges Sicherheitsupdate. WordPress 7.0.2 behebt ein als kritisch sowie ein als hoch eingestuftes Sicherheitsproblem. Aufgrund der Schwere der Schwachstellen wurden für betroffene Installationen sogar erzwungene automatische Updates aktiviert.

Besonders problematisch ist allerdings:

Ein WordPress-Update schließt zwar die Sicherheitslücke – es entfernt aber keine bereits installierten Backdoors.

 

Was ist WP2Shell?

Unter der Bezeichnung WP2Shell wird eine Angriffskette zusammengefasst, mit der Angreifer unter bestimmten Voraussetzungen ohne vorherige Anmeldung Schadcode auf einer WordPress-Website ausführen konnten.

Dabei spielen zwei inzwischen dokumentierte Sicherheitslücken eine Rolle:

CVE-2026-60137
Eine SQL-Injection-Schwachstelle im WordPress-Core.

CVE-2026-63030
Eine Schwachstelle im Zusammenhang mit REST-API-Batch-Routen, die in Kombination mit der SQL-Injection zur Ausführung von Code führen konnte.

WordPress selbst bestätigt, dass die Kombination der Schwachstellen eine Remote Code Execution (RCE) ermöglichte.

Remote Code Execution bedeutet vereinfacht:

Ein Angreifer kann unter bestimmten Bedingungen eigenen Programmcode auf dem Server ausführen, ohne sich vorher regulär im WordPress-Backend anmelden zu müssen.

Genau deshalb ist WP2Shell wesentlich gefährlicher als viele klassische WordPress-Sicherheitsprobleme.

Welche WordPress-Versionen sind von WP2Shell betroffen?

Nach Angaben der Sicherheitsforscher und von WordPress.org waren insbesondere folgende Versionen relevant:

WordPress 6.9.0 bis 6.9.4
Diese Versionen waren von beiden Schwachstellen betroffen. Die Fehler wurden mit WordPress 6.9.5 behoben.

WordPress 7.0.0 bis 7.0.1
Auch diese Versionen waren betroffen. Die Fehler wurden mit WordPress 7.0.2 behoben.

WordPress 6.8
Dieser Versionszweig war laut WordPress nur von der ersten Schwachstelle betroffen. Hierfür wurde WordPress 6.8.6 veröffentlicht.

WordPress-Versionen vor 6.8 sind laut offizieller Mitteilung von diesen konkreten Schwachstellen nicht betroffen.

Wer eine betroffene Installation betreibt, sollte daher unbedingt kontrollieren, ob das Sicherheitsupdate tatsächlich durchgeführt wurde.

Sich darauf zu verlassen, dass das automatische Update vermutlich funktioniert hat, halten wir bei einer derart kritischen Sicherheitslücke für keine gute Strategie.

Wie macht sich eine gehackte WordPress-Website bemerkbar?

Das Schwierige an professionell kompromittierten WordPress-Websites ist, dass man den Angriff häufig zunächst überhaupt nicht bemerkt.

Die Website funktioniert scheinbar normal.

Das WordPress-Backend funktioniert.

Beiträge können bearbeitet werden.

Und trotzdem befindet sich im Hintergrund bereits eine Backdoor auf dem Server.

Typische Hinweise sind beispielsweise:

• plötzlich vorhandene unbekannte Administratoren
• unbekannte PHP-Dateien im WordPress-Verzeichnis
• PHP-Dateien innerhalb von /wp-content/uploads/
• unbekannte Dateien oder Plugins unter /wp-content/mu-plugins/
• Veränderungen an WordPress-Core-Dateien
• plötzlich auftauchende Spam-Seiten bei Google
• Casino-, Pharma-, Kredit- oder Erotik-Suchbegriffe in Google
• Weiterleitungen auf fremde Websites
• unbekannte Benutzer direkt in der Datenbank
• Benutzer, die nach dem Löschen wieder auftauchen
• unbekannte Cronjobs
• ungewöhnliche Einträge in wp_options
• plötzlich veränderte .htaccess-, .user.ini– oder Konfigurationsdateien
• Warnungen eines Sicherheitsscanners wie Wordfence

Keines dieser Symptome beweist für sich allein einen WP2Shell-Angriff. Treten mehrere davon gleichzeitig auf, sollte eine WordPress-Installation allerdings dringend genauer untersucht werden.

Warum das Löschen einer Malware-Datei nicht ausreicht

Einer der häufigsten Fehler bei der Bereinigung gehackter WordPress-Seiten lautet:

„Wordfence hat eine infizierte Datei gefunden. Wir haben sie gelöscht. Damit ist das Problem behoben.“

Leider ist es häufig nicht so einfach.

Hat ein Angreifer bereits die Möglichkeit erhalten, PHP-Code auszuführen, muss grundsätzlich davon ausgegangen werden, dass er weitere Dateien oder Zugänge angelegt haben könnte.

Ein Angreifer könnte beispielsweise:

• mehrere Webshells installieren,
• einen neuen WordPress-Administrator anlegen,
• PHP-Code in einer bestehenden Datei verstecken,
• ein manipuliertes MU-Plugin installieren,
• Datenbankeinträge verändern,
• Cronjobs anlegen,
• JavaScript in die Website einschleusen,
• zusätzliche Zugangsmöglichkeiten vorbereiten.

Das bedeutet:

Die zuerst gefundene Schadsoftware kann nur die sichtbare Spitze des Problems sein.

Update durchgeführt? Dann beginnt bei einem bereits erfolgten Angriff erst die eigentliche Arbeit

Das Update auf WordPress 7.0.2 beziehungsweise 6.9.5 ist unbedingt notwendig.

Es verhindert allerdings nur, dass die geschlossene Sicherheitslücke weiterhin auf demselben Weg ausgenutzt werden kann.

Wurde die Website bereits vor dem Update kompromittiert, können zuvor angelegte Backdoors weiterhin vorhanden sein.

Ein einfaches Beispiel:

Ein Einbrecher gelangt durch eine defekte Tür in ein Gebäude und versteckt anschließend einen zweiten Schlüssel im Garten.

Die Tür wird repariert.

Der versteckte Schlüssel verschwindet dadurch aber nicht.

Bei einem kompromittierten WordPress-System verhält es sich ähnlich.

Typische Verstecke von Webshells und WordPress-Backdoors

Bei der Untersuchung einer gehackten WordPress-Installation müssen mehrere Bereiche kontrolliert werden.

1. Das Upload-Verzeichnis

Das Verzeichnis

/wp-content/uploads/

enthält normalerweise Bilder, PDFs, Videos und andere hochgeladene Medien.

PHP-Dateien sind dort zumindest bei vielen normalen WordPress-Websites ungewöhnlich und sollten daher genauer untersucht werden.

Besonders verdächtig sind Dateien mit:

• kryptischen Dateinamen
• sehr kurzem PHP-Code
• verschleiertem Code
• eval()
• base64_decode()
• gzinflate()
• dynamisch ausgeführten Requests

Allerdings gilt auch hier:

Nicht jede Datei mit einer solchen Funktion ist automatisch Malware. Eine Bewertung sollte immer im Kontext erfolgen.

2. MU-Plugins

Ein häufig übersehener Bereich ist:

/wp-content/mu-plugins/

MU steht für Must Use Plugins.

Diese Plugins werden von WordPress automatisch geladen und erscheinen nicht wie normale Plugins in der klassischen Plugin-Verwaltung.

Gerade deshalb eignen sie sich hervorragend als Versteck für eine Backdoor.

Gleichzeitig verwenden viele professionelle Hosting-Anbieter legitime MU-Plugins für Cache-, Sicherheits-, Login- oder Verwaltungsfunktionen.

Man darf deshalb nicht einfach alles aus diesem Verzeichnis löschen.

Jede Datei muss zunächst darauf geprüft werden, woher sie stammt und welche Aufgabe sie erfüllt.

3. WordPress-Core-Dateien

Besondere Aufmerksamkeit verdienen zentrale Dateien wie beispielsweise:

• index.php
• wp-settings.php
• wp-load.php
• wp-blog-header.php

und Dateien innerhalb von:

/wp-admin/

sowie

/wp-includes/

Bei diesen Dateien ist ein Vergleich mit einer sauberen WordPress-Version besonders sinnvoll.

4. Themes und Child-Themes

Auch Theme-Dateien können manipuliert werden.

Häufig kontrollierte Dateien sind beispielsweise:

• functions.php
• header.php
• footer.php
• individuell angelegte PHP-Dateien

Besonders bei alten oder nicht mehr verwendeten Themes lohnt sich eine genaue Kontrolle.

5. wp-config.php

Die Datei wp-config.php enthält zentrale Einstellungen einer WordPress-Installation und ist deshalb besonders sensibel.

Hier befinden sich unter anderem die Zugangsdaten zur Datenbank.

Unbekannte PHP-Anweisungen, Includes oder ungewöhnlicher Code sollten daher immer überprüft werden.

6. .user.ini und PHP-Konfiguration

Auch Dateien wie

.user.ini

oder Server-Konfigurationen können Einfluss darauf haben, welche PHP-Dateien automatisch geladen werden.

Allerdings ist auch hier Vorsicht notwendig:

Security-Produkte wie Wordfence verwenden beispielsweise legitime Mechanismen dieser Art für ihre Web Application Firewall.

Eine ungewöhnliche Zeile ist also nicht automatisch ein Beweis für einen Angriff.

Besonders gefährlich: Versteckte WordPress-Administratoren

Bei unseren eigenen Untersuchungen in den vergangenen Tagen gehörten unbekannte Administratoren zu den auffälligsten Symptomen kompromittierter WordPress-Installationen.

WordPress speichert Benutzer unter anderem in den Datenbanktabellen:

wp_users

und

wp_usermeta

Bei manchen Angriffsszenarien kann ein Benutzer direkt in der Datenbank vorhanden sein, obwohl die Situation im WordPress-Backend zunächst anders aussieht.

Besonders kritisch wird es, wenn ein unbekannter Benutzer gelöscht wird und kurze Zeit später erneut erscheint.

Dann sollte man keinesfalls einfach immer wieder denselben Benutzer löschen.

Es muss untersucht werden:

Wer oder was legt diesen Benutzer erneut an?

Mögliche Ursachen sind beispielsweise:

• eine Backdoor
• ein manipuliertes Plugin
• ein manipuliertes MU-Plugin
• ein Cronjob
• Schadcode in einer Theme-Datei
• Schadcode im WordPress-Core
• externe Zugriffe mit noch gültigen Zugangsdaten
• Datenbankmanipulationen

Solange dieser Mechanismus nicht gefunden wurde, ist die Website nicht wirklich bereinigt.

Unsere praktische Vorgehensweise bei einer gehackten WordPress-Website

Eine hundertprozentig identische Vorgehensweise gibt es nicht, weil jede kompromittierte Installation anders aussieht.

Wir arbeiten bei Austrianweb jedoch grundsätzlich nach einem systematischen Prinzip.

1. Aktuellen Zustand sichern

Bevor Dateien verändert werden, sollte der aktuelle Stand gesichert werden.

Das klingt zunächst widersprüchlich – schließlich enthält das Backup möglicherweise bereits Schadcode.

Für eine spätere Analyse kann genau dieser Zustand aber wertvoll sein.

Außerdem schützt ein Backup davor, bei Bereinigungsarbeiten versehentlich Daten unwiederbringlich zu verlieren.

2. WordPress-Version kontrollieren und aktualisieren

Bei WP2Shell ist dies besonders wichtig.

Betroffene WordPress-Versionen müssen auf eine korrigierte Version aktualisiert werden.

Zum Zeitpunkt dieses Artikels ist WordPress 7.0.2 die aktuelle stabile Sicherheitsversion im 7.0-Zweig. WordPress empfiehlt ausdrücklich ein sofortiges Update.

3. Administratoren kontrollieren

Alle WordPress-Benutzer mit Administratorrechten werden überprüft.

Unbekannte Accounts müssen untersucht und gegebenenfalls entfernt werden.

Dabei sollte allerdings dokumentiert werden:

• Benutzername
• E-Mail-Adresse
• Registrierungsdatum
• Benutzer-ID
• hinterlegte Rollen

Diese Informationen können später wichtige Hinweise auf den Angriff liefern.

4. WordPress-Core kontrollieren

Die vorhandenen Core-Dateien sollten mit einer sauberen WordPress-Version verglichen werden.

Manipulierte oder zusätzliche Dateien müssen untersucht werden.

Eine sehr sichere Vorgehensweise kann darin bestehen, die WordPress-Core-Dateien komplett durch saubere Originaldateien derselben beziehungsweise einer aktuellen Version zu ersetzen.

Dabei dürfen natürlich keine individuellen Inhalte aus wp-content oder der wp-config.php verloren gehen.

5. Plugins kontrollieren

Nicht verwendete Plugins sollten entfernt werden.

Installierte Plugins müssen auf:

• Herkunft
• Aktualität
• bekannte Sicherheitsprobleme
• ungewöhnliche Dateien

überprüft werden.

Bei Zweifeln kann es sinnvoller sein, ein Plugin aus einer vertrauenswürdigen Quelle vollständig neu zu installieren, als einzelne Dateien manuell zu reparieren.

6. MU-Plugins untersuchen

Dieser Punkt wird häufig vergessen.

Gerade auf Managed-WordPress-Systemen liegen dort legitime Dateien des Hosters. Gleichzeitig können sich Angreifer hier hervorragend verstecken.

Deshalb gilt:

Nicht blind löschen – sondern prüfen.

7. Upload-Verzeichnisse überprüfen

Besonders PHP-, JS- und HTML-Dateien innerhalb typischer Medienverzeichnisse verdienen Aufmerksamkeit.

Bei großen Websites kann dieser Bereich tausende oder hunderttausende Dateien enthalten. Automatisierte Scanner sind deshalb hilfreich, ersetzen die manuelle Bewertung auffälliger Funde aber nicht vollständig.

8. Datenbank kontrollieren

Bei einer ernsthaften Kompromittierung sollte nicht nur das Dateisystem untersucht werden.

Zu kontrollieren sind insbesondere:

• Benutzer
• Benutzerrollen
• wp_options
• aktive Plugins
• Cronjobs
• ungewöhnliche URLs
• eingeschleuster HTML- oder JavaScript-Code
• verdächtige Autoload-Einträge

Auch die besten Dateiscanner können eine Manipulation der Datenbank übersehen.

9. Zugangsdaten ändern

Nach einer Kompromittierung sollten unter anderem geändert werden:

• WordPress-Passwörter
• Hosting-Passwort
• FTP-/SFTP-Passwörter
• SSH-Zugänge
• Datenbankpasswort
• gegebenenfalls Cloudflare- oder CDN-Zugänge

Je nach Angriff können weitere Zugangsdaten betroffen sein.

10. WordPress Security Keys / Salts erneuern

WordPress verwendet sogenannte Authentication Keys und Salts.

Werden diese erneuert, verlieren bestehende Login-Sessions ihre Gültigkeit.

Gerade nach einer Kompromittierung ist das sinnvoll, weil ein Angreifer möglicherweise noch eine gültige Sitzung besitzt.

11. Sicherheitsscan durchführen

Nach der manuellen Kontrolle sollte nochmals ein vollständiger Malware-Scan durchgeführt werden.

Geeignete Sicherheitslösungen können dabei helfen, beispielsweise:

• veränderte Core-Dateien
• bekannte Malware
• verdächtige Dateien
• Backdoors
• bekannte Sicherheitslücken

zu erkennen.

Warum ein sauberer Wordfence-Scan noch keine hundertprozentige Entwarnung ist

Wordfence und vergleichbare Security-Lösungen sind ausgesprochen nützliche Werkzeuge.

Ein Scan mit dem Ergebnis „Keine Probleme gefunden“ bedeutet allerdings nicht zwangsläufig:

Diese Website wurde garantiert niemals kompromittiert und enthält garantiert keinerlei Backdoor.

Scanner arbeiten unter anderem mit:

• bekannten Malware-Signaturen
• Datei-Vergleichen
• Heuristiken
• bekannten Schwachstellen
• auffälligen Code-Strukturen

Individuell programmierter oder gut versteckter Schadcode kann unter Umständen unentdeckt bleiben.

Darüber hinaus können Angreifer legitime Dateinamen verwenden oder Veränderungen in der Datenbank vornehmen.

Deshalb ist bei einer nachweislich kompromittierten Website neben automatisierten Scans immer auch eine strukturierte manuelle Untersuchung sinnvoll.

SEO-Spam: Wenn der Hack plötzlich bei Google sichtbar wird

Ein weiteres typisches Symptom kompromittierter Websites ist sogenannter SEO-Spam.

Plötzlich erscheinen bei Google Suchergebnisse wie:

• Viagra kaufen
• Online Casino
• Kryptowährungen
• Kredite
• Fake-Shops
• Medikamente
• Erotikseiten

Obwohl solche Seiten im WordPress-Backend überhaupt nicht existieren.

Das kann verschiedene Ursachen haben.

Angreifer können beispielsweise dynamisch Inhalte für Suchmaschinen erzeugen oder unterschiedliche Inhalte abhängig davon ausliefern, ob Google oder ein normaler Besucher die Website aufruft.

Dieses Verfahren wird häufig als Cloaking bezeichnet.

Das Gefährliche daran:

Der Betreiber sieht beim normalen Aufruf seiner Website möglicherweise überhaupt nichts Ungewöhnliches.

Bei Google sind aber bereits hunderte oder tausende Spam-URLs indexiert.

Eine 404-Seite bedeutet nicht automatisch, dass alles wieder in Ordnung ist

Nach einer Bereinigung erleben Website-Betreiber häufig Folgendes:

Die bei Google angezeigte Spam-URL wird aufgerufen und liefert inzwischen einen Fehler 404.

Das ist zunächst positiv.

Es bedeutet aber lediglich:

Der schädliche Inhalt ist unter dieser URL momentan nicht mehr erreichbar.

Google kann die URL trotzdem noch einige Zeit im Index führen.

Deshalb sollte anschließend auch die Google Search Console überprüft werden.

Interessant sind dort insbesondere:

• indexierte Seiten
• unbekannte URL-Strukturen
• Crawling-Aktivitäten
• ungewöhnliche Suchbegriffe
• Sicherheitsprobleme
• manuelle Maßnahmen

Auch eine Google-Suche mit

site:meine-domain.at

kann einen ersten Eindruck vermitteln.

Was passiert mit Besuchern einer kompromittierten Website?

Ein WordPress-Hack ist nicht ausschließlich ein Problem des Website-Betreibers.

Hat ein Angreifer vollständige Kontrolle über die Website, können auch Besucher gefährdet werden.

Mögliche Folgen sind unter anderem:

• Weiterleitungen
• gefälschte Loginseiten
• Malware-Downloads
• Betrugsseiten
• Datendiebstahl

Damit wird aus einem technischen WordPress-Problem schnell ein erhebliches Reputations- und Sicherheitsproblem für ein Unternehmen.

Browser, Suchmaschinen und Sicherheitsprodukte können eine kompromittierte Website zudem als gefährlich einstufen.

---

Was sollte nach der Bereinigung gemacht werden?

Ist die eigentliche Malware entfernt, beginnt die Absicherung.

WordPress aktuell halten

Sicherheitsupdates sollten insbesondere bei kritischen Core-Schwachstellen möglichst schnell installiert werden.

Plugins und Themes aktuell halten

Nicht mehr benötigte Erweiterungen sollten vollständig entfernt werden.

Zwei-Faktor-Authentifizierung aktivieren

Administratorzugänge sollten möglichst durch 2FA geschützt werden.

Administratorrechte reduzieren

Nicht jeder Benutzer benötigt Administratorrechte.

Starke und einzigartige Passwörter verwenden

Passwörter sollten niemals für mehrere Dienste gleichzeitig verwendet werden.

Regelmäßige Backups einrichten

Backups sollten außerhalb der eigentlichen WordPress-Installation gespeichert werden.

Malware- und Dateiüberwachung verwenden

Veränderungen an wichtigen Dateien sollten möglichst früh erkannt werden.

Login-Versuche überwachen

Massive oder ungewöhnliche Loginversuche können auf einen Angriff hinweisen.

PHP-Ausführung im Upload-Verzeichnis einschränken

Je nach Hosting-Umgebung kann zusätzlich verhindert werden, dass PHP-Dateien innerhalb typischer Upload-Verzeichnisse ausgeführt werden.

Damit wird ein häufig genutzter Angriffsweg erschwert.

Eine solche Einstellung muss allerdings zur jeweiligen Hosting-Konfiguration passen und sollte nicht blind aus irgendeiner Anleitung kopiert werden.

Wann sollte WordPress vollständig neu installiert werden?

Nicht jede kompromittierte Website sollte stunden- oder tagelang manuell repariert werden.

In bestimmten Fällen kann eine saubere Neuinstallation die sicherere Lösung darstellen.

Das gilt insbesondere wenn:

• sehr viele Dateien verändert wurden,
• der Zeitpunkt des Angriffs unbekannt ist,
• keine vertrauenswürdigen Backups vorhanden sind,
• mehrere Backdoors gefunden werden,
• Administratoren immer wieder neu angelegt werden,
• Core-Dateien massiv verändert wurden,
• die Website nach einer Bereinigung erneut kompromittiert wird.

Dann muss wirtschaftlich und technisch entschieden werden:

Ist eine weitere forensische Bereinigung sinnvoll oder ist ein sauberer Neuaufbau zuverlässiger?

Unsere Erfahrungen mit aktuellen WordPress-Angriffen

Die in den vergangenen Tagen von Austrianweb untersuchten WordPress-Installationen haben eines sehr deutlich gezeigt:

Man darf nach dem ersten Malware-Fund nicht aufhören zu suchen.

Wir haben bei kompromittierten Installationen unter anderem verdächtige Dateien in ungewöhnlichen Verzeichnissen, manipulierte beziehungsweise unbekannte Administratoren und Auffälligkeiten bei MU-Plugins untersucht.

In einem Fall war beispielsweise entscheidend, dass ein verdächtiger Benutzer nach dem Löschen erneut in der Datenbank auftauchte.

An diesem Punkt wäre es falsch gewesen, einfach noch einmal auf „Löschen“ zu drücken.

Die richtige Frage lautet:

Welcher Mechanismus erzeugt diesen Benutzer immer wieder?

Genau diese Denkweise ist bei der Bereinigung einer kompromittierten Website entscheidend.

Nicht:

„Wie lösche ich diesen Fund?“

sondern:

„Wie konnte dieser Fund entstehen und gibt es noch einen Zugang, der ihn erneut erzeugen kann?“

Checkliste: Ist meine WordPress-Website möglicherweise gehackt?

Prüfen Sie Ihre Website insbesondere dann genauer, wenn Sie eine oder mehrere dieser Fragen mit „Ja“ beantworten können:

• ☐ Gibt es unbekannte WordPress-Administratoren?
• ☐ Befinden sich ungewöhnliche PHP-Dateien im Upload-Verzeichnis?
• ☐ Existieren unbekannte MU-Plugins?
• ☐ Wurden WordPress-Core-Dateien verändert?
• ☐ Meldet Wordfence verdächtige Dateien?
• ☐ Tauchen gelöschte Benutzer erneut auf?
• ☐ Finden Sie bei Google unbekannte Spam-Seiten Ihrer Domain?
• ☐ Werden Besucher unerwartet weitergeleitet?
• ☐ Gibt es unbekannte Cronjobs?
• ☐ Enthält die Datenbank ungewöhnliche Einträge?
• ☐ Sind plötzlich neue Dateien auf dem Server vorhanden?
• ☐ Ist unklar, wann die Website zuletzt vollständig sauber war?

Je mehr dieser Punkte zutreffen, desto dringender sollte die Installation professionell untersucht werden.

WP2Shell: Aktuelle und neutrale Informationsquellen

Wer sich technisch genauer mit dem aktuellen Sicherheitsproblem beschäftigen möchte, findet hier weiterführende Informationen.

WordPress.org – WordPress 7.0.2 Sicherheitsrelease

Die offizielle Veröffentlichung des WordPress-Projekts mit Informationen zu den behobenen Sicherheitslücken und den betroffenen WordPress-Versionen.

WordPress 7.0.2 Sicherheitsrelease öffnen

WordPress.org – technische Informationen zu WordPress 7.0.2

Enthält unter anderem CVE-Referenzen und Informationen zu den betroffenen Versionszweigen.

WordPress-Dokumentation zu Version 7.0.2

Searchlight Cyber – WP2Shell

Informationen des Sicherheitsteams zur untersuchten Pre-Authentication-RCE-Schwachstelle im WordPress-Core.

Informationen zu WP2Shell öffnen

Malwarebytes – Auswirkungen kompromittierter WP2Shell-Websites

Gut verständliche Einordnung möglicher Gefahren für Besucher kompromittierter WordPress-Websites.

Malwarebytes: WP2Shell und kompromittierte WordPress-Seiten

Fazit: Bei WP2Shell reicht ein WordPress-Update allein nicht immer aus

WP2Shell zeigt eindrucksvoll, warum WordPress-Sicherheit nicht ausschließlich eine Frage sicherer Plugins ist.

Die im Juli 2026 veröffentlichten Schwachstellen befanden sich im WordPress-Core selbst und konnten in Kombination die Ausführung von Code ohne vorherige Anmeldung ermöglichen.

Für noch nicht kompromittierte Websites ist das Update die entscheidende Schutzmaßnahme.

Für bereits angegriffene Websites reicht es dagegen nicht.

Eine kompromittierte WordPress-Installation muss systematisch untersucht werden. Dabei geht es nicht nur darum, sichtbare Malware zu löschen.

Es muss auch geklärt werden:

• Wie ist der Angreifer eingedrungen?
• Welche Veränderungen wurden vorgenommen?
• Gibt es weitere Backdoors?
• Wurden Administratoren angelegt?
• Wurde die Datenbank manipuliert?
• Kann der Angreifer erneut Zugriff erhalten?

Erst wenn diese Fragen beantwortet und die entsprechenden Schwachstellen beseitigt wurden, kann eine WordPress-Installation wieder als vertrauenswürdig betrachtet werden.