WordPress-Sicherheit - Warum Updates und Schutz entscheidend sind

Eine WordPress-Website wird selten durch einen neuen Trick übernommen. Meist ist es eine Lücke, deren Korrektur längst veröffentlicht war und die niemand rechtzeitig eingespielt hat. Dieser Beitrag geht vom jüngsten Sicherheitsrelease des Cores aus und folgt dem ganzen Weg: was behoben wurde, was sich selbst aktualisiert, was nicht, wer für den Rest zuständig ist und was die DSGVO nach einer Panne verlangt.

#Was WordPress 7.1.3 behoben hat

WordPress 7.1.3 erschien am 6. Oktober 2026 mit 7 Sicherheitskorrekturen und 4 Fehlerkorrekturen. Die Ankündigung nennt diese Fehlerklassen:

• gespeichertes XSS auf der Kommentar-Verwaltungsseite über ausstehende Kommentare
• ein Denial-of-Service-Problem in WP_Http::make_absolute_url()
• eine SQL-Injection zweiter Ordnung im WXR-Export
• eine Schwachstelle, mit der Nutzer der Rolle Autor Beiträge oben anheften konnten
• nicht authentifizierte Offenlegung von Kommentaren zu privaten und unveröffentlichten Beiträgen
• XSS in Imgur-Einbettungen
• fälschbare Parameter im Hook {status}_{type}, die zu einer Namenskollision bei Aktionen führten

Unter den Danksagungen stehen Thomas Chauchefoin (Trail of Bits) und Ananda Dhakal (Patchstack). Anthropic wird für drei der Lücken genannt: das Denial of Service, die SQL-Injection und die Schwachstelle beim Anheften von Beiträgen.

Am 17. September 2026 hatte WordPress 7.1.1 bereits 11 Sicherheitskorrekturen gebracht, darunter ein gespeichertes XSS in wpautop(), eine authentifizierte Path Traversal im REST-Templates-Controller und das beliebige Überschreiben von Beiträgen durch Mitarbeiter.

Nüchtern gelesen verlangen die meisten dieser Fehler eine angemeldete Rolle, einen ausstehenden Kommentar oder eine bestimmte Funktion. Genau deshalb werden sie aufgeschoben. Das Argument für Eile ist Rechnerei, kein Alarm: Die Korrektur und ihr Diff sind am Releasetag öffentlich, und die Zeit zwischen diesem Tag und Ihrem Update ist das Fenster, in dem eine bekannte Lücke auf Ihrer Seite liegt. Die Ankündigung hält auch fest, dass “nur die neueste Version von WordPress aktiv unterstützt wird” (eigene Übersetzung), mit Sicherheitskorrekturen, die bei Bedarf in ältere Zweige zurückportiert werden (derzeit bis 4.7).

#Wie das WordPress-Sicherheitsteam Schwachstellen im Core behandelt

Laut wordpress.org/about/security besteht das Sicherheitsteam von WordPress aus mehr als 50 vertrauenswürdigen Fachleuten, darunter Lead Developer und Sicherheitsforscher. Das Team entwickelt und testet die Korrekturen selbst und veröffentlicht sie in Bugfix-Releases. Die Seite beschreibt außerdem die Zusammenarbeit mit großen Hostern und Sicherheitsanbietern beim Rollout und bei WAF-Regeln, die Angriffe dämpfen, bevor alle aktualisiert haben.

Daraus folgen zwei Dinge für den Betrieb. Beim Core kommt die Korrektur aus einer koordinierten Quelle, und das automatische Hintergrund-Update ist der Lieferweg. Ist es aktiv, ist der Großteil der Core-Arbeit erledigt. Bei Plugins und Themes ist das anders: Schwachstellen gehen an den Entwickler und an das Plugin- oder Theme-Team, und das Tempo der Korrektur hängt an einer einzelnen Person. Deshalb liegt der Großteil Ihrer Update-Arbeit in der Plugin-Liste, nicht im Core.

#Wer für WordPress-Updates zuständig ist

Die Frage ist selten “ob”, sondern “wer”. Klären Sie sie schriftlich, bevor etwas passiert:

