WordPress 7.0.2 ist ein Sicherheitsrelease vom 17. Juli 2026. Für Betreiber zählt jetzt nicht nur, ob ein Update angestoßen wurde. Entscheidend ist, welche korrigierte Version tatsächlich installiert ist und ob die geschäftlich wichtigen Funktionen der Website danach weiterhin zuverlässig arbeiten.
Welche WordPress-Version ist betroffen?
Der notwendige Versionsstand hängt von der zuvor eingesetzten Hauptversion ab:
- WordPress-Versionen vor 6.8 sind nicht betroffen.
- WordPress 6.8 ist nur vom ersten der beiden behobenen Probleme betroffen. Die Korrektur ist in WordPress 6.8.6 enthalten.
- WordPress 6.9 benötigt Version 6.9.5. Sie behebt beide Probleme.
- WordPress 7.0.x benötigt Version 7.0.2. Sie behebt ebenfalls beide Probleme.
Für betroffene Versionen wurden erzwungene automatische Updates aktiviert. Das reduziert den Zeitraum bis zur Installation, ersetzt aber nicht den Nachweis, dass die richtige Version auf der konkreten Website angekommen ist.
Die technischen Angaben und korrigierten Versionszweige nennt die offizielle WordPress-Mitteilung zum Release 7.0.2. Am 21. Juli 2026 nahm CISA die betreffenden Schwachstellen außerdem in ihren Known Exploited Vulnerabilities Catalog auf. Dazu liegt eine offizielle CISA-Meldung vor.
So weisen Sie den installierten Versionsstand nach
Prüfen Sie die Versionsnummer direkt in der WordPress-Administration und, wenn möglich, zusätzlich über Ihr Hosting oder Ihre Verwaltungsplattform. Für einen belastbaren Nachweis sollten Website, Zeitpunkt und festgestellte Versionsnummer dokumentiert sein.
- Bei WordPress 6.8 muss mindestens Version 6.8.6 installiert sein.
- Bei WordPress 6.9 muss mindestens Version 6.9.5 installiert sein.
- Bei WordPress 7.0 muss mindestens Version 7.0.2 installiert sein.
- Ein angezeigter Update-Auftrag oder eine automatische Update-E-Mail allein belegt noch nicht das Ergebnis.
Kontrollieren Sie auch, ob das Update vollständig abgeschlossen wurde. Wartungsmodus, ausstehende Datenbankaktualisierungen oder Fehlermeldungen im Backend sind Gründe für eine genauere Prüfung.
Welche Website-Funktionen nach dem Update getestet werden sollten
Ein korrekter Versionsstand sagt noch nichts darüber aus, ob Formulare, Anmeldungen und angebundene Abläufe wie vorgesehen funktionieren. Testen Sie deshalb die Wege, über die Anfragen, Buchungen oder Umsätze entstehen.
- Senden Sie jedes wichtige Kontakt-, Anfrage- und Bewerbungsformular mit realistischen Testdaten ab. Prüfen Sie Bestätigung, Zustellung und gespeicherten Eintrag.
- Testen Sie Login, Passwort-Zurücksetzen und relevante Benutzerrollen. Ein erfolgreicher Administrator-Login allein reicht nicht aus.
- Führen Sie bei Shops einen vollständigen Testkauf bis zur Bestellbestätigung durch. Bei Buchungssystemen prüfen Sie Auswahl, Verfügbarkeit, Bestätigung und Benachrichtigungen.
- Kontrollieren Sie die Übergabe an CRM, Helpdesk, Newsletter-System oder andere angeschlossene Dienste. Vergleichen Sie die übermittelten Felder und prüfen Sie, ob der Datensatz tatsächlich am Ziel ankommt.
Halten Sie Ergebnis und Zeitpunkt der Tests fest. So lässt sich später unterscheiden, ob eine Störung bereits unmittelbar nach dem Update bestand oder erst danach entstanden ist.
Mögliche Angriffsspuren richtig einordnen
Das Update schließt die bekannten Schwachstellen im jeweiligen Versionszweig. Es beantwortet jedoch nicht rückwirkend, ob eine Website zuvor angegriffen oder verändert wurde.
Unbekannte Administratorkonten, unerklärliche Änderungen an Inhalten oder Einstellungen, neu aufgetauchte Erweiterungen, ungewöhnliche Weiterleitungen sowie auffällige Anmelde- oder Serverprotokolle sind Gründe für eine technische Prüfung. Dasselbe gilt, wenn Formulare plötzlich andere Empfänger verwenden oder Integrationen ohne geplante Änderung abweichende Daten übertragen.
Solche Beobachtungen sind Hinweise für die Triage, keine forensischen Beweise. Sie können harmlose Ursachen haben, während ein unauffälliger Schnelltest einen früheren Zugriff nicht sicher ausschließt. Verdächtige Änderungen sollten deshalb dokumentiert und eingegrenzt werden, bevor Dateien, Protokolle oder Konten bereinigt werden.
Welche Nachweise am Ende vorliegen sollten
- Die installierte, für den verwendeten Versionszweig korrigierte WordPress-Version
- Ein dokumentierter erfolgreicher Test der geschäftlich wichtigen Website-Funktionen
- Ein bestätigter Test der Datenübergabe an angeschlossene Systeme
- Eine eingeordnete Liste unerklärlicher Änderungen oder Auffälligkeiten
Damit ist nicht automatisch bewiesen, dass die Website nie betroffen war. Es schafft aber eine klare Grundlage für die nächsten Entscheidungen und zeigt, wo eine vertiefte Prüfung nötig ist.
Fehlt Ihnen einer dieser Nachweise? Beim DKSIGN WordPress Security Check prüfen wir Versionsstand, kritische Website-Funktionen und auffällige Veränderungen und liefern eine priorisierte Liste der nächsten Schritte.