Das Wichtigste in Kürze
- Im Juli wurde eine kritische Sicherheitslücke im Kern von WordPress geschlossen – betroffen war jede Standard-Installation, unabhängig von Plugins, Passwörtern oder Wartungszustand.
- Angriffe begannen innerhalb von Stunden nach Veröffentlichung des Updates. Betroffen sind die Versionen 6.8 bis 7.0.1.
- Ein Update schliesst die Lücke – entfernt aber keinen Schadcode, der vorher platziert wurde.
- Prüfen Sie Ihre Version und achten Sie auf unbekannte Administrator-Konten. Kostenlose Prüfwerkzeuge finden Sie weiter unten im Beitrag.
Was passiert ist
Im Juli entdeckten Sicherheitsexperten eine kritische Schwachstelle im Kern von WordPress – die erste ihrer Art seit fast einem Jahrzehnt. Sie meldeten den Fund vertraulich an das WordPress-Sicherheitsteam, das umgehend Notfall-Updates bereitstellte.
Das Besondere an dieser Lücke: Es brauchte kein unsicheres Passwort, kein veraltetes Plugin und keinen Bedienfehler. Betroffen war jede Standard-Installation, die online erreichbar war. Ein einziger anonymer Aufruf genügte, um Schadcode auf dem Server auszuführen – ohne Login, ohne Zugangsdaten. Wer alles richtig gemacht hatte, war genauso betroffen wie alle anderen.
Mit der Veröffentlichung des Updates wurde die Lücke zwangsläufig öffentlich bekannt – das ist bei Sicherheitsupdates unvermeidbar. Angreifer analysierten den Patch, rekonstruierten daraus die Schwachstelle und begannen innerhalb weniger Stunden mit automatisierten Angriffen. WordPress.org hielt die Lage für so ernst, dass erstmals automatische Zwangs-Updates ausgelöst wurden.
Zwischen «Update verfügbar» und «Websites werden angegriffen» lag also weniger Zeit, als die meisten Unternehmen brauchen, um überhaupt zu bemerken, dass es ein Update gibt. Genau hier liegt der Kern des Problems – und der Grund für diesen Beitrag.
Welche Versionen betroffen sind
Version | Betroffen? | Update auf |
|---|---|---|
7.0.0 – 7.0.1 | Vollständige Angriffskette (kritisch) | 7.0.2 |
6.9.0 – 6.9.4 | Vollständige Angriffskette (kritisch) | 6.9.5 |
6.8.0 – 6.8.5 | Nur SQL-Injection (weniger kritisch) | 6.8.6 |
Älter als 6.8 | Von dieser Lücke nicht betroffen | trotzdem aktualisieren |
Offizielle WordPress-Release-Ankündigung: https://wordpress.org/news/2026/07/wordpress-7-0-2-release/
Ihre Version finden Sie im WordPress-Backend unter Dashboard → Aktualisierungen.
Ein wichtiger Hinweis: Prüfen Sie jede Installation einzeln – auch Testumgebungen, Entwicklungs-Subdomains und vergessene Nebenprojekte. Dass eine Website erfolgreich aktualisiert wurde, sagt nichts über die anderen aus. Und die automatischen Zwangs-Updates greifen nicht überall zuverlässig.
Kurz eingeordnet: Liegt das an WordPress?
Diese Frage kommt erfahrungsgemäss sofort – deshalb vorweg: Nein.
Kritische Sicherheitslücken gibt es in jeder Software. Bei geschlossenen Systemen, bei Cloud-Diensten, bei grossen Anbietern mit eigenen Sicherheitsteams. Der Unterschied ist, dass Sie dort meist gar nicht erfahren, dass es sie gab – gepatcht wird im Hintergrund, kommuniziert wird nicht unbedingt.
WordPress macht das Gegenteil: Die Lücke wurde von unabhängigen Fachleuten gefunden, verantwortungsvoll gemeldet, transparent dokumentiert und innerhalb von Stunden durch ein weltweites Entwicklerteam geschlossen. Genau das ist die Stärke einer grossen Open-Source-Community. Tausende Augen schauen auf denselben Code, und im Ernstfall arbeitet ein globales Netzwerk an der Lösung statt einer einzelnen Firma. Das wirkt kurzfristig beunruhigender, ist aber ehrlicher und im Ergebnis schneller.
Die schlechten WordPress-Erfahrungen, von denen manche berichten, stammen in der Regel nicht aus dem System selbst. Sie stammen aus überladenen Plugin-Installationen ohne Konzept, Eigenbau-Bastel-Lösungen, fehlender Wartung und dem Umstand, dass sich nach dem Launch niemand mehr zuständig fühlt.
Auch wir waren betroffen – und woran Sie erkennen können, ob auch Sie es sind
An dieser Stelle könnte ich schreiben, dass bei uns alles glattlief. Das wäre nicht ehrlich.
Auch eines der von uns betreuten Projekte wurde in diesem Zeitfenster kompromittiert – trotz Wartungsvertrag, trotz Monitoring, trotz Sicherheitssoftware. Bei einer Lücke, die keinen Login benötigt, gibt es keine Prävention, die zuverlässig greift. In der Fachwelt wird es so zusammengefasst: Die einzige wirksame Variable war, ob die Installation gepatcht war oder nicht.
Auffällig ist, was die Angreifer nicht getan haben: Es gab keinen sichtbaren Schaden, keine veränderten Inhalte, keine Fehlermeldungen. Stattdessen wurden systematisch Zugänge eingerichtet – Administrator-Konten, ein getarntes Plugin, abgeschaltete Sicherheitssoftware. Das entspricht dem typischen Muster automatisierter Massenangriffe: Erst wird der Zugang gesichert, verwertet wird später. Genau deshalb merken viele Betroffene zunächst nichts. Die Website funktioniert normal – während im Hintergrund die Tür offensteht.
Wichtiger als unsere Geschichte ist, woran Sie einen Einbruch erkennen. Denn ein Update schliesst zwar die Lücke – es entfernt aber keinen Schadcode, der vorher schon platziert wurde.
Unbekannte Administrator-Konten. Das deutlichste Zeichen. Angreifer legen automatisiert Konten mit generischen Namen an – zufällige Zeichenfolgen, oft mit Fantasie-E-Mail-Adressen. Prüfen Sie unter Benutzer, ob dort Konten stehen, die Sie nicht kennen.
Deaktivierte Sicherheitssoftware. Wenn Ihr Security-Plugin plötzlich «wegen eines Fehlers» abgeschaltet ist, ist das selten ein Fehler.
Unbekannte oder doppelte Plugins. Besonders solche mit harmlos klingenden technischen Namen, die Sie nie installiert haben.
Dateien, die dort nicht hingehören. PHP-Dateien im Upload-Verzeichnis sind ein klassisches Versteck für Hintertüren – dort gehören ausschliesslich Bilder und Dokumente hin.
Eine Besonderheit dieses Angriffs erschwert die Suche: Die entscheidenden Schritte laufen über Anfragen, die in den Server-Protokollen kaum Spuren hinterlassen. Die Beweise liegen deshalb primär in der Datenbank und im Dateisystem, nicht in den Logs. Wer nur die Zugriffsprotokolle prüft, übersieht den Einbruch möglicherweise.
Wenn Sie eines dieser Zeichen finden: Konten nicht einfach löschen und weitermachen. Ein Einbruch dieser Art hinterlässt in der Regel weitere Hintertüren. Hier braucht es eine saubere Analyse und – im Zweifel – eine vollständige Wiederherstellung auf geprüfter Basis.
Werkzeuge zur Selbstprüfung
1. Ist meine Version verwundbar?
Ein Online-Checker des Teams, das die Lücke entdeckt hat. Sie geben Ihre Domain ein und erhalten in Sekunden eine Einschätzung, ob Ihre Installation noch angreifbar ist.
→ wp2shell.com
2. Wurde meine Website bereits kompromittiert?
Eye Security stellt ein kostenloses WordPress-Plugin bereit, das gezielt nach den Spuren dieses Angriffs sucht – in der Datenbank und im Dateisystem. Es behebt nichts, sondern zeigt Ihnen den Befund.
→ Compromise Scanner und Anleitung
3. Technische Details zum Angriff
Ausführliche Analyse der Sicherheitsfirma Wordfence – wie die Angriffskette funktioniert und worauf Betreiber achten sollten.
→ Wordfence-Analyse
Die Prüfwerkzeuge sind eine erste Orientierung, kein Freispruch. Ein negativer Befund schliesst eine Kompromittierung nicht sicher aus – manche Schadcode-Varianten löschen ihre Spuren nach der Ausführung. Bei Verdacht lohnt sich eine fachliche Prüfung.
Der Unterschied liegt in der Vorbereitung
Gegen eine Lücke dieser Art hilft keine noch so gute Absicherung – das ist die unbequeme Erkenntnis. Was sich hingegen sehr wohl beeinflussen lässt, ist der Schaden, der daraus entsteht.
Entscheidend sind dabei zwei Ebenen: Wie schnell ein Einbruch überhaupt bemerkt wird – und wie gut vorbereitet die Reaktion darauf ist. Ein Monitoring, das binnen Minuten Alarm schlägt, verkürzt das Zeitfenster, in dem ein Angreifer unbemerkt agieren kann, von Wochen auf Stunden. Und ein durchdachter Wiederherstellungsprozess entscheidet darüber, ob daraus eine Nacht Arbeit wird oder ein Projekt über Tage.
In unserem Fall waren es vier Dinge, die zusammengespielt haben:
- Das Monitoring meldete den unbekannten Zugang unmittelbar.
- Mehrere Backup-Generationen erlaubten es, einen nachweislich sauberen Stand zu identifizieren – ein einzelnes tägliches Backup hätte nicht genügt, weil es bereits infiziert gewesen wäre.
- Getrennte Hosting-Umgebungen verhinderten eine Ausbreitung.
- Und ein definierter Wiederherstellungsablauf ersetzte Improvisieren.
Ergebnis: Die Website läuft wieder auf sauberer Basis, ohne Inhaltsverluste, mit einer Ausfallzeit im Rahmen weniger Stunden. Für den Kunden entstanden keine zusätzlichen Kosten, weil die Betreuungsvereinbarung genau das abdeckt.
Ein Punkt verdient dabei besondere Erwähnung, weil er in der Praxis oft unterschätzt wird: Wo mehrere Websites im selben Hosting-Konto liegen, kann Schadsoftware von einer zur nächsten springen. Sie teilen sich dasselbe Dateisystem – eine kompromittierte Website kann die Nachbarwebsite infizieren, auch wenn diese selbst gar nicht angreifbar war.
Deshalb betreiben wir jedes Kundenprojekt in einer eigenen, isolierten Umgebung – und arbeiten dafür mit ausgewählten Schweizer Hosting-Partnern zusammen. Das kostet etwas mehr als ein Sammel-Hosting, begrenzt im Ernstfall aber den Schaden auf ein einzelnes Projekt.
Prüfen Sie Ihre eigene Website – jetzt
Der wichtigste Teil dieses Beitrags richtet sich an alle, die ihre WordPress-Website selbst betreuen oder nicht sicher wissen, wer sich darum kümmert.
Ein grosser Teil der betroffenen Websites wurde nie aktualisiert, weil niemand zuständig war. Nicht aus Nachlässigkeit – sondern weil Wartung nach dem Launch oft schlicht niemandem zugeteilt wurde. Genau daraus entstehen die schlechten Erfahrungen, die viele mit WordPress verbinden.
Drei Fragen, die Sie beantworten können sollten:
- Wie schnell wird ein kritisches Sicherheitsupdate bei Ihnen eingespielt? Wenn die Antwort «wenn es jemandem auffällt» lautet, ist das Ihr grösstes Risiko. Hier zählten Stunden.
- Wie viele Backup-Generationen haben Sie – und liegen sie an einem zweiten Ort? Ein Backup von gestern hilft nicht, wenn der Einbruch vorgestern war.
- Würden Sie einen Einbruch überhaupt bemerken? Die meisten Kompromittierungen sind unsichtbar. Die Website sieht normal aus, während sie im Hintergrund für Spam-Versand oder Weiterleitungen missbraucht wird – das passiert nicht selten unbemerkt über Monate.
Fazit
Sicherheit ist kein Zustand, den man einmal herstellt. Sie ist ein Prozess, der auch dann funktionieren muss, wenn etwas schiefgeht – und es geht irgendwann etwas schief.
Eine Website ist für die meisten Unternehmen kein digitales Prospekt, sondern ein Betriebsmittel. Für Betriebsmittel gibt es Wartungspläne und Notfallprozeduren. Für Websites sollte das genauso selbstverständlich sein.
Unsicher, ob Ihre Website betroffen war oder wie schnell Sicherheitsupdates bei Ihnen ankommen? Wir prüfen den aktuellen Stand und zeigen Ihnen, wo Handlungsbedarf besteht.
