WordPress-Sicherheit, Updates und Hardening

Aktuelle Fassung: WordPress-Sicherheit, Updates und Schutz mit dem Sicherheitsrelease 7.1.3, Auto-Updates, Update-Routine und DSGVO-Pflichten.

WordPress ist eines der beliebtesten Content-Management-Systeme (CMS) und treibt Millionen von Websites weltweit an. Benutzerfreundlichkeit, Flexibilität und die große Auswahl an Plugins machen es zur Wahl für Blogger, Unternehmer und große Organisationen. Dieselbe Popularität sorgt dafür, dass Botnetze rund um die Uhr wp-login.php, REST-Endpunkte und veraltete Plugins scannen. Sicherheit hängt hier selten an einem einzelnen „Sicherheits-Plugin“. Sie ist eine Betriebsroutine: Updates, Staging, minimale Rechte und ein ehrliches Verständnis dessen, was eine WAF tatsächlich abdeckt.

Dieser Beitrag stützt sich auf das offizielle WordPress-Hardening, auf die Update-Dokumentation von developer.wordpress.org und auf öffentliche Quellen von Patchstack, nicht auf erfundene CVE-Prozentzahlen.

#WordPress-Sicherheit, Grundlagen

Einbrüche und Malware setzen die Website finanziellen, rechtlichen und Reputationsschäden aus, von denen sie sich schwer erholt. Grundlegende Maßnahmen umfassen:

• regelmäßige Updates von WordPress, Plugins und Themes,
• starke Passwörter und eindeutige Benutzernamen,
• regelmäßige Backups, geprüft durch eine echte Wiederherstellung,
• ein abgesichertes Hosting und einen abgesicherten Server,
• ein Sicherheits-Plugin als zusätzliches Signal, nicht als Ersatz für die übrigen Punkte.

#Warum WordPress-Updates für die Sicherheit wichtig sind

Eine Schwachstelle in einem Plugin wird erst gefährlich, wenn sie öffentlich bekannt ist und Ihre Installation noch die alte Version ausführt. Patchstack veröffentlicht regelmäßig Auswertungen zum WordPress-Ökosystem, darunter State of WordPress Security in 2026. Wenn Sie Zahlen brauchen, nehmen Sie sie von dort. Runde Behauptungen wie „99 % aller Einbrüche“ ohne Quelle gehören nicht in ein Sicherheitskonzept.

Updates decken drei Ebenen ab:

• Core: Sicherheitsreleases von wordpress.org schließen Fehler in Login, REST API, Mediathek und Dateiverarbeitung.
• Plugins: Hier liegt der Großteil der externen Angriffsfläche. Ein verlassenes Plugin ohne Maintainer ist ein dauerhaftes Risiko, auch wenn es „nur“ ein Formular anzeigt.
• Themes: seltener in den Schlagzeilen, aber eigene Änderungen in functions.php, Page Builder und alte Child Themes können Datei-Uploads oder XSS öffnen.

Vernachlässigte Updates öffnen den Weg für Einbrüche, Malware, den Verlust des Zugriffs oder der Daten und nebenbei für Konflikte zwischen Plugins und Themes. In einem deutschen Shop mit PayPal, Klarna oder Mollie ist das Zeitfenster für ein Update kürzer als bei einem einfachen Firmenblog. Zahlungs-Plugins sprechen mit externen APIs. Eine bekannte Lücke dort ist ein Reputations-, Datenschutz- und Vertragsrisiko nach der DSGVO, mit der Datenschutzaufsicht des jeweiligen Bundeslandes als zuständiger Behörde.

#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. Korrekturen werden in ältere Versionen zurückportiert, damit ältere Websites kritische Sicherheitskorrekturen über automatische Updates erhalten.

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.

#So testen Sie WordPress-Updates auf Staging

Direkt auf der Produktion auf „Aktualisieren“ zu klicken, ist der häufigste Grund, warum Teams Sicherheitspatches aufschieben. Die Angst vor einem kaputten Checkout, einem zerschossenen Elementor-Layout oder einem stillen Fehler im WooCommerce-Bestellstatus ist real. Die Lösung ist nicht, den Patch aufzuschieben, sondern Staging.

Eine brauchbare Staging-Routine sieht so aus:

1. Erstellen Sie ein frisches Backup (Dateien und Datenbank) mit geprüfter Wiederherstellung, nicht nur „ein Backup-Plugin ist installiert“.
2. Klonen Sie die Produktion auf Staging mit derselben PHP-Version und denselben Erweiterungen (Imagick, Redis, OPcache).
3. Führen Sie die Updates auf Staging aus. Testen Sie Login, Formulare, Checkout, Suche und eigene Shortcodes.
4. Dokumentieren Sie, was kaputtgegangen ist. Beheben Sie es auf Staging, nicht in einer hektischen SSH-Sitzung auf dem Live-System.
5. Spielen Sie die Updates in einem geplanten Fenster auf die Produktion, mit demselben Backup bereit für die Rücknahme.

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.

#Benutzerrollen und Zugriffsrechte in WordPress

Wird ein Konto kompromittiert, entscheidet die Rolle über das Ausmaß des Schadens. WordPress-Rollen sind grob, aber besser als ein Zustand, in dem alle Administrator sind.

Regeln, die in Agenturen und kleinen Unternehmen funktionieren:

