WP2Shell: 15.938 Websites in Österreich, 13.185 in der Schweiz auf den betroffenen WordPress-Zweigen

risikomonitor.com · Analyse · 14. September 2026 · Manuel Löw-Beer, MBA MPA · risikomonitor.com GmbH, Wien

Am Freitag, dem 17. Juli 2026, veröffentlichte das WordPress-Projekt Notfall-Updates für eine Schwachstellenkette im WordPress-Kern, die unter dem Namen WP2Shell bekannt wurde. Zwei Fehler – CVE-2026-63030 und CVE-2026-60137 – ergeben zusammen eine Codeausführung aus der Ferne ohne jede Anmeldung: Eine einzige anonyme Anfrage an eine Standardinstallation ohne Plugins genügt, um Website und Server zu übernehmen. Gefunden wurde die Kette von Searchlight Cyber mit Unterstützung eines KI-Modells in rund zehn Stunden. Bereits in der Nacht auf Samstag lief die Ausnutzung, am 21. Juli nahm die US-Behörde CISA beide Lücken in ihren Katalog aktiv ausgenutzter Schwachstellen auf, und allein ein großer Hoster registrierte in der ersten Woche mehr als 45 Millionen Angriffsversuche.

risikomonitor.com hat daraufhin alle als WordPress identifizierten Websites im österreichischen und im Schweizer Domainbestand passiv vermessen: 220.413 Websites in Österreich, 242.969 in der Schweiz. Das Ergebnis in einem Satz: In Österreich laufen 56,5 % der Websites mit erkennbarer Version auf dem aktuellen Zweig 7.1, in der Schweiz 62,4 % – und auf den von WP2Shell betroffenen Zweigen 6.9 und 7.0 liegen 15.938 österreichische und 13.185 Schweizer Websites.

WP2Shell auf einen Blick

1. Was ist WP2Shell?

WordPress besteht aus drei Schichten: dem Kern, den das WordPress-Projekt pflegt, sowie Plugins und Themes von Dritten. Historisch lag die überwältigende Mehrheit der Schwachstellen in Plugins. Genau das macht WP2Shell besonders: Die Lücke sitzt vollständig im Kern und ist gegen eine unveränderte Standardinstallation ausnutzbar. Wordfence bezeichnete sie als erste kritische, ohne Anmeldung ausnutzbare Codeausführung im WordPress-Kern seit fast zehn Jahren.

CVE-2026-63030 betrifft den Batch-Endpunkt der REST-API (/wp-json/batch/v1 und gleichwertig ?rest_route=/batch/v1). Prüfung und Ausführung der gebündelten Anfragen erfolgen in getrennten Schleifen, die über parallel geführte, nach Position indizierte Listen verknüpft sind. Scheitert die Verarbeitung eines Elements, erhält die Prüfliste einen Eintrag, die Zuordnungsliste aber keinen Platzhalter – die Positionen verschieben sich, und eine Anfrage wird mit der Berechtigungsprüfung einer anderen ausgeführt. CVE-2026-60137 ist eine SQL-Injection im Abfrageobjekt WP_Query: Der Parameter author__not_in erwartet eine Liste von IDs; wird eine Zeichenkette übergeben, entfällt die Typprüfung und der Rohwert gelangt ungefiltert in die Datenbankabfrage.

Verkettet ergibt sich: Die Routenverwechslung öffnet anonymen Anfragen den Weg zur SQL-Injection, diese liest Passwort-Hashes aus oder legt ein neues Administratorkonto an, und über ein präpariertes Plugin wird beliebiger Code ausgeführt. Nach Beobachtungen von Bitdefender vergehen zwischen Beginn der Ausnutzung und Administratorzugang rund zwei Minuten. Laut Cloudflare ist der verwundbare Codepfad nur erreichbar, wenn kein persistenter Objekt-Cache aktiv ist; dieselbe Version kann daher auf einem Server ausnutzbar sein und auf einem anderen nicht.

2. Chronologie

Der Ablauf zeigt, wie stark sich das Zeitfenster zwischen Veröffentlichung und Massenausnutzung verkürzt hat. Die Notfall-Updates erschienen an einem Freitagnachmittag US-Zeit – wer Updates nicht automatisch einspielt, hatte faktisch ein Wochenende gegen weltweite Scanner zu überstehen.