Laut Ankündigung zu 7.1.3 starten Websites, die automatische Hintergrund-Updates unterstützen, das Update von selbst. Die Upgrade-Dokumentation erklärt die Konstante: true aktiviert Entwicklungs-, Minor- und Major-Updates, false schaltet alle ab, 'minor' erlaubt nur Minor-Updates. Prüfen Sie je Website drei Dinge: Die Konstante steht nicht noch auf false in der wp-config.php, weil ein früherer Entwickler eine Version einfrieren wollte. Die Seite ist kein Versionskontroll-Checkout, der stillschweigend aussteigt. Und der Hoster liefert das Update tatsächlich aus. Ein wp core version auf dem Server am Tag nach einem Sicherheitsrelease klärt den dritten Punkt.

Für Plugins und Themes sagt die Dokumentation, Hintergrund-Updates geschähen nur in Sonderfällen, “wie von der Antwort der WordPress.org-API festgelegt, die vom WordPress-Sicherheitsteam gesteuert wird” (eigene Übersetzung). Seit WordPress 5.5 lassen sich Auto-Updates für jedes Plugin und Theme einzeln ein- oder ausschalten, auf den gewohnten Bildschirmen. Alles einzuschalten ist keine Strategie. Schalten Sie es für kleine Plugins mit sauberer Release-Historie ein, und lassen Sie Shop, Formulare und Mitgliederbereiche über Staging laufen. Wie das vertraglich aussehen kann, beschreibt der Beitrag zum WordPress-Wartungsvertrag.

#Was passiert, wenn ein Plugin im Verzeichnis gesperrt wird

Laut Leitfaden des Plugin-Verzeichnisses werden Schwachstellen dem Plugin-Team gemeldet, das den Entwickler zu erreichen versucht, und “die meisten Plugins werden geschlossen, um neue Downloads zu verhindern, bis das Problem behoben ist” (eigene Übersetzung). Die Sperre verhindert Neuinstallationen. Sie greift nicht auf Ihre Website durch: Ein gesperrtes Plugin, das Sie letztes Jahr installiert haben, läuft weiter. Gleichen Sie einmal im Quartal die aktiven Plugins mit dem Verzeichnis ab und ersetzen Sie gesperrte oder verwaiste. Dasselbe gilt für Supply-Chain-Angriffe, bei denen ein vertrauenswürdiges Plugin den Besitzer wechselt und das nächste Update der Angriff ist. Zur Wartefrist für Updates beim WordPress.org gibt es eine eigene Einordnung.

#WordPress sicher im Live-Betrieb aktualisieren

Ob sich ein Update lohnt, hängt davon ab, ob Sie es rückgängig machen können. Die Routine, die funktioniert:

1. Ziehen Sie ein Backup, das Sie mindestens einmal wiederhergestellt haben. Ein nie getestetes Backup ist eine Hoffnung.
2. Spielen Sie die Updates auf Staging ein und klicken Sie die Pfade durch, die Umsatz bringen oder Daten sammeln: Checkout, Formulare, Login, Suche.
3. Aktualisieren Sie die Produktion in einem verkehrsarmen Fenster und wiederholen Sie denselben Durchlauf.
4. Prüfen Sie das PHP-Fehlerlog auf neue Hinweise, denn ein Plugin kann leise ausfallen.
5. Kennen Sie den Rückweg, bevor Sie starten. Geht es schief, zeigt die Anleitung zum Wiederherstellen einer früheren Version nach fehlgeschlagenem Update den Weg.

Zwei WP-CLI-Befehle erledigen den Großteil der Bestandsaufnahme: wp plugin list --update=available zeigt, was aussteht, wp core check-update den Stand des Cores. Sicherheitsreleases kommen zuerst, der Rest folgt wöchentlich.

Bei Hostern mit Staging per Klick ist die Hürde niedrig. Auf einem eigenen VPS nutzen Sie wp-cli oder eine Deploy-Pipeline und halten Staging hinter HTTP-Auth oder VPN. Ein offener Klon der Produktion mit echten Daten ist schon für sich ein Datenschutzproblem.

Vermeiden Sie auch ein „Staging“, das nur ein Unterordner auf derselben Datenbank ist. Gemeinsame Tabellen und gemeinsame Cookies erzeugen falsche Sicherheit. Echtes Staging hat eine eigene Datenbank und eine eigene URL.

#Wie WordPress ein fehlgeschlagenes Plugin-Update zurückrollt

Seit WordPress 6.3 hat der Core einen eingebauten Rollback für manuelle Plugin- und Theme-Updates. Laut der Entwicklernotiz zu 6.3 wird die installierte Version vor dem Update nach wp-content/upgrade-temp-backup/plugins/ oder wp-content/upgrade-temp-backup/themes/ verschoben. Scheitert die Installation, wandert sie zurück. Gelingt sie, wird die Kopie gelöscht. Site Health erhielt dabei zwei Prüfungen: ob der Backup-Ordner beschreibbar ist und ob genug Speicherplatz für ein sicheres Update vorhanden ist.

