WordPress ist mit einem Marktanteil von über 40 % das mit Abstand populärste CMS weltweit – und entsprechend oft im Visier von Hackern. Allein im Jahr 2023 wurden laut Statistiken täglich über 13.000 WordPress-Websites gehackt. Besonders kleinere Unternehmen und Selbstständige wähnen sich oft in Sicherheit, doch automatisierte Angriffe machen keinen Unterschied zwischen großen und kleinen Seiten. Die gute Nachricht: Viele erfolgreiche Attacken könnten durch einfache Maßnahmen verhindert werden. Sicherheitsexperten schätzen, dass rund 69 % der kompromittierten WordPress-Seiten auf veraltete Software und schwache Passwörter zurückzuführen sind – also auf vermeidbare Fehler. Im Folgenden stellen wir die zehn häufigsten Sicherheitslücken vor und geben praktische Tipps, wie du sie schließen kannst.
1. WordPress nicht aktuell (veraltete Versionen)
Problem: Veraltete WordPress-Versionen stellen ein erhebliches Risiko dar. Sobald Sicherheitslücken bekannt werden, veröffentlichen die Entwickler Updates, um diese zu schließen. Bleibt WordPress ungepatcht, sind diese bekannten Schwachstellen frei zugänglich – Angreifer scannen aktiv nach Websites mit älteren Versionen und nutzen bekannte Exploits aus. Das betrifft nicht nur den WordPress-Core, sondern auch Plugins und Themes. Wer Updates ignoriert, setzt seine Website unnötigen Gefahren aus.
Lösung: Halte dein WordPress stets auf dem neuesten Stand. Installiere umgehend alle Updates für Core, Plugins und Themes, sobald sie verfügbar sind. Am einfachsten geht das, indem du automatische Updates aktivierst. So erhält deine Seite stets die neuesten Sicherheits-Patches, selbst wenn du einmal nicht daran denkst. Prüfe zudem regelmäßig im Dashboard unter „Updates“, ob Aktualisierungen bereitstehen, und spiel diese ein. Wichtig: Lege vor größeren Updates immer ein Backup an (siehe Punkt 6), um im Notfall schnell wiederherstellen zu können.
2. „Admin“ als Benutzername
Problem: „admin“ war früher der Standard-Administratorenname in WordPress – und ist bis heute leider viel zu häufig im Einsatz. Hacker zielen bevorzugt auf das Benutzerkonto admin, da dieser Name weithin bekannt ist. Ist er in deinem System vorhanden, hat ein Angreifer bereits die halbe Miete: Er muss nur noch das Passwort knacken. Auch wenn neuere WordPress-Versionen dich bei der Installation einen eigenen Admin-Benutzernamen wählen lassen, verwenden viele Betreiber unwissentlich weiterhin admin. Das macht Brute-Force-Angriffe deutlich einfacher.
Lösung: Verwende einen einzigartigen Administrator-Benutzernamen. Wenn dein Administratorkonto derzeit „admin“ heißt, solltest du es ändern. Da WordPress eine nachträgliche Änderung nicht direkt zulässt, gehst du am besten so vor: Lege ein neues Administrator-Konto mit einem individuellen Nutzernamen an (keinen offensichtlichen Namen wählen, der leicht zu erraten ist). Melde dich dann mit dem neuen Konto an und lösche den alten admin-User. Weise dabei alle bestehenden Beiträge dem neuen Konto zu, damit keine Inhalte verloren gehen. Alternativ kannst du ein Plugin wie Change Username nutzen, das die Umbenennung ermöglicht. Durch einen nicht-trivialen Login-Namen machst du es Angreifern deutlich schwerer, erfolgreich einzubrechen – idealerweise in Kombination mit starken Passwörtern und weiteren Schutzmaßnahmen.
3. Kein SSL-Zertifikat (Seite läuft auf HTTP)
Problem: Eine Website ohne SSL-Verschlüsselung überträgt alle Daten im Klartext. Das betrifft Login-Daten, Passwörter, Kontaktformulare usw. Ohne HTTPS können Angreifer diese Informationen unterwegs abfangen – etwa in öffentlichen WLAN-Netzen. Darüber hinaus stufen aktuelle Browser HTTP-Seiten als „nicht sicher“ ein, was Besucher abschreckt. Auch für SEO ist HTTPS inzwischen ein Ranking-Faktor. Kurz: Fehlt ein SSL-Zertifikat, leidet sowohl die Sicherheit deiner Nutzer als auch das Vertrauen in deine Seite.
Lösung: Aktiviere SSL und setze deine Website auf HTTPS. Die meisten Hoster bieten kostenlose SSL-Zertifikate (z. B. von Let’s Encrypt) an – nutze diese unbedingt. Nach Installation musst du sicherstellen, dass alle Aufrufe auf https://
umgeleitet werden. Stelle in den WordPress-Einstellungen unter Allgemein die Website-URL auf HTTPS um (statt HTTP). Zusätzlich können Plugins wie Really Simple SSL helfen, gemischte Inhalte (Mixed Content) zu bereinigen, falls nach Umstellung noch Warnungen auftreten. Ein aktives SSL sorgt dafür, dass vertrauliche Daten zwischen Browser und Server verschlüsselt übertragen werden – Lauschangriffe haben dann keine Chance mehr.
4. WP_DEBUG ist aktiviert (Fehlermeldungen in Produktion)
Problem: WP_DEBUG ist eine PHP-Debugging-Funktion, die in der wp-config.php aktiviert werden kann, um Fehler auf der Website anzuzeigen. Im Entwicklungsmodus ist das nützlich – auf einer Live-Seite jedoch fatal. Ist WP_DEBUG
eingeschaltet, können detaillierte Fehlermeldungen mit technischen Informationen öffentlich sichtbar werden. Diese verraten einem potenziellen Angreifer z. B. Pfade, Dateinamen, Versionsnummern oder sogar Code-Ausschnitte und Konfigurationsdetails der Seite. Damit lieferst du Hackern wertvolle Anhaltspunkte über dein System auf dem Silbertablett. Zudem wirkt eine mit Warnungen übersäte Seite unprofessionell und kann Besucher verunsichern.
Lösung: Schalte WP_DEBUG auf Live-Seiten immer aus. Öffne dazu die wp-config.php und stelle sicher, dass die Konstante auf define('WP_DEBUG', false);
gesetzt ist (bzw. entferne die Zeile ganz, da WordPress standardmäßig Debugging deaktiviert). Falls zusätzlich WP_DEBUG_DISPLAY
oder display_errors
aktiviert sind, deaktiviere auch diese. Auf Produktionsseiten sollten keine PHP-Fehler nach außen sichtbar sein – sie gehören in Logs, nicht auf die Website. So verhinderst du, dass Besucher oder Angreifer interne Infos zu Gesicht bekommen. Tipp: Nutze für die Entwicklungsphase eine separate Umgebung, in der WP_DEBUG eingeschaltet sein darf, aber niemals auf der Live-Seite.
5. Dateieditor im Dashboard nicht deaktiviert
Problem: WordPress verfügt im Backend über einen Datei-Editor für Themes und Plugins (unter Design → Theme-Editor bzw. Plugin-Editor). Was bequem klingt, ist aus Sicherheitssicht brandgefährlich. Gelingt es einem Angreifer, in dein Admin-Dashboard zu gelangen, kann er über den Editor beliebigen PHP-Code in deine Dateien einschleusen. Beispielsweise lässt sich in Sekunden ein Backdoor in die functions.php deines Themes einfügen. Selbst wenn du ihm später das Login wieder entziehst, behält der Angreifer so dauerhaften Zugriff auf dein System. Kurz gesagt: Solange der Dateieditor aktiv ist, genügt ein einziger kompromittierter Admin-Login, um deine Seite komplett zu übernehmen.
Lösung: Deaktiviere den internen Dateieditor. Das geht, indem du in der wp-config.php folgende Zeile ergänzt: define('DISALLOW_FILE_EDIT', true);
. Damit wird der Theme- und Plugin-Editor im Dashboard ausgeblendet, und selbst ein Administrator kann dort keinen PHP-Code mehr verändern. Alternativ bieten Sicherheits-Plugins oder Hardening-Tools eine One-Click-Option dafür. Wichtig: Du verlierst dadurch nicht die Möglichkeit, Themes oder Plugins zu bearbeiten – dies ist weiterhin via FTP oder Dateimanager möglich. Durch das Abschalten der Editor-Funktion nimmst du Angreifern aber eine einfache Methode, Schadcode in deine Seite einzuschleusen.
6. Kein Backup-Plugin aktiv (fehlende Backups)
Problem: Ein oft unterschätzter Aspekt der Sicherheit ist die Verfügbarkeit von Backups. Keine Website ist 100 % vor Angriffen oder technischen Problemen gefeit. Kommt es zu einem Hack, Datenverlust oder defekten Update, steht man ohne Backup sprichwörtlich vor dem Nichts. Im schlimmsten Fall sind sämtliche Inhalte, Einstellungen und Dateien verloren oder müssen mühsam rekonstruiert werden. Fehlende Backups verlängern Ausfallzeiten enorm und können im Falle eines Security-Incidents den Unterschied zwischen schneller Erholung und dauerhafter Beschädigung der Website bedeuten.
Lösung: Richte ein Backup-System ein und sichere deine Website regelmäßig. Am komfortabelsten geht das mit einem Backup-Plugin (z. B. UpdraftPlus, BackWPup oder ähnlichen), das automatisierte Sicherungen ermöglicht. Plane tägliche Backups ein – mindestens aber wöchentliche, je nach Aktualisierungsfrequenz deiner Inhalte. Ein vollständiges Backup umfasst sowohl die Datenbank als auch die Dateien. Wichtig: Lagere Backup-Dateien an einem externen Ort, etwa Cloud-Speicher oder einen anderen Server. So sind sie auch im Fall einer Kompromittierung deines Webspaces sicher. Und vor allem: Teste im Ernstfall die Wiederherstellung. Ein ungetestetes Backup nützt wenig. Mit aktuellen und geprüften Sicherungen in der Hinterhand kannst du deine Seite nach einem Vorfall schnell aus einem sauberen Zustand wiederherstellen und den Schaden minimieren.
7. Ausführung von PHP im Uploads-Ordner erlaubt
Problem: Der Ordner wp-content/uploads dient zur Ablage von hochgeladenen Medien (Bilder, PDFs etc.) und ist für den Webserver öffentlich zugänglich. Standardmäßig können dort aber auch ausführbare PHP-Dateien liegen. Das öffnet Angreifern Tür und Tor: Kann ein Hacker über ein verwundbares Plugin oder Formular eine PHP-Datei hochladen, lässt sich diese direkt im Browser ausführen – und damit Schadcode auf dem Server starten. Ein solcher Webshell-Upload gehört zu den häufigsten Angriffswegen, um eine WordPress-Seite nach einem ersten Eindringen vollständig unter Kontrolle zu bringen. Kurz: Wenn PHP in uploads nicht geblockt ist, läuft man Gefahr, dass hochgeladene Malware aktiviert werden kann.
Lösung: Verbiete die Ausführung von PHP im Uploads-Verzeichnis. Praktisch geschieht das über eine einfache Server-Konfiguration. Bei Apache-Webservern kannst du in der Datei .htaccess
innerhalb von /wp-content/uploads/
folgende Regeln einfügen:
<Files *.php>
deny from all
</Files>
Damit werden alle PHP-Dateien in diesem Ordner blockiert – sie lassen sich nicht mehr via Browser ausführen. Ähnliches lässt sich für Nginx konfigurieren. Viele Sicherheitsplugins bieten auch eine Option „Disable PHP in Uploads“ als Teil ihrer Hardening-Funktionen. Diese Maßnahme stellt sicher, dass im Upload-Verzeichnis nur statische Dateien ausgeliefert werden. Sollte es einem Angreifer gelingen, eine PHP-Datei dort abzulegen, kann diese dank der Sperre keinen Schaden anrichten.
8. Standard-Datenbankpräfix wp_
Problem: Bei der Installation verwendet WordPress standardmäßig wp_
als Präfix für alle Tabellennamen in der MySQL-Datenbank (z. B. wp_users, wp_posts). Viele Betreiber belassen diese Voreinstellung. Sicherheitsproblematisch ist das vor allem, weil es Angreifern Arbeit erspart. Skriptkiddies und Bots wissen genau, wie die Tabellen heißen, und können so zielgerichtete SQL-Injection-Angriffe durchführen. Zum Beispiel suchen manche Malware automatisch nach der Tabelle wp_users, um Benutzeraccounts auszulesen. Das vorgegebene Präfix macht SQL-Attacken erfolgversprechender, da keine Variationen der Tabellennamen berücksichtigt werden müssen.
Lösung: Verwende ein individuelles DB-Präfix. Am besten setzt man bereits bei der Installation einen eigenen Präfix (z. B. wpxyz_
statt wp_
). Das erschwert automatisierten Angriffen die Identifikation deiner Tabellen. Bei bestehenden Seiten lässt sich das Präfix nachträglich ändern – allerdings mit Vorsicht: Hierfür müssen alle Tabellen umbenannt und die wp-config.php angepasst werden. Ohne Erfahrung kann das schiefgehen, daher empfiehlt sich der Einsatz eines Plugins (z. B. Brozzme DB Prefix), das diesen Vorgang unterstützt. Wichtig: Erstelle vorher ein vollständiges Backup der Datenbank. Ein individuelles Tabellenpräfix ist kein Allheilmittel, aber es schützt vor gewissen automatisierten Attacken, die blind auf die Standardnamen abzielen – nach dem Motto Security through Obscurity. Zusammen mit anderen Maßnahmen (z. B. einer Firewall oder einer WAF) ergibt sich so ein runderes Sicherheitsbild.
9. Benutzer mit ID 1 (Standard-Admin-Konto)
Problem: In jeder WordPress-Datenbank haben Benutzerkonten eine numerische ID. Die allererste angelegte Benutzer*in – in der Regel der Admin – erhält automatisch ID 1. Angreifer wissen das und können versuchen, darüber Rückschlüsse auf deinen Admin-Login zu ziehen. Viele Brute-Force-Skripte zielen standardmäßig auf den User mit ID 1, da dieser in 99 % der Fälle ein Administratorkonto ist. Zudem erlaubt WordPress in der Standardeinstellung eine einfache Benutzerauflistung über die URL: Ein Aufruf wie ?author=1
auf deiner Domain liefert oft direkt den Benutzernamen des Users mit der ID 1. Somit können Hacker ohne großen Aufwand herausfinden, wie dein Admin-Account heißt – selbst wenn du den Standardnamen „admin“ geändert hast. Die Existenz eines Administrator-Accounts mit ID 1 macht ihre Arbeit also deutlich leichter.
Lösung: Vermeide einen Admin-User mit der ID 1. Wenn du WordPress neu installierst, lege am besten zunächst einen Dummy-Benutzer an oder ändere die Erstellungsreihenfolge so, dass das Hauptadmin-Konto nicht die erste ID bekommt. Bei bestehenden Seiten kannst du folgendes tun: Erstelle einen zweiten Administrator-Account und übertrage alle Inhalte von User 1 auf diesen neuen Account. Anschließend lösche den Benutzer mit ID 1 (der alte Admin). Damit vergibst du keine ID 1 neu – diese ID bleibt in der Datenbank ungenutzt. Effekt: Automatisierte Angriffe, die stumpf Benutzer 1 attackieren, laufen ins Leere. Beachte jedoch, dass auch andere Methoden (wie oben erwähnt ?author=2
usw.) Benutzernamen herausfinden können. Dennoch erschwert das Entfernen des Standard-Admins die gängigsten Angriffsskripte erheblich. Kombiniere dies unbedingt mit starken Passwörtern und idealerweise Zwei-Faktor-Authentifizierung, um Admin-Logins generell abzusichern.
10. Keine Zwei-Faktor-Authentifizierung (2FA)
Problem: Der Login-Bereich ist die am häufigsten attackierte Stelle einer WordPress-Seite. Ohne Zwei-Faktor-Authentifizierung genügt ein geleaktes oder schwaches Passwort, um vollen Zugriff zu erlangen. Gerade Brute-Force-Angriffe und Credential-Stuffing (das massenhafte Ausprobieren geklauter Zugangsdaten) haben leichtes Spiel, wenn nur der Faktor Passwort zählt. Viele Admins vertrauen allein auf komplexe Passwörter – doch sollte dieses eine Sicherheitsnetz reißen, steht der Angreifer sofort im Backend. Die Erfahrung zeigt: Konten ohne 2FA sind ein Haupteinfallstor für Angriffe, da Passwörter öfter kompromittiert werden, als man denkt.
Lösung: Aktiviere Zwei-Faktor-Authentifizierung für alle Admin-Logins. 2FA verlangt neben dem Passwort einen zweiten Nachweis, z. B. einen zeitbasierten Code auf dem Smartphone. Selbst wenn das Passwort gestohlen wird, bleibt der Account so für Fremde gesperrt. Für WordPress gibt es zahlreiche kostenlose Plugins, etwa Google Authenticator oder WP 2FA, die sich leicht einrichten lassen. Nach der Installation koppelt jeder User sein Konto mit einer Authenticator-App (wie Google Authenticator, Authy oder ähnlichen). Fortan ist beim Login der sechsstellige Code aus der App einzugeben, zusätzlich zum Passwort. Dieser Schritt erhöht die Sicherheit enorm – Passwort-Diebstahl oder -eraten allein reichen dann nicht mehr aus, um einzubrechen. Richte 2FA zumindest für alle Administratoren und Benutzer mit hohen Rechten ein. Der geringe Mehraufwand beim Login ist ein kleiner Preis für den massiven Gewinn an Sicherheit.
Fazit
Sicherheit in WordPress besteht nicht nur aus Technik, sondern vor allem aus konsequenter Wartung und den richtigen Einstellungen. Viele Angriffe scheitern bereits, wenn bekannte Basics beherzigt werden: Halte deine Installation aktuell, nutze starke Zugangsdaten, schränke unnötige Funktionen ein und überwache deine Seite. Die hier vorgestellten zehn Fehler gehören zu den häufigsten Ursachen für erfolgreiche Hacks – doch mit den genannten Gegenmaßnahmen kannst du das Risiko drastisch senken. Investiere ein wenig Zeit in diese Optimierungen, denn sie schützen nicht nur deine Website, sondern auch deine Besucher und dein Geschäft. Sollte doch einmal etwas passieren, bist du mit Backups und zusätzlichen Schutzebenen gewappnet und kannst schnell reagieren.
Zum Abschluss ein Tipp: Nutze die angebotenen Sicherheits-Plugins oder -Services, die dich bei diesen Aufgaben unterstützen – viele Probleme lassen sich so mit wenigen Klicks präventiv lösen.
Das Plugin zeigt dir automatisch, welche dieser Fehler deine Seite betreffen – kostenlos: wp-security-check.de .