• 15.04.2025: WordPress 6.8 erscheint, die SQL-Injection ist ab diesem Zweig enthalten
• 02.12.2025: WordPress 6.9 erscheint, mit der Routenverwechslung entsteht die ausnutzbare Kette
• 20.05.2026: WordPress 7.0 erscheint
• 17.07.2026: Notfall-Releases 7.0.2, 6.9.5, 6.8.6; erzwungene Auslieferung über das Auto-Update-System
• 18.07.2026: In den frühen Morgenstunden läuft die Ausnutzung, öffentliche Exploits kursieren auf GitHub
• 20.07.2026: CERT.at warnt, das deutsche BSI stuft die Lage mit Stufe 3 (Orange) von 4 ein
• 21.07.2026: CISA nimmt beide CVEs in den KEV-Katalog auf
• 22.07.2026: Searchlight Cyber veröffentlicht die vollständigen technischen Details
• bis 24.07.2026: über 45 Mio. Ausnutzungsversuche aus fast 150.000 Netzwerkquellen
• 19.08.2026: WordPress 7.1 erscheint
• 11.09.2026: Meldepflichten des Cyber Resilience Act treten in Kraft
• 01.10.2026: NISG 2026 tritt in Österreich in Kraft

3. Wer hat die Lücke gefunden – und wer nutzt sie aus?

Die Routenverwechslung fand Adam Kues, Sicherheitsforscher bei Assetnote, der Attack-Surface-Management-Einheit von Searchlight Cyber, und meldete sie über das HackerOne-Programm von WordPress. Bemerkenswert ist der Weg dorthin: Die Kette samt Exploit wurde KI-gestützt in rund zehn Stunden entwickelt. Searchlight Cyber hielt die Details zunächst zurück – es half wenig: Andere Forscher analysierten den Patch und stellten binnen Stunden lauffähige Exploits online.

Die Angreifer sind bislang keinem bekannten Akteur zugeordnet; die Kampagnen gelten als opportunistisch und branchenübergreifend. Wiz Research beobachtete zweckgebaute Werkzeuge, erkennbar an Kennungen wie „wp2shell" und „rezwp2shell" im User-Agent. Die eigentliche Lehre betrifft die Geschwindigkeit: Patchstack misst für stark ausgenutzte WordPress-Schwachstellen eine gewichtete Medianzeit von fünf Stunden zwischen Veröffentlichung und erster Ausnutzung. Wenn KI die Suche nach Lücken und die Umwandlung von Patches in Exploits gleichermaßen beschleunigt, wird ein Wartungszyklus von einer Woche zum strukturellen Risiko.

4. Das Ausmaß – und eine notwendige Einordnung

Nach W3Techs lief WordPress im Sommer 2026 auf rund 41 % aller Websites und auf rund 59 % aller Websites mit erkennbarem CMS. Diese Gesamtzahl ist aber nicht die verwundbare Menge: Betroffen waren nur Installationen der Zweige 6.9 und 7.0. Wiz Research stellte fest, dass bei Veröffentlichung 60 % der Organisationen mit WordPress mindestens eine verwundbare Instanz betrieben und 25 % eine davon direkt aus dem Internet erreichbar hatten.

45 Millionen Angriffe sind nicht 45 Millionen Opfer. Die häufig zitierte Zahl bezieht sich auf Ausnutzungsversuche in der ersten Woche, gemessen auf der Infrastruktur eines einzelnen Hosters. Sie beschreibt den Angriffsdruck, nicht die Zahl kompromittierter Websites. Eine belastbare weltweite Opferzahl existiert bislang nicht.

Die erzwungenen Updates haben vermutlich sehr viele Websites gerettet. Sie erreichen aber keine Installationen, bei denen automatische Updates deaktiviert, blockiert oder technisch gescheitert sind, und sie heilen keine Kompromittierung, die vor dem Update erfolgt ist. Ein Hoster dokumentierte zwei binnen zwei Stunden kompromittierte Websites, von denen eine sechs Tage nach der Bereinigung erneut infiziert war, weil die Angreifer mehrere Persistenzebenen angelegt hatten.

5. Update-Management in Österreich und der Schweiz

Grundlage der folgenden Zahlen ist eine Vollerhebung von risikomonitor.com im September 2026 über eigene IP-Infrastruktur. Erhoben wurde ausschließlich, ob eine Website erreichbar ist und ob sie ihre WordPress-Version über das meta-generator-Tag oder den RSS-Feed preisgibt. Es wurden keine Schwachstellen getestet oder ausgenutzt.

Bemerkenswert ist der Unterschied bei der Versionspreisgabe über den RSS-Feed: 15,4 % der österreichischen, aber nur 6,0 % der Schweizer WordPress-Websites verraten dort ihre exakte Version. Das ist ein klassisches Härtungsdefizit. Umgekehrt gilt: Eine verborgene Version ist keine Sicherheitsmaßnahme – bei WP2Shell wurde wahllos gescannt.

