Am 17. Juli 2026 hat WordPress ein Notfall-Sicherheitsupdate (Version 7.0.2) veröffentlicht, das eine kritische Schwachstellenkette im WordPress-Core schließt. Betroffen von der WordPress-Sicherheitslücke sind nach ersten Schätzungen einige Millionen Websites, wenn man beachtet, dass weltweit rund 500-Millionen Websites auf WordPress setzen. Unter dem Namen „wp2shell“ erlaubt sie einem nicht-authentifizierten, entfernten Angreifer, beliebigen Code auf dem Server auszuführen (Remote Code Execution, RCE) – ganz ohne Login, ohne Plugin, gegen eine blanke Standardinstallation. Das BSI hat eine Cyber-Sicherheitswarnung herausgegeben, und WordPress.org hat für betroffene Installationen erzwungene automatische Updates aktiviert.
Wir fassen die Fakten kompakt zusammen und werfen einen Blick auf das Thema Risikomanagement im Kontext von Open-Source Software wie WordPress.
Was ist die WordPress Sicherheitslücke wp2shell? Die Fakten in Kürze
Hinter dem griffigen Namen stecken zwei Schwachstellen, die erst in ihrer Kombination gefährlich werden. Entdeckt wurde die Lücke von Adam Kues (Searchlight Cyber).
- Zwei verkettete CVEs: CVE-2026-60137 und CVE-2026-63030 greifen ineinander. Einstiegspunkt ist eine Verwechslung in der REST-API-Batch-Route (/wp-json/batch/v1), die in eine SQL-Injection und von dort in die Codeausführung mündet.
- Ohne Authentifizierung ausnutzbar: Der Angreifer braucht kein Konto und keine Nutzerinteraktion. Genau das macht die Lücke so brisant – sie lässt sich automatisiert und mit KI-Agenten gegen große Mengen von Seiten fahren.
- Riesige Angriffsfläche: WordPress betreibt schätzungsweise deutlich über 500 Millionen Websites weltweit. Die Zahl potenziell betroffener Installationen ist entsprechend groß.
- Aktive Ausnutzung bestätigt: Laut BSI-Warnung (Update vom 20. Juli 2026) wurden am Wochenende Proof-of-Concepts veröffentlicht, die die vollständige Kette ohne Authentifizierung ausnutzen. Es liegen bereits Berichte über erste reale Angriffe vor.
Betroffene Versionen und Fixes
| WordPress-Version | Status | Maßnahme |
|---|---|---|
| 7.0.0 – 7.0.1 | Anfällig (RCE) | Update auf 7.0.2 |
| 6.9.0 – 6.9.4 | Anfällig (RCE) | Update auf 6.9.5 |
| 7.1 beta | Anfällig (RCE) | Update auf 7.1 beta2 |
| 6.8.x | Separate SQL-Injection | Update auf 6.8.6 |
| vor 6.8 | Nicht betroffen | – |
GRC-Betrachtung: Was der Vorfall über Risikomanagement lehrt
Ein Sicherheitsupdate einzuspielen ist Tagesgeschäft der IT. Der eigentliche Wert eines Vorfalls wie wp2shell für Unternehmen liegt woanders: Er ist ein Stresstest für das eigene Risikomanagement. Die entscheidende Frage lautet nicht „Haben wir gepatcht?“, sondern „hätten wir es rechtzeitig gemerkt?“ oder „hätten wir gewusst, welche Systeme überhaupt betroffen sind?“ – aus GRC-Perspektive legt der Fall vier Schwachpunkte offen, die weit über WordPress hinausreichen.
Willkommen bei WordPress 7.0.2 – wer diese Meldung sieht, hat rechtzeitig gehandelt und die Sicherheitslücke geschlossen.
1. Asset-Management: Man kann nur schützen, was man kennt
Die erste Frage nach einer solchen Meldung lautet: Betreiben wir überhaupt WordPress-Websites – und wenn ja – in welcher Version, an welchen Stellen?
Viele Unternehmen können das nicht ad hoc beantworten. Firmen-Blog, Landingpages, Kampagnen-Microsites, das von einer Agentur betreute Portal – digitale Assets wachsen dezentral und geraten aus dem Blick. Ohne ein gepflegtes Asset-Inventar wird jede Schwachstellenmeldung zur hektischen Suche. Die Parallele zum Shadow-AI-Problem ist offensichtlich: Was nicht inventarisiert ist, lässt sich nicht steuern.
2. Patch- und Schwachstellenmanagement als Prozess
Erzwungene Auto-Updates haben hier viele Seiten gerettet – aber sich darauf zu verlassen, ist keine Strategie, sondern Glück. Auto-Updates sind bei stark angepassten Installationen oft deaktiviert, aus Sorge vor Kompatibilitätsproblemen. Ein belastbares Patch-Management definiert im Vorfeld: Wer beobachtet Sicherheitsquellen wie die BSI-Warnungen? Innerhalb welcher Frist werden kritische Lücken eingespielt? Wer verifiziert den Erfolg? Ohne dokumentierten Prozess bleibt Reaktionsfähigkeit dem Zufall überlassen.
3. Meldepflichten: Wenn aus dem IT-Vorfall ein Rechtsthema wird
Hier wird die reine Technik zur Chefsache. Eine erfolgreiche RCE bedeutet, dass ein Angreifer den Server kontrolliert – und damit potenziell auf personenbezogene Daten zugreifen kann. Daraus können konkrete Pflichten entstehen:
- DSGVO-Meldepflicht (Art. 33): Bei einer Verletzung des Schutzes personenbezogener Daten ist die Aufsichtsbehörde in der Regel binnen 72 Stunden zu informieren. Die Uhr läuft ab Kenntnis – nicht ab Behebung.
- Benachrichtigung Betroffener (Art. 34): Bei hohem Risiko für die Betroffenen kommt deren direkte Information hinzu.
- NIS-2-Meldepflichten: Für Unternehmen im Anwendungsbereich der NIS-2-Richtlinie gelten zusätzliche, teils noch kürzere Meldefristen an das BSI.
Wer diese Pflichten erst im Schadensfall zum ersten Mal liest, verliert wertvolle Stunden. Ein vorbereiteter Incident-Response-Plan mit klaren Rollen und Eskalationswegen ist der Unterschied zwischen geordneter Reaktion und Chaos.
4. Lieferkette und Verantwortung: „Die Agentur macht das“ reicht nicht
Viele KMU lassen ihre Website von einer Agentur oder einem Freelancer betreuen. Das verlagert die technische Umsetzung – nicht aber die Verantwortung. Datenschutzrechtlich bleibt das Unternehmen der Verantwortliche. Ob der Dienstleister zeitnah patcht, ob es einen Auftragsverarbeitungsvertrag mit klaren Sicherheitspflichten oder gar einen Wartungsvertrag mit klar definierten Wartungsroutinen gibt oder ob im Ernstfall eine Meldekette funktioniert – das sind Fragen des Third-Party-Risk-Managements, die vor dem Vorfall geklärt sein müssen.
Eines ist garantiert: in Zeiten von KI-Agenten und autonom ausnutzbaren Sicherheitslücken wird uns das Thema in Zukunft noch dramatisch oft beschäftigen!
Handlungsempfehlung: Checkliste zum Vorfall
Kompakt zum Abhaken – so gehen Sie strukturiert mit wp2shell und ähnlichen Vorfällen um:
- Version prüfen: im Dashboard die installierte WordPress-Version verifizieren (Ziel: 7.0.2, 6.9.5 oder 6.8.6)
- Sofort patchen bzw. Auto-Update-Erfolg bestätigen, nicht nur annehmen
- Überbrückung, falls kein sofortiges Update möglich: REST-Batch-Route per WAF sperren
- Kompromittierung prüfen: Logs, neue Admin-Accounts, unbekannte Dateien und Cronjobs kontrollieren
- Asset-Inventar abgleichen: Welche weiteren WordPress-Instanzen (Microsites, Agentur-Projekte) betreiben wir?
- Dienstleister kontaktieren und Patch-Status der betreuten Seiten schriftlich bestätigen lassen
- Meldepflichten prüfen: bei Verdacht auf Datenabfluss DSGVO (Art. 33/34) und ggf. NIS-2 bewerten
- Patch-Prozess etablieren oder nachschärfen: Quellen, Fristen, Verantwortliche, Verifikation
- Incident-Response-Plan auf Aktualität prüfen (Rollen, Eskalation, Meldeketten)
Wie Elsen GRC Sie unterstützt
Ein einzelner Patch ist schnell eingespielt – ein belastbares Risikomanagement wächst nicht über Nacht. Elsen GRC hilft KMU, aus reaktivem Feuerlöschen einen gesteuerten Prozess zu machen, der in Zukunft seriöse und nachvollziehbare Reaktionen bei IT-Sicherheitsvorfällen ermöglicht.
- GRC- & Governance-Beratung: Aufbau von Asset-Inventar, Patch- und Schwachstellenmanagement sowie Incident-Response-Prozessen.
- Privacy QuickCheck: Schnelle Standortbestimmung zu Datenschutz, Meldepflichten und technisch-organisatorischen Maßnahmen (TOM).
- NIS-2- & DSGVO-Begleitung: Klärung Ihrer konkreten Meldepflichten und Aufbau der nötigen Nachweisdokumentation.
Häufige Fragen zu wp2shell (FAQ)
Bin ich betroffen, wenn ich nur einen kleinen Firmen-Blog betreibe?
Ja, potenziell. Die Lücke betrifft den WordPress-Kern selbst, unabhängig von Größe oder Plugins. Jede Installation in einer der betroffenen Versionen ist angreifbar – gerade automatisierte Angriffe machen keinen Unterschied zwischen groß und klein.
Reicht es, wenn Auto-Updates aktiviert sind?
In den meisten Fällen ja – aber verlassen sollten Sie sich nicht blind darauf. Prüfen Sie die tatsächlich installierte Version im Dashboard. Bei stark angepassten Installationen sind Auto-Updates häufig deaktiviert.
Muss ich den Vorfall den Behörden melden?
Das hängt davon ab, ob personenbezogene Daten betroffen sein könnten. Besteht dieser Verdacht, greift die DSGVO-Meldepflicht (Art. 33, in der Regel binnen 72 Stunden). Unternehmen im NIS-2-Anwendungsbereich haben zusätzliche Pflichten. Im Zweifel frühzeitig fachkundig bewerten lassen.
Meine Website wird von einer Agentur betreut – bin ich dann aus dem Schneider?
Technisch liegt die Umsetzung beim Dienstleister, die datenschutzrechtliche Verantwortung bleibt aber bei Ihnen. Lassen Sie sich den Patch-Status bestätigen und prüfen Sie, ob ein Auftragsverarbeitungsvertrag oder ein Wartungsvertrag mit klaren Sicherheits- und Meldepflichten besteht.
Falls Sie technische Unterstützung mit Ihrer WordPress-Website benötigen, können Sie unsere Webagentur Elsen Media kontaktieren.
Verwandte Themen
- NIS-2: Definition, Pflichten & Betroffenheit
- Shadow AI: Definition, Risiken & Maßnahmen
- Auftragsverarbeitungsvertrag (AVV): Definition & Pflichten
Quellen & Bild
- BSI: WordPress – Schwachstellen erlauben Remote Code Execution (Warnung, Stand 20.07.2026)
- WordPress.org: 7.0.2 Security Release
- Aikido Security: Unauthenticated RCE in WordPress core (wp2shell)
- heise online: wp2shell – Kritische WordPress-Lücke erlaubt Codeeinschleusung über API
Bild: Foto von Dima Pechurin auf Unsplash
