Blog · 2. September 2026 · aktualisiert 16. Oktober 2026
WordPress-Sicherheitsupdate: erkennen, prüfen, einspielen — mit den Releases 7.0.2 bis 7.1.3 als Beispiel
Anleitung in fünf Schritten, ein Selbsttest und die Sicherheits-Releases seit Juli 2026 (7.0.2 bis 7.1.3) mit Quelle und Datum.
Ein Sicherheitsupdate nennt WordPress.org in der Ankündigung „security release“ und rät, umgehend zu aktualisieren. Sichern Sie zuerst, spielen Sie dann ein und prüfen Sie Startseite, Login und Formulare. Neueste Version: 7.1.3 vom 6. Oktober 2026.
Ist Ihre WordPress-Seite beim Sicherheitsupdate auf der sicheren Seite?
Jedes Nein ist eine Stelle, an der ein Sicherheitsupdate liegen bleiben oder schiefgehen kann. Die ersten drei lösen Sie in einem Nachmittag selbst; die vierte ist die, an der die meisten Seiten scheitern — nicht an der Technik, sondern am Dranbleiben.
Stand 16. Oktober 2026: Neuestes Sicherheits-Release ist 7.1.3 (6. Oktober). Das Projekt empfiehlt, jedes Sicherheits-Release umgehend einzuspielen (Wortlaut in den Belegen). Sie sehen es im Dashboard unter „Aktualisierungen“ und in den Ankündigungen auf wordpress.org/news. Seit Juli 2026 erschienen mehrere Sicherheits-Releases hintereinander; die Meldung „7.0.4 ist aktuell“ gilt also nicht mehr.
Anleitung: Sicherheitsupdate erkennen, prüfen, einspielen
- Erkennen. Öffnen Sie im Dashboard Aktualisierungen. Notieren Sie die installierte Version. Vergleichen Sie sie mit der Security-Kategorie auf wordpress.org/news: Steht dort ein neueres Release für Ihren Zweig, ist Ihre Seite hinten dran. Wer nicht mitlesen will, lässt sich mit dem Alters-Check zeigen, wie alt eine Installation von außen wirkt.
- Einordnen. Lesen Sie den Abschnitt „Security updates included in this release“. Lücken ohne Anmeldung („unauthenticated“, „pre-auth“) und Codeausführung („remote code execution“) sind die dringenden. Lücken, die erst ab einer Rolle wie Mitarbeiter oder Autor greifen, betreffen vor allem Seiten mit mehreren Redakteuren.
- Backup anlegen. Vollständig (Dateien und Datenbank) und nicht nur auf dem Server selbst. Wie das geht, steht im Beitrag zum WordPress-Backup.
- Einspielen. Dashboard → Aktualisierungen → Jetzt aktualisieren. Danach Plugins und Themes, falls Updates anstehen. Bei Shops und Seiten mit Umsatz zuerst auf einer Kopie (Staging), sonst außerhalb der Stoßzeiten.
- Prüfen. Startseite, ein Beitrag, Login, ein Formular und — falls vorhanden — der Warenkorb. Danach im Dashboard noch einmal Aktualisierungen öffnen: Dort darf kein weiteres WordPress-Update mehr angeboten werden. Funktioniert etwas nicht mehr, deaktivieren Sie die Plugins nacheinander, bevor Sie das Backup zurückspielen. Weiterhelfen können Kritischer Fehler in WordPress und WordPress gehackt erkennen.
Warum der Zweig nicht reicht: die Releases seit Juli 2026
Alle Angaben stammen aus den Ankündigungen auf wordpress.org/news, gelesen am 16. Oktober 2026 (Wortlaut in den Belegen). Die Übersetzungen der Lückenbeschreibungen sind unsere.
| Release | Datum | Was die Ankündigung nennt |
|---|---|---|
| 7.0.2 | 17. Juli 2026 | eine kritische und eine hohe Lücke (SQL-Injection, Codeausführung über die REST-API); erzwungene Updates über das Auto-Update-System |
| 7.0.3 | 6. August 2026 | „several security fixes“, darunter eine Lücke auf der Login-Seite (CVE-2026-64638) |
| 7.0.4 | 12. August 2026 | ein Sicherheitsfix: Codeausführung über hochgeladene Dateien (CVE-2026-65640) |
| 7.1.1 | 17. September 2026 | 11 Sicherheitsfixes, 36 Fehlerbehebungen |
| 7.1.2 | 22. September 2026 | eine kritische Lücke bei der Template-Auswahl (CVE-2026-87902) |
| 7.1.3 | 6. Oktober 2026 | 7 Sicherheitsfixes, 4 Fehlerbehebungen |
Sechs Sicherheits-Releases zwischen dem 17. Juli und dem 6. Oktober 2026 sind eine Taktfrage: Ein Update im Quartal kommt zu spät, und „ich habe 7.0“ sagt nichts darüber, ob die Seite abgesichert ist.
7.0.2 (17. Juli 2026)
Die Ankündigung nennt „one critical and one high severity security issue“: eine „facilitated SQL injection issue“ und eine Verwechslung bei REST-API-Sammelanfragen mit SQL-Injection, die bis zur Codeausführung führt. Wegen der Schwere hat das Projekt „forced updates via the auto-update system“ für betroffene Seiten aktiviert. Betroffen waren laut Ankündigung auch 6.9 (behoben in 6.9.5) und 6.8 (behoben in 6.8.6); Versionen vor 6.8 nicht. Die Hintergründe zu dieser Lücke beschreibt wp2shell: die kritische WordPress-Lücke.
7.0.3 (6. August 2026)
Das Release behebt zwölf aufgezählte Probleme. Das gewichtigste ist ein „pre-auth reflected cross-site scripting (XSS) on the login screen with potential to lead to PHP code execution“ — also ohne Anmeldung auslösbar, unter Umständen bis zur PHP-Ausführung. Dazu mehrere gespeicherte XSS-Lücken ab der Rolle Contributor (Mitarbeiter), eine Rechteausweitung in Multisite-Netzwerken mit offener Registrierung, Informationspreisgabe über den Block „Neueste Kommentare“ bei passwortgeschützten Beiträgen und eine serverseitige Anfragefälschung (SSRF) in der URL-Prüfung.
7.0.4 (12. August 2026)
Ein Fix für „authenticated Author+ remote code execution via malicious file upload on sites that use Imagick and Ghostscript“, übersetzt: Wer mindestens Autor ist, kann über eine präparierte Datei Code auf dem Server ausführen, sofern dort Imagick und Ghostscript zur Bildverarbeitung laufen. Ob Ihr Hoster beides einsetzt, weiß nur er; fragen Sie nach, statt es anzunehmen.
7.1.1 bis 7.1.3 (September und Oktober 2026)
7.1.2 behebt, dass ein Angreifer ohne Anmeldung unter bestimmten Bedingungen eine lesbare lokale PHP-Datei außerhalb der Theme-Ordner einbinden lassen kann („remote code execution“, wenn Server und Theme die Voraussetzungen erfüllen). Die Einzelheiten zu 7.1.1 und 7.1.3 stehen in den verlinkten Ankündigungen. Die Ankündigungen zu 7.0.3, 7.0.4, 7.1.2 und 7.1.3 enthalten den Satz, dass nur die jeweils neueste WordPress-Version aktiv unterstützt wird; wer auf einem älteren Zweig bleibt, verlässt sich darauf, dass jede Korrektur zurückportiert wird.
Zwei Dinge, die Sie unabhängig vom Release tun können
Rollen ausmisten. Mehrere der genannten Lücken brauchen ein Konto ab Mitarbeiter oder Autor. Gastautoren, ehemalige Mitarbeiter und die Agentur von 2019 haben in der Benutzerliste nichts mehr zu suchen. Jedes Konto, das niemand mehr braucht, ist ein Konto, das jemand anders brauchen kann.
Prüfen, wer Updates tatsächlich einspielt. Bei einer Firmenseite mit mehreren Plugins heißt „wir machen das“ oft: bei Gelegenheit. Für Betriebe, die unter NIS2 fallen, ist ein dokumentierter Update-Prozess außerdem Pflicht-Thema; Einzelheiten stehen in den NIS2-Pflichten für Ihre WordPress-Website.
Selber machen oder abgeben?
Selbst: ein einzelnes Core-Update mit Backup, Test und Rückweg. Dafür reicht die Anleitung oben.
Abgeben: wenn niemand verlässlich dranbleibt (die Abstände zwischen den sechs Releases lagen bei 5 bis 36 Tagen, auch im Urlaub), Plugins und Themes mitziehen müssen, ein Test auf einer Kopie und ein geprobtes Zurückspielen im Alltag fehlen oder schon etwas passiert ist. Die laufenden Updates übernimmt die WordPress-Wartung: Backup vor jedem Update, Updates für Core, Themes und Plugins täglich (im Paket „Standleitung“ dreimal täglich und zuerst auf einer Staging-Kopie), Überwachung und Monatsbericht. Preise stehen auf der Seite. Was zur Absicherung sonst gehört, fasst WordPress-Sicherheit zusammen.
Belege: Wortlaut, Quelle, Abrufdatum 16.10.2026
Alle Zitate stammen von wordpress.org/news, abgerufen am 16. Oktober 2026. Unsere eigene Einordnung steht jeweils getrennt darunter.
| Aussage | Wortlaut | Quelle |
|---|---|---|
| Empfehlung | „Because this is a security release, it is recommended that you update your sites immediately.“ | 7.0.4, 12.08.2026 |
| Updateweg | „You can update to WordPress 7.0.4 by downloading it from WordPress.org, or visiting your site’s Dashboard → Updates and clicking Update Now.“ | 7.0.4 |
| Hintergrund-Updates | „Sites that support automatic background updates will begin updating shortly.“ | 7.0.4 |
| 7.0.4, Lücke | „Authenticated Author+ remote code execution via malicious file upload on sites that use Imagick and Ghostscript.“ Advisory: CVE-2026-65640 | 7.0.4 |
| Nur neueste Version | „As a reminder, only the most recent version of WordPress is actively supported.“ | 7.0.3, 7.0.4, 7.1.2, 7.1.3 |
| Rückportierung | „the security fixes are being backported, where necessary, to all branches eligible to receive security fixes (currently through 4.7)“ | 7.1.3, 06.10.2026 |
| 7.0.2 | „The 7.0.2 security release addresses one critical and one high severity security issue.“ – „the WordPress.org team have enabled forced updates via the auto-update system for sites running affected versions“ | 7.0.2, 17.07.2026 |
| 7.0.2, Zweige | „WordPress 6.9 is affected by both vulnerabilities. Version 6.9.5 has been released containing fixes for both.“ – „Versions of WordPress prior to 6.8 are not affected.“ | 7.0.2 |
| 7.0.3 | „features several security fixes“; „Pre-auth reflected cross-site scripting (XSS) on the login screen with potential to lead to PHP code execution“; Advisory: CVE-2026-64638 | 7.0.3, 06.08.2026 |
| 7.1.1 | „17 bug fixes on Core, 19 bug fixes for the Block Editor, and 11 security fixes“ | 7.1.1, 17.09.2026 |
| 7.1.2 | „a critical severity security vulnerability“; „an unauthenticated attacker can, under certain conditions, make page template resolution include a chosen readable local PHP file outside the active theme directories“; Advisory: CVE-2026-87902 | 7.1.2, 22.09.2026 |
| 7.1.3 | „This security and maintenance release features 7 security fixes and 4 bug fixes.“ | 7.1.3 |
| Automatische Kern-Updates | „Standardmäßig aktualisiert WordPress kleinere Sicherheits- und Wartungs-Releases automatisch.“ | WPBeginner, So aktualisieren Sie WordPress sicher, 28.08.2026 |
Eigene Ergänzung, nicht Teil der Zitate:
- Die Abstände von 5 bis 36 Tagen haben wir aus den Veröffentlichungsdaten der sechs Ankündigungen selbst berechnet (kürzester Abstand 17.09. bis 22.09.: 5 Tage, längster 12.08. bis 17.09.: 36 Tage).
- „Zwölf aufgezählte Probleme“ bei 7.0.3 ist unsere Zählung der Aufzählung in der Ankündigung.
- Die deutschen Übersetzungen und Erklärungen („Wer mindestens Autor ist …“) sind unsere.
- Näherung, WebSearch, 16.10.2026: Eine Suche nach „WordPress Sicherheitsupdate einspielen Anleitung“ zeigt vor allem ältere Meldungen zu einzelnen Versionen (zum Beispiel 4.7.1, 3.8.2) und allgemeine Update-Anleitungen wie die von WPBeginner. Der WPBeginner-Beitrag beschreibt Backup, Update im Dashboard, FTP-Weg und Prüfung danach. Dieser Beitrag ergänzt das um den Selbsttest, die datierte Chronik von 7.0.2 bis 7.1.3 und die Abgrenzung zum Selbermachen. Es ist eine Näherung an die Top 10, keine Rangmessung.
Häufige Fragen
Woran erkenne ich, dass ein WordPress-Update ein Sicherheitsupdate ist?
An der Ankündigung auf wordpress.org/news: Sicherheits-Releases sind dort in der Kategorie „Security“ eingeordnet und enthalten den Satz, dass wegen der Sicherheitsfixes empfohlen wird, die Seite umgehend zu aktualisieren (z. B. in der Ankündigung zu 7.1.3 vom 6. Oktober 2026, abgerufen am 16.10.2026; Wortlaut in den Belegen).
Muss ich jedes Sicherheitsupdate umgehend einspielen?
Das Projekt empfiehlt es für jedes Sicherheits-Release („it is recommended that you update your sites immediately“, WordPress 7.0.4, abgerufen am 16.10.2026; 7.1.3 enthält denselben Satz). Ein Backup davor und ein kurzer Test danach gehören trotzdem dazu; ohne Sicherung zu aktualisieren, tauscht ein Risiko gegen ein anderes.
Reicht es, auf 7.0.4 zu bleiben?
Nein, nicht dauerhaft. Nach 7.0.4 vom 12. August 2026 erschienen 7.1.1 (17. September), 7.1.2 (22. September) und 7.1.3 (6. Oktober). Die Releases weisen darauf hin, dass Korrekturen auch auf ältere Zweige zurückportiert werden; sie weisen zugleich darauf hin, dass nur die jeweils neueste WordPress-Version aktiv unterstützt wird (abgerufen am 16.10.2026). Welche Nummer für Ihren Zweig die neueste ist, zeigt das Dashboard.
Werden Sicherheitsupdates nicht automatisch eingespielt?
Teilweise. In den Ankündigungen steht, dass Seiten mit aktivierten automatischen Hintergrund-Updates sich selbst aktualisieren. Ob das bei Ihnen greift, hängt von Hoster und Einstellungen ab; verlassen Sie sich nicht darauf, ohne es einmal geprüft zu haben. Für Plugins und Themes gilt diese Ankündigung ohnehin nicht.
Was, wenn die Seite nach dem Update kaputt ist?
Dann hilft das Backup von vorher: zurückspielen, Update auf einer Kopie testen, Ursache (meist ein Plugin oder Theme) suchen. Ein Backup, das Sie nie zurückgespielt haben, ist dabei eine Hoffnung; deshalb gehört die Probe-Wiederherstellung in die Anleitung weiter unten.
Zum Weiterlesen
WordPress-Version jetzt checken →kostenlos, ohne Anmeldung