Auf den ersten Blick funktioniert die automatische Aktualisierung: Wenige Wochen nach Erscheinen von 7.1 am 19. August läuft bereits die Mehrheit auf dem neuen Zweig, die Schweiz mit 62,4 % um 5,9 Prozentpunkte vor Österreich mit 56,5 %. Nicht auf dem aktuellen Zweig befinden sich in Österreich 37.625 Websites (43,5 %), in der Schweiz 29.475 (37,6 %).

Wichtig für eine seriöse Darstellung: „Nicht auf 7.1" bedeutet nicht „verwundbar". Relevant sind nur die Zweige 6.9 und 7.0, und dort nur Versionen unterhalb von 6.9.5 bzw. 7.0.2. Auf diesen beiden Zweigen liegen in Österreich 15.938 Websites (18,4 % der Websites mit Versionswert), in der Schweiz 13.185 (16,8 %). Diese Zahl ist eine Obergrenze; die Auswertung auf Patch-Ebene ist der nächste Schritt dieser Erhebung.

Das größere strukturelle Problem liegt am unteren Ende. In Österreich laufen 17.102 Websites (19,8 %) auf Zweig 6.7 oder älter, in der Schweiz 12.660 (16,2 %). Diese Installationen sind von WP2Shell nicht betroffen, weil die fehlerhaften Codeteile dort noch nicht existierten – sie erhalten aber offiziell keine Sicherheitsunterstützung mehr, und ihre Plugins sind in aller Regel ebenso veraltet. 902 österreichische Websites laufen auf der Hauptversion 4.9 aus dem Jahr 2017. Wer hier WP2Shell entgangen ist, verdankt das nicht seinem Update-Management, sondern dessen Fehlen.

6. WordPress als Ökosystem: die Schwachstellenlage

7. Verbreitete Plugins und ihre Referenzschwachstellen

Von den zehn 2025 am häufigsten angegriffenen Schwachstellen wurden nur vier im selben Jahr veröffentlicht; die übrigen stammen aus 2023 und 2024. Angreifer suchen gezielt nach veralteten Versionen. Alle genannten Lücken sind längst behoben.

Das Muster ist eindeutig: Die gefährlichsten Lücken betreffen Datei-Uploads, Rechteausweitung und Authentifizierung – genau jene Funktionen, über die Angreifer dauerhaften Zugang erlangen. Patchstack beobachtete zudem, dass kommerzielle Premium-Komponenten dreimal so viele aktiv ausgenutzte Schwachstellen aufwiesen wie freie, weil sie seltener unabhängig geprüft werden.

8. Was mit erbeuteten Daten geschieht

Eine Codeausführung auf dem Webserver ist mehr als ein Defacement. Wer den Server kontrolliert, hat Zugriff auf die gesamte Datenbank, das Upload-Verzeichnis und die Konfiguration mit allen Zugangsdaten.

Die Verwertung folgt einer arbeitsteiligen Untergrundökonomie. Die Mitte 2026 aufgedeckte Operation WP-SHELLSTORM zeigt das Geschäftsmodell: Eine Gruppe scannte über 1,4 Mio. Domains, nutzte 27 Schwachstellen vor allem in Plugins aus, betrieb Tausende Webshells und verkaufte den Zugang weiter. Besonders heikel sind Ausweiskopien: Anders als ein Passwort lässt sich eine Passnummer nicht zurücksetzen.

9. Datenschutzrechtliche Bewertung

Bei einer erfolgreichen WP2Shell-Ausnutzung hat der Angreifer Administratorrechte und Codeausführung erlangt. Damit liegt ein unbefugter Zugang zu allen gespeicherten Daten vor, auch wenn ein Abfluss nicht nachgewiesen ist (Art. 4 Nr. 12 DSGVO). Die Meldung an die Datenschutzbehörde ist binnen 72 Stunden ab Kenntnis zu erstatten (Art. 33 DSGVO); bei hohem Risiko – Ausweiskopien, Gesundheits- oder Finanzdaten – sind zusätzlich die Betroffenen zu benachrichtigen (Art. 34 DSGVO). Jede Verletzung ist intern zu dokumentieren, Agenturen und Hoster als Auftragsverarbeiter müssen den Verantwortlichen unverzüglich informieren.

