Eine WordPress-Seite ist nie fertig. Sie ist ein Versprechen, das du jede Woche neu einlösen musst.
Die meisten Hacks, die ich bei Grazer Unternehmen sehe, sind nichts Persönliches. Niemand sitzt nachts da und denkt sich: „Heute knacke ich diesen Friseur in der Sporgasse." Es sind Bots. Sie scannen das halbe Internet automatisiert nach derselben veralteten Plugin-Version und schlagen zu, wo sie sie finden. Dein Risiko ist keine Frage von Pech. Es ist eine Frage von Wartung.
Warum ausgerechnet WordPress
Über 40 % aller Websites laufen auf WordPress. Das macht es zum lohnendsten Ziel der Welt — ein einziger funktionierender Exploit lässt sich auf Millionen Seiten gleichzeitig anwenden. Und fast nie liegt die Lücke im WordPress-Kern selbst. Der ist solide gepflegt. Laut den Sicherheits-Reports von Patchstack stammt die überwältigende Mehrheit aller WordPress-Schwachstellen aus Plugins und Themes — nicht aus dem Core.
Das ist der entscheidende Punkt: Dein Risiko wächst mit jeder Erweiterung, die du installierst. Dieser eine Slider, das Kontaktformular-Plugin, das Theme aus dem Marktplatz — jedes davon ist Code von Dritten, der irgendwann eine Lücke bekommt. Jede Erweiterung ist eine Tür. Je mehr Türen, desto mehr musst du abschließen.
Wie so ein Hack tatsächlich abläuft
Damit es greifbar wird — so sieht der typische Ablauf aus, und kein Schritt davon braucht einen menschlichen Angreifer:
- Ein Bot crawlt deine Seite und liest die Version eines Plugins aus.
- Für diese Version existiert eine öffentlich bekannte Schwachstelle.
- Der Bot nutzt sie automatisiert aus und lädt Schadcode hoch.
- Deine Seite verteilt jetzt Spam, leitet Besucher auf Glücksspiel-Seiten um oder schürft Kryptowährung im Hintergrund — oft, ohne dass du sofort etwas merkst.
- Google erkennt das, wirft dich aus dem Index oder zeigt die rote Warnung „Diese Website könnte Ihren Computer schädigen". Dein Traffic stirbt über Nacht.
Vom verwundbaren Plugin bis zur Google-Sperre vergehen manchmal Stunden. Bis zum nächsten Mal, dass du selbst auf die Seite schaust, oft Tage.
Die 12 Schritte
1. Updates sind kein Vorschlag
Core, Plugins und Themes aktuell halten — automatisiert, nicht „wenn ich mal Zeit habe". Die meisten gehackten Seiten liefen auf einer Version, für die der Fix längst da war. Aktiviere Auto-Updates für alles, was du nicht manuell kontrollierst.
2. Schaff den „admin"-Benutzer ab
Wenn dein Login-Name admin ist, hat der Angreifer die Hälfte der Arbeit geschenkt bekommen — er muss nur noch das Passwort raten. Leg einen neuen Admin mit eigenem Namen an, übertrag die Inhalte, lösch den alten.
3. Starke Passwörter + Zwei-Faktor
Ein 20-Zeichen-Passwort aus dem Passwort-Manager, dazu 2FA per App. Das allein stoppt praktisch alle automatisierten Login-Angriffe, weil der Bot mit geratenen Passwörtern nicht mehr durchkommt.
4. Login-Versuche begrenzen
Ohne Limit darf ein Bot unendlich oft raten (Brute-Force). Ein Plugin wie Limit Login Attempts oder eine WAF-Regel sperrt nach wenigen Fehlversuchen die IP.
5. wp-config.php härten
Die wp-config.php ist das Herz deiner Installation. Zwei Dinge, die jeder setzen sollte — den Datei-Editor im Backend abschalten (sonst kann ein gekaperter Admin direkt Code schreiben) und frische Security-Keys verwenden:
// Datei-Editor im WP-Backend deaktivieren
define( 'DISALLOW_FILE_EDIT', true );
// Security-Keys neu generieren auf:
// https://api.wordpress.org/secret-key/1.1/salt/
define( 'AUTH_KEY', 'hier-langer-zufallswert' );
define( 'SECURE_AUTH_KEY', 'hier-langer-zufallswert' );
// ... die restlichen Keys ebenso ersetzen
6. Den Zugriff auf sensible Dateien sperren
wp-config.php, .htaccess und Debug-Logs gehen niemanden etwas an. Auf Apache-Servern blockst du den direkten Zugriff per .htaccess:
<files wp-config.php>
require all denied
</files>
7. Weniger Plugins = weniger Angriffsfläche
Jedes Plugin, das du nicht brauchst, ist ein Risiko ohne Gegenwert. Deaktivierte Plugins sind keine Lösung — gelöschte schon. Geh einmal im Quartal durch und miste aus. Und installiere nur, was gepflegt wird (letztes Update, Bewertungen, aktive Installationen prüfen).
8. XML-RPC schließen
xmlrpc.php braucht heute fast niemand mehr, aber Angreifer lieben sie für Brute-Force und DDoS. Wenn du sie nicht aktiv nutzt: deaktivieren.
9. HTTPS und Security-Header
SSL ist Pflicht, kein Bonus. Dazu gehören Header wie Strict-Transport-Security, X-Content-Type-Options und eine Content-Security-Policy — sie machen ganze Angriffsklassen (z. B. Cross-Site-Scripting) von vornherein unmöglich.
10. Datei- und Ordnerrechte
Verzeichnisse auf 755, Dateien auf 644, die wp-config.php enger (600). Kein Verzeichnis sollte für die Welt beschreibbar sein.
11. Eine Web Application Firewall
Eine WAF (z. B. über Cloudflare oder Wordfence) filtert bösartige Anfragen, bevor sie WordPress überhaupt erreichen. Das ist dein Vorhof — die meisten automatisierten Angriffe sterben hier, lange bevor sie an ein Plugin kommen.
12. Backups, die du auch zurückspielen kannst
Ein Backup, das du noch nie getestet hast, ist kein Backup, sondern eine Hoffnung. Automatische, externe Backups (nicht auf demselben Server) plus ein echter Wiederherstellungs-Test, einmal. Im Ernstfall zählt nicht, dass du ein Backup hast — sondern dass es funktioniert.
Was ein Hack dich wirklich kostet
Die Bereinigung ist das Wenigste. Teuer wird der Rest: Tage, an denen die Seite offline oder mit Google-Warnung unbesucht ist. Der Vertrauensverlust, wenn ein Stammkunde „Diese Seite könnte gehackt sein" liest. Der Ranking-Einbruch, weil Google dich aus dem Index geworfen hat — und der Wiederaufbau danach. Eine Stunde Prävention ist fast immer billiger als ein Tag Schadensbegrenzung.
Oder: das Problem an der Wurzel lösen
Lies die Liste oben nochmal. Das ist kein Projekt — das ist eine Daueraufgabe. Jede Woche Updates, jedes Quartal Plugin-Audit, ständig ein halbes Auge auf der nächsten Lücke. Für viele Unternehmen in Graz ist genau das der Punkt, an dem ich ehrlich frage: muss es WordPress sein?
WordPress hat seine Berechtigung — für Redaktionen mit täglichem Content, für Leute, die das Ökosystem bewusst wollen. Aber eine Website, die ich mit Custom-Code baue (Next.js, statisch ausgeliefert), hat schlicht keine dieser Türen. Kein Plugin-Ökosystem, das veralten kann. Kein Login-Panel, das im offenen Web auf Brute-Force wartet. Keine Datenbank, die bei jedem Seitenaufruf angefragt wird. Die halbe Liste oben wird damit gegenstandslos, weil es die Angriffsfläche gar nicht erst gibt.
Das ist kein Argument gegen WordPress. Es ist ein Argument dafür, ehrlich zu rechnen: Was kostet dich die Wartung über drei Jahre — an Geld, an Zeit, an dem mulmigen Gefühl, ob die letzte Lücke geschlossen ist? Manchmal ist die sicherste Plattform die, die du gar nicht erst absichern musst.
Eine Seite, die nichts hat, was man kapern kann, schläft ruhiger. Du auch.