• Administrator nur für Personen, die Plugins installieren, Permalinks ändern oder Einstellungen rund um wp-config.php anfassen. Ein Marketingteam braucht das selten.
• Redakteur / Autor für Inhalte. Sie brauchen keine Plugin-Installation.
• Shop-Manager (WooCommerce) für Bestellungen und Produkte, ohne Zugriff auf Theme-Dateien.
• Ein eigenes Konto pro Person. Geteilte „admin / Admin123!“-Konten machen Logs wertlos und Kündigungen gefährlich.
• Starke Authentifizierung: lange Passwörter in einem Passwortmanager und 2FA, wo verfügbar. Interne Werkzeuge hinter SSO oder VPN sind noch besser.

Dasselbe Prinzip gilt außerhalb von wp-admin. Der Datenbankbenutzer sollte nicht root sein. Der SFTP-Benutzer sollte keinen Schreibzugriff auf den ganzen Server haben. Cron-Jobs, die als www-data laufen, brauchen keine unnötigen sudo-Rechte. Das offizielle Hardening beschreibt Dateirechte, das Abschalten des Dateieditors im Backend und die Einschränkung von XML-RPC, wo es nicht gebraucht wird, siehe Hardening WordPress. Das Hardening im Detail, von Dateirechten bis zur Serverkonfiguration, behandelt der Beitrag über erweiterte WordPress-Sicherheit und Hardening.

Ein gedachter, aber realistischer Ablauf: Eine Agentur gibt einem Freelancer vorübergehend Administratorrechte, um ein Elementor-Problem zu beheben. Das Konto wird nie entfernt. Drei Monate später wird das E-Mail-Postfach des Freelancers kompromittiert, und der Angreifer erbt den Administrator auf der Kundenwebsite. Minimale Rechte und befristete Konten beenden diese Geschichte, bevor sie beginnt.

#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.

#Wie oft man WordPress aktualisieren sollte

Eine Routine, die nur in einem Dokument lebt, stirbt in der Urlaubszeit. Binden Sie sie an einen Kalender und an eine verantwortliche Person:

• Wöchentlich: verfügbare Updates prüfen, Sicherheitsmeldungen zu den Plugins lesen, die Sie wirklich nutzen, und Fehlerlogs ansehen (PHP, Webserver, WAF).
• Bei einem Sicherheitsrelease: Staging am selben Tag für kritische Plugins, Produktion nach einem kurzen Smoke-Test.
• Monatlich: ungenutzte Plugins und Themes entfernen, die Benutzerliste prüfen und testen, ob sich das Backup auf ein leeres Staging zurückspielen lässt.
• Quartalsweise: Zugangsschlüssel prüfen (SMTP, Zahlungsanbieter, Google-Dienste), kontrollieren, dass keine ehemaligen Freelancer noch Admin sind, und Patchstack oder andere öffentliche Advisories zu den Plugins Ihres Stacks lesen.

Bei WordPress Multisite oder Headless-Setups mit getrenntem Frontend ist die Liste länger, der Kern bleibt gleich: Bekannte Schwachstellen schließt man mit Versionssprüngen, nicht mit Hoffnung.

#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.

#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.

#Welche Folgen hat mangelnde technische Unterstützung bei WordPress

Werden Updates und Zugriffskontrolle aufgeschoben, ist der Schaden selten theoretisch:

• Defacement oder SEO-Spam in index.php und eingeschleuste ausgehende Links,
• versteckte Malware in der Mediathek, die sich an Besucher verteilt,
• Diebstahl von Kundendaten aus Formularen und Bestellungen,
• Sperrlisten bei Google Safe Browsing oder E-Mail-Anbietern,
• Stunden oder Tage Ausfallzeit, während jemand Dateien ohne sauberes Backup bereinigt, mit Folgen für Traffic, Conversions und Google-Positionen.

Die Wiederherstellung kostet fast immer mehr als die aufgeschobene Update-Sitzung, egal ob Sie selbst betreiben oder Hilfe einkaufen. Nach einem Einbruch ist die Reihenfolge: Website offline nehmen oder in den Wartungsmodus schalten, Logs sichern, ein bekannt sauberes Backup zurückspielen, falls vorhanden, alles patchen, alle Geheimnisse rotieren und erst dann wieder Traffic zulassen. Dateien auf einem kompromittierten System zu „säubern“, ohne zu wissen, wann die Hintertür kam, ist Glücksspiel.

Die Zusammenarbeit mit einem erfahrenen WordPress-Entwickler bringt regelmäßige Überwachung und Wartung, schnelle Fehlererkennung und jemanden, der Staging, Update-Routine und Hardening einrichtet, ohne ein weiteres Plugin zu installieren, das niemand versteht.

#Checkliste für WordPress-Sicherheit

• Core, Plugins und Themes sind aktuell oder haben einen datierten Plan auf Staging.
• Das Backup wurde durch eine echte Wiederherstellung geprüft.
• Die Zahl der Administratoren ist minimiert, 2FA, wo möglich.
• Der Dateieditor im Backend ist aus, XML-RPC ist eingeschränkt, wenn es nicht gebraucht wird.
• Interne Plugins haben einen Update URI-Header, die Regeln für automatische Updates liegen in einem MU-Plugin.
• Die PHP-Version erhält laut php.net noch Sicherheitskorrekturen.
• WAF oder virtuelles Patching laufen als Puffer, nicht als einzige Verteidigung.
• Staging hat eine eigene Datenbank und ist nicht mit personenbezogenen Produktionsdaten offen.
• Zahlen kommen aus öffentlichen Quellen (WordPress-Hardening, Patchstack), nicht aus geschätzten CVE-Statistiken.

#Ist es wert, sich um WordPress-Sicherheit zu kümmern

Ja, denn WordPress-Sicherheit ist Betriebsarbeit. Updates schließen bekannte Lücken. Staging macht das Aktualisieren sicher. Minimale Rechte begrenzen den Schaden. Eine WAF kauft Zeit. Keines davon ersetzt die anderen.