Art. 32 DSGVO verlangt Maßnahmen nach dem Stand der Technik. Dieser ist bei WP2Shell unmissverständlich dokumentiert: Fix verfügbar, erzwungene Auslieferung, Warnungen von CERT.at und BSI, CISA-KEV-Eintrag. Eine Installation, die Wochen danach noch auf 7.0.1 läuft, lässt sich kaum als angemessen geschützt darstellen. Der EuGH hat in C-340/21 klargestellt, dass ein erfolgreicher Angriff nicht automatisch unzureichende Maßnahmen beweist – die Beweislast für die Angemessenheit trägt aber der Verantwortliche. Verstöße gegen Art. 32 DSGVO können mit bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes geahndet werden.

Schweiz: Das revidierte DSG verpflichtet zu risikoangemessener Datensicherheit (Art. 8 DSG). Verletzungen mit voraussichtlich hohem Risiko sind dem EDÖB so rasch als möglich zu melden (Art. 24 DSG). Anders als die DSGVO richtet das DSG seine Strafbestimmungen an natürliche Personen: Wer vorsätzlich Mindestanforderungen an die Datensicherheit missachtet, kann mit Busse bis zu 250.000 Franken bestraft werden (Art. 61 lit. c DSG).

10. Haftung: Betreiber, Agentur, Geschäftsleitung

Sobald eine Lücke öffentlich bekannt, aktiv ausgenutzt und ein Fix verfügbar ist, wird das Nicht-Einspielen zur Sorgfaltsfrage.

Betroffene gegen Betreiber: Wer durch einen DSGVO-Verstoß einen materiellen oder immateriellen Schaden erleidet, hat Anspruch auf Schadenersatz (Art. 82 DSGVO). Nach EuGH C-300/21 gibt es keine Erheblichkeitsschwelle, der Schaden muss aber nachgewiesen werden; nach C-340/21 kann bereits die begründete Befürchtung eines Datenmissbrauchs einen immateriellen Schaden darstellen.

Betreiber gegen Agentur und Hoster: Umfasst ein Wartungsvertrag die Aktualisierung von Kern und Plugins, ist das Einspielen eines kritischen Sicherheitsupdates Hauptleistungspflicht. Fachleute haften nach dem objektiven Sorgfaltsmaßstab ihres Fachs (§ 1299 ABGB) und für Subunternehmer wie für eigenes Verhalten (§ 1313a ABGB). Ohne Wartungsvertrag bleibt die Update-Verantwortung grundsätzlich beim Betreiber.

Geschäftsleitung und Versicherung: Geschäftsführer haften der Gesellschaft nach § 25 GmbHG, Vorstände nach § 84 AktG. Die Business Judgment Rule schützt informierte unternehmerische Entscheidungen, nicht aber das Ignorieren einer bekannten kritischen Warnung. Cyber-Versicherungen enthalten regelmäßig Obliegenheiten zum zeitnahen Einspielen von Sicherheitsupdates; ihre Verletzung kann zur Leistungsfreiheit führen. In der Schweiz gilt Art. 97 OR mit vermutetem Verschulden, Art. 398 OR für Beauftragte und Art. 754 OR für Verwaltungsräte; ein Ausschluss der Haftung für grobe Fahrlässigkeit ist nichtig (Art. 100 Abs. 1 OR).

11. NISG 2026, DORA und Cyber Resilience Act

Das NISG 2026 (BGBl. I Nr. 94/2025) setzt NIS2 in Österreich um und tritt am 1. Oktober 2026 in Kraft. Erfasst sind rund 4.000 Einrichtungen aus 18 Sektoren; die Registrierung muss bis 31. Dezember 2026 erfolgen, eine Übergangsfrist für die materiellen Pflichten gibt es nicht. Vier Punkte sind für WP2Shell-artige Ereignisse maßgeblich: Risikomanagement einschließlich Umgang mit Schwachstellen (§ 32), Sicherheit der Lieferkette – da die meisten Websites von Agenturen betreut werden, sind deren Patch-Prozesse Teil des eigenen Risikomanagements –, gestaffelte Meldepflichten von 24 Stunden, 72 Stunden und einem Monat (§ 34) sowie die Billigungs- und Überwachungspflicht der Leitungsorgane (§ 31). Die Geldbußen reichen bis 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes. In der Schweiz gilt seit 1. April 2025 die 24-Stunden-Meldepflicht an das BACS für Betreiberinnen kritischer Infrastrukturen, Sanktionen sind seit 1. Oktober 2025 möglich.