Die Grenze steht in derselben Notiz. „Fehlgeschlagen“ heißt, dass die Installation selbst einen Fehler zurückgibt, etwa ein leeres Download-Paket oder Dateien, die sich nicht verschieben lassen. Ein Update, das sauber installiert wird, aber den Checkout zerlegt, gilt als erfolgreich, und die alte Version ist dann bereits gelöscht.

WordPress 6.6 ging bei automatischen Plugin-Updates weiter. Der übernommene Merge-Vorschlag beschreibt den Ablauf: Während automatischer Updates steht die Website im Wartungsmodus, WordPress sendet eine Loopback-Anfrage an die Startseite, um fatale PHP-Fehler zu erkennen, und wenn diese einen Fehler liefert, wird die vorherige Plugin-Version wiederhergestellt und die Adresse aus admin_email per E-Mail informiert. Der Testaufruf zu 6.6 bestätigt, dass das ab 6.6 Standard ist.

Der Mechanismus fängt das Offensichtliche ab: einen fatalen Fehler, der die Startseite lahmlegt. Er fängt keinen Fehler ab, der nur im Checkout, in einem Formular oder in einem Cron-Job sichtbar wird, und der Vorschlag nennt nur Plugins, keine Themes. Der eingebaute Rollback ersetzt also weder Staging noch ein Backup, das Sie mindestens einmal wiederhergestellt haben.

#Wie man automatische Updates im Code steuert

Die Update-Dokumentation beschreibt mehr Schalter als die Konstante WP_AUTO_UPDATE_CORE. Sie helfen, wenn ein Team viele Websites nach denselben Regeln betreut:

• AUTOMATIC_UPDATER_DISABLED in wp-config.php schaltet alle automatischen Updates ab, Core und alles andere. Die Dokumentation rät ausdrücklich davon ab. Finden Sie die Konstante auf einer Website, klären Sie, wer sie gesetzt hat und warum.
• Die Filter auto_update_plugin und auto_update_theme erhalten das zu aktualisierende Element, sodass Sie $item->slug prüfen und die Automatik nur für ausgewählte Plugins einschalten können. Gibt der Filter für alles false zurück, blockiert er auch die Sicherheitsupdates, die WordPress.org in besonderen Fällen ausrollt.
• auto_update_translation steuert die Übersetzungsdateien, die standardmäßig automatisch aktualisiert werden.
• auto_core_update_send_email steuert die E-Mails zu Core-Updates. Der Filter erhält den Typ (success, fail oder critical), sodass Sie Erfolgsmeldungen stummschalten und Fehlermeldungen behalten können.
• automatic_updates_is_vcs_checkout entscheidet, ob ein .git-, .hg- oder .svn-Ordner im WordPress-Verzeichnis oder darüber automatische Updates stoppt.

Laut Dokumentation gehören die Filter in ein Must-Use-Plugin und nicht in wp-config.php, weil WordPress dort noch nicht vollständig geladen ist und Konflikte entstehen können, unter anderem mit WP-CLI. Ein kleines MU-Plugin in der Versionskontrolle macht die Regeln außerdem für den nächsten Entwickler sichtbar, der die Website übernimmt.

#Wie man eigene Plugins vor falschen Updates schützt

Ein individuell entwickeltes Plugin mit demselben Slug wie ein Plugin im WordPress.org-Verzeichnis konnte früher überschrieben werden, sobald die Verzeichnisversion ein Update bekam. Die Entwicklernotiz zu WordPress 5.8 führte dagegen den Plugin-Header Update URI ein: Zeigt der Wert auf etwas anderes als WordPress.org, versucht WordPress nicht, das Plugin von dort zu aktualisieren. Update URI: false stoppt Updates ganz, und der Filter update_plugins_{$hostname} erlaubt einem eigenen Update-Server, neue Versionen zu liefern. Setzen Sie den Header in jedes interne Plugin. Das dauert eine Minute und beseitigt eine ganze Klasse von Unfällen, bei denen fremder Code über den Update-Button auf die Produktion gelangt.

#WordPress härten, bis der Patch installiert ist

Keine Routine ist sofort. Die Härtung entscheidet, was ein Angreifer in der Zwischenzeit erreicht.

• Kein Datei-Editor. define('DISALLOW_FILE_EDIT', true); in der wp-config.php entfernt den Theme- und Plugin-Editor aus dem Dashboard, sodass eine gestohlene Admin-Sitzung kein PHP aus dem Browser schreiben kann.
• Kein PHP in Uploads. Sperren Sie die Ausführung in wp-content/uploads am Webserver. Ein Upload-Fehler endet dann als abgelegte Datei, nicht als Shell.
• Enge Rechte. Die wp-config.php nur für den Website-Benutzer lesbar, keine für alle beschreibbaren Verzeichnisse.
• Wenige Administratoren. Mehrere Korrekturen der 7.1.x-Reihe hängen an einer Rolle. Weniger privilegierte Konten, weniger ausnutzbare Wege. Geben Sie Redakteuren die Rolle Redakteur, nicht Administrator.
• Starke Anmeldung. Passkeys oder 2FA für jedes Konto, das veröffentlichen oder installieren darf.
• XML-RPC aus, wenn keine App oder Jetpack-Verbindung es braucht: add_filter('xmlrpc_enabled', '__return_false');.

Die vollständige Liste mit Serverbeispielen steht im Leitfaden zur Härtung.

#Wovor eine WAF WordPress schützt

Web Application Firewalls (Cloudflare, Sucuri, die WAF des Hosters oder virtuelles Patching per Plugin von Anbietern wie Patchstack) sind nützlich. Sie ersetzen keine Updates.

Eine WAF ist gut bei:

• Rate Limiting gegen Brute Force auf den Login,
• dem Blockieren bekannter Exploit-Signaturen und schädlicher User-Agents,
• virtuellem Patching: vorübergehendem Blockieren eines bekannten Angriffsmusters, während Sie das Update auf Staging testen,
• Geo- oder ASN-Filtern, wenn offensichtliche Scanmuster auftauchen.

Schwach oder blind ist eine WAF bei:

• Logikfehlern im eigenen Plugin („wenn ?token= passt, gib Admin“),
• kompromittierten, legitimen Admin-Sitzungen (gestohlenes Cookie nach Phishing),
• falschen Dateirechten, die eine hochgeladene PHP-Datei ausführbar machen,
• Hintertüren, die nach einem früheren Einbruch schon in wp-content/uploads liegen,
• Supply-Chain-Problemen, bei denen ein aktualisiertes Plugin selbst kompromittiert ist (seltener, aber im Ökosystem dokumentiert).

Die Reihenfolge ist deshalb immer dieselbe: zuerst aktualisieren und härten, die WAF als zusätzliche Schicht und als Puffer im Patch-Fenster. „Cloudflare davorschalten“ und die Arbeit für erledigt halten ist ein häufiger Fehler, besonders wenn das DNS stimmt, der Ursprungsserver aber wp-admin weiter direkt über die IP ausliefert.

#Warum die PHP-Version zur Update-Routine gehört

WordPress-Updates helfen wenig, wenn das PHP darunter keine Sicherheitskorrekturen mehr bekommt. Die Anforderungsseite auf wordpress.org empfiehlt PHP 8.3 oder neuer, MySQL 8.0 oder neuer bzw. MariaDB 10.11 oder neuer sowie HTTPS. Sie sagt auch, dass WordPress unter PHP 7.4 und MySQL 5.5.5 läuft, diese Versionen aber ihr Lebensende erreicht haben und die Website Schwachstellen aussetzen können.

Die Übersicht auf php.net zeigt im Oktober 2026, dass PHP 8.2 nur noch Sicherheitskorrekturen erhält und diese am 31. Dezember 2026 enden. PHP 8.3 erhält Sicherheitskorrekturen bis zum 31. Dezember 2027, 8.4 und 8.5 haben noch aktiven Support. Zweige älter als 8.2 bekommen keine Korrekturen mehr. Die Version sehen Sie unter Werkzeuge, Website-Zustand, Reiter Bericht, oder mit php -v auf dem Server. Planen Sie den Wechsel auf Staging wie ein größeres WordPress-Update. Ein altes Plugin, das kein neueres PHP verträgt, ist ein Argument, das Plugin zu ersetzen, nicht auf einem PHP-Zweig ohne Korrekturen zu bleiben.

#Was die DSGVO nach einer Datenpanne verlangt

Art. 32 der DSGVO verlangt “geeignete technische und organisatorische Maßnahmen” zum Schutz personenbezogener Daten. Art. 33 verlangt die Meldung an die Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden, nachdem die Verletzung bekannt wurde, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Verstöße gegen Pflichten aus den Art. 25 bis 39 fallen unter die niedrigere Bußgeldstufe des Art. 83 Abs. 4: bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.

Die Verordnung sagt nicht “spielen Sie Updates ein”. Ein Shop, der Kundendaten sammelt und wochenlang ein Plugin mit veröffentlichter Korrektur laufen ließ, wird diese Maßnahme aber schwer verteidigen können. Halten Sie fest, was das Gegenteil belegt: Update-Daten, den Staging-Test, den Rollback-Plan. Dieselben Nachweise helfen bei einem EU-Konformitätsaudit.

#Gehackte WordPress-Website erkennen

Eingeschleuster SEO-Spam ist so gebaut, dass der Betreiber ihn nicht bemerkt. Die Seiten werden Googlebot gezeigt, nicht Besuchern, eine saubere Startseite beweist also nichts. Diese Prüfungen schon:

• wp core verify-checksums und wp plugin verify-checksums --all vergleichen die Dateien mit den offiziellen Releases und melden Abweichungen.
• Suchen Sie PHP-Dateien, die neuer sind als die wp-config.php, zuerst im Theme-Ordner.
• wp user list --role=administrator darf nur Personen zeigen, die Sie kennen.
• Eine Dateiänderung, die im Team niemand erklären kann, ist ein Vorfall. Gehen Sie direkt zur Eindämmung über.

Wenn die Prüfung jemand übernehmen soll, der die Website nicht besitzt, deckt ein WordPress-Sicherheitsaudit veraltete Komponenten, offene Benutzerlisten und Serverkonfiguration in einem Durchgang ab.

#Typische WordPress-Sicherheitsfehler in Unternehmen

Einige Muster wiederholen sich bei kleinen Unternehmen und Agenturkunden:

Zahlungs- und Buchungsstack ohne Verantwortlichen. PayPal, Klarna, Stripe, Easy Digital Downloads, Bookly oder Amelia werden aktualisiert, „wenn Zeit ist“. Das Zahlungs-Plugin ist genau der Ort, den Angreifer suchen, weil die Beute direkt ist. Bestimmen Sie eine Person, die Sicherheitsmeldungen genau für diese Slugs verfolgt.

Produktionsdaten auf Staging ohne Bereinigung. Kopien von Kundenlisten, Bestellhistorie und Mitgliedschaften auf einer offenen Staging-URL sind ein Datenschutzproblem, bevor überhaupt jemand einbricht. Maskieren Sie die Daten oder beschränken Sie den Zugriff. Die Aufsichtsbehörde interessiert sich für die Sicherheit der Verarbeitung, nicht dafür, ob die Umgebung „dev“ heißt.

Agentur und Kunde ohne klare Zuständigkeit. Der Kunde glaubt, die Agentur patcht. Die Agentur glaubt, der Kunde klickt in wp-admin. Schreiben Sie es auf: Wer überwacht Updates, wer gibt Staging für die Produktion frei, wer hat 2FA im Hosting-Panel. Ohne diesen Satz wird der Patch auf die Zeit nach Black Friday oder dem Weihnachtsgeschäft verschoben, genau dann, wenn am wenigsten Zeit für Brandbekämpfung ist.

„Sicherheits-Plugin“ statt Hardening. Ein Plugin, das Dateien scannt, ist als Signal nützlich. Es ersetzt keine Dateirechte, keine Updates und nicht das Sperren von install.php nach der Installation. Arbeiten Sie die Punkte aus dem Hardening im Developer Handbook ab, bevor Sie eine weitere Lizenz kaufen.

E-Mail und SMTP-Schlüssel. Ein kompromittiertes SMTP-Plugin oder ein geleakter SendGrid- oder Mailgun-Schlüssel wird für Phishing im Namen Ihrer Firma genutzt. Rotieren Sie Schlüssel, wenn jemand geht, und begrenzen Sie die API-Berechtigungen.

#Was Sie diese Woche an Ihrer WordPress-Website prüfen sollten

Bestätigen Sie, dass 7.1.3 auf jeder Website installiert ist. Listen Sie die Plugins mit ausstehenden Updates und sortieren Sie sie danach, worauf jedes Zugriff hat. Entfernen Sie Verwaistes. Zählen Sie die Administratorkonten und kürzen Sie sie. Tragen Sie dann die nächste Prüfung in den Kalender ein, denn das nächste Sicherheitsrelease wartet nicht.