Für Banken, Versicherungen, Wertpapier-, Zahlungs- und Kryptodienstleister gilt seit 17. Jänner 2025 DORA. Webagenturen und Hoster, die Websites, Antragsstrecken oder Kundenportale betreiben, sind IKT-Drittdienstleister: Sie gehören ins Informationsregister, ihre Verträge müssen Sicherheitsanforderungen, Meldepflichten, Prüfrechte und Ausstiegsstrategien enthalten. Ein Finanzunternehmen, das nicht belegen kann, wann sein Dienstleister WP2Shell geschlossen hat, hat eine Lücke im Drittparteienmanagement.

Mit dem heutigen 11. September 2026 treten die Meldepflichten des Cyber Resilience Act in Kraft: Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen über die Single Reporting Platform der ENISA melden – Frühwarnung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur. Kommerzielle Plugin- und Theme-Anbieter mit Kunden in der EU gelten als Hersteller.

12. Prüfkatalog für Webagenturen und Hoster

13. Sofortmaßnahmen

1. Exakte Version prüfen – im Dashboard oder per Kommandozeile (wp core version), auf jeder einzelnen Instanz. Nicht darauf vertrauen, dass das erzwungene Update angekommen ist. 2. Kompromittierung ausschließen ab 17. Juli 2026: neue Administratorkonten, unbekannte Plugins einschließlich Must-Use-Plugins, PHP-Dateien im Upload-Verzeichnis, veränderte Kerndateien (wp core verify-checksums). In den Zugriffsprotokollen nach Anfragen auf /wp-json/batch/v1 und ?rest_route=/batch/v1, auffälligen HTTP-207-Antworten und den Kennungen „wp2shell" und „rezwp2shell" suchen. 3. Bei Befund neu aufsetzen statt bereinigen: Wiederherstellung aus einem sauberen Backup vor dem 17. Juli, alle Passwörter zurücksetzen, Salts und Datenbankpasswort erneuern, API-Schlüssel widerrufen. 4. Datenschutzrechtlich bewerten und dokumentieren: 72-Stunden-Frist nach Art. 33 DSGVO prüfen, Benachrichtigung nach Art. 34 DSGVO erwägen. 5. Als Überbrückung den Batch-Endpunkt für anonyme Zugriffe an der Web Application Firewall sperren, wenn ein Update kurzfristig nicht möglich ist. Das ersetzt das Update nicht.

Mittelfristig braucht jede Organisation ein vollständiges Inventar ihrer Websites, verbindliche Patch-Fristen in Stunden statt Wochen, automatisierte Sicherheitsupdates, laufende Überwachung auf Kompromittierungsindikatoren und Lieferantenverträge nach dem Prüfkatalog. Websites auf Zweig 6.7 oder älter sind nicht nachzurüsten, sondern zu migrieren oder stillzulegen. Wer nicht weiß, welche Websites unter seiner Marke laufen, kann sie auch nicht patchen.

Methodik und Grenzen

Grundgesamtheit sind alle Websites im österreichischen und im Schweizer Domainbestand, die als WordPress-Installation identifiziert wurden. Die Erhebung erfolgte als Vollerhebung über eigene IP-Infrastruktur im September 2026. Abgerufen wurden ausschließlich öffentlich zugängliche Inhalte, nämlich Startseite und RSS-Feed; die Versionskennung stammt aus dem meta-generator-Tag bzw. dem generator-Eintrag des Feeds. Es wurden keine Schwachstellen aktiv getestet. Grenzen: Versionsangaben können durch Caching veraltet sein; Websites mit verborgener Version (26,4 % in Österreich, 27,6 % in der Schweiz) und unerreichbare Websites sind nicht bewertet; die Darstellung erfolgt auf Ebene der Hauptzweige, die Aufschlüsselung nach Patch-Ständen folgt.

Sie wissen nicht, wie viele WordPress-Instanzen unter Ihrer Marke und bei Ihren Dienstleistern laufen? risikomonitor.com inventarisiert Ihre Domains, prüft Versionsstände, Erreichbarkeit und Härtung und überwacht Ihre Lieferanten laufend – rechtzeitig vor dem NISG 2026. [Jetzt Kontakt aufnehmen](/kontakt)

Quellen

• WordPress.org – WordPress 7.0.2 Security Release
• CERT.at – Warnung zu CVE-2026-60137 und CVE-2026-63030
• The Hacker News – New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code
• Picus Security – CVE-2026-63030 and CVE-2026-60137 (wp2shell): WordPress RCE Explained
• Dark Reading – WP2Shell Opens Millions of WordPress Sites to Remote Takeover
• Jones Day – EU Cyber Resilience Act: 24-Hour Reporting Duties Start September 11, 2026
• Patchstack – State of WordPress Security in 2026
• risikomonitor.com – Vollerhebung WordPress Österreich und Schweiz, September 2026