WordPress absichern – die Gegenseite hat nämlich auch KI

Seit Jahren sehe ich Artikel zum Thema Sicherheit mit den krudesten, meist anderswo kopierten „Tipps“. Häufig in Listenform, als ob es nur 10 Wege gibt, WordPress abzusichern.

Was hilft denn wirklich gegen einen Hack?
Wir schauen uns einen konkreten Fall an: Ein Plugin hat eine Sicherheitslücke.
Wie sind die Missetäter vorgegangen?
Welcher Schutz hätte wirklich geholfen?
Und wie habe ich das Ganze bereinigt?

Mythen widerlegen. Lösungen besser bewerten können. Ruhiger schlafen. 😉

Transcript

1. WordPress absichern - die Gegenseite hat nämlich auch KI WordCamp Mannheim 2025 Torsten Landsiedel @zodiac1978
2. 1. Was für (unsinnige) Tipps werden immer wieder geteilt? 2. Myth Busting! 3. Exkurs: State of WordPress Security in 2026 (Patchstack) 4. Konkreter Fall mit einem Kunden 5. Was hätte wirklich geholfen? Was ist das heute für ein Talk?
3. Sicherheitsverständnis (Symbolbild)
4. Die besten Tipps für Sicherheit?
5. • Gute Passwörter • WordPress-Version verstecken • Login verstecken • Zwei-Faktor-Authentifizierung • https statt http • wp-config.php eine Ebene höher Hier meine Liste an (auch schlechten!) Tipps:
6. • Datenbank-Präfix ändern • Salt Keys in wp-config.php nutzen • Loginschutz via .htaccess • wp-config.php / .htaccess absichern • Directory Listing deaktivieren • File Editor deaktivieren (DISALLOW_FILE_EDIT) Diese Tipps habe ich so tatsächlich gesehen …
7. • /wp-includes via .htaccess absichern (offizielle Hardening-Seite) • Ungenutzte User löschen (oder zu Abonnenten machen) • Jedem Benutzer nur so viele Rechte wie nötig • Inaktive Plugins/Themes löschen • Permissions (755 Ordner/644 Dateien/wp-config.php so wenig wie möglich) Oder diese …
8. • Backups • Anmeldeversuche beschränken • Security Header • XML-RPC schließen • REST API schließen • PHP in /uploads nicht erlauben Und noch mehr …
9. • Login Fehler nicht mehr Grund verraten lassen • readme.html / license.txt verstecken • Anmeldenamen verstecken (nicht “admin” nutzen …) • Updaten, Updaten, Updaten Und natürlich die großen Geschütze: Firewalls Wordfence, Patchstack, Ninja Firewall, Sucuri, etc. Langsam wird es lustig …
10. Wir werden auf alle diese Punkte am Ende wieder zurückkommen. Was hätte wirklich geholfen? Was ist kompletter Unfug? Und was hilft - aber nur an anderen Stellen? Was hilft wirklich gegen einen Hack?
11. Myth Busting
12. • Viele dieser Tipps waren in der Vergangenheit mal richtig • Viele dieser Tipps erklären die Konsequenzen nicht ausreichend • Viele dieser Tipps sind nicht überall möglich (Shared Hosting) • Viele dieser Tipps haben nur einen begrenzten Nutzen Hartnäckige Legenden
13. • Multicall-Methode in XML-RPC - bei Fehler im 1. Call, wird der Rest verworfen (schließen deaktiviert Pingbacks - gewusst?) • license.txt / readme.html enthielten Copyright inkl. Jahr, was Rückschlüsse auf die Version ermöglichte (fraglicher Nutzen und die Jahresangabe wurde inzwischen entfernt) • „admin“ ist seit WordPress 3.0 (vom 17. Juni 2010) nicht mehr standardmäßig vorgegeben Veraltete Information
14. • Directory Listing AN • Error Reporting AN Wenn es aktiviert ist und nicht durch dich konfigurierbar, dann wechsele den Hoster! Sollte nicht nötig sein, wenn doch … 󰝊
15. • Datenbank-Präfix ist dafür gedacht, mehrere Installationen in einer Datenbank unterzubringen - kein Sicherheitsfeature! • Salt Keys sollten eh immer gesetzt sein. Ein Ändern invalidiert sämtliche Login-Cookies: Erst nach dem Hack relevant. Feature falsch verstanden …
16. • WordPress-Version verstecken • Anmeldenamen verstecken • Login-Fehler leeren oder auf allgemeine Meldung stellen - Wert wird gelöscht, wenn nicht zutreffend. UX-Rückschritt für echte Nutzer. Völliger Unsinn. Wirklich.
17. Die anderen Tipps haben einen Sicherheitseffekt. Aber helfen sie bei einer echten Sicherheitslücke? Das schauen wir uns später an … Was ist mit dem Rest?
18. State of WordPress Security
19. Die meisten Lücken in Plugins https://patchstack.com/whitepaper/state-of-wordpress-security-in-2026/
20. Paid Plugins schwerer betroffen
21. Plakativer ausgedrückt
22. Und es geht immer schneller …
23. Hefte raus, Klassenarbeit!
24. Broken Access Control Fehlende oder fehlerhafte Zugriffskontrollen ermöglichen den Zugriff auf Funktionen oder Daten ohne ausreichende Berechtigung. Privilege Escalation Ein Angreifer erweitert seine Berechtigungen und erhält Zugriff auf Funktionen oder Daten, die eigentlich nicht erlaubt sind. Local File Inclusion (LFI) Eine Anwendung lädt lokale Dateien anhand von Benutzereingaben und ermöglicht so das Auslesen sensibler Dateien oder weiteren Missbrauch. Lernen wir ein paar Fachbegriffe
25. SQL Injection Eingeschleuster SQL-Code manipuliert Datenbankabfragen und ermöglicht das Auslesen, Verändern oder Löschen von Daten. Broken Authentication Schwachstellen im Anmeldeprozess erlauben die Übernahme von Benutzerkonten oder das Umgehen der Authentifizierung. Arbitrary File Upload Ein Angreifer kann beliebige Dateien hochladen, beispielsweise Schadcode, der anschließend auf dem Server ausgeführt wird. Lernen wir ein paar Fachbegriffe
26. Lernen wir ein paar Fachbegriffe Remote Code Execution (RCE) Ein Angreifer führt eigenen Code auf dem Zielsystem aus und kann den Server vollständig kompromittieren. Cross-Site Scripting (XSS) Schadhaftes JavaScript wird in Webseiten eingeschleust und im Browser anderer Nutzer ausgeführt. Cross-Site Request Forgery (CSRF) Ein angemeldeter Nutzer wird unbemerkt dazu gebracht, unerwünschte Aktionen in seinem Namen auszuführen.
27. Broken Access Control: Subscriber kann Admin-Funktionen aufrufen. Privilege Escalation: Subscriber wird durch Plugin-Fehler zum Administrator. Local File Inclusion: wp-config.php oder /etc/passwd werden ausgelesen. SQL Injection: Alle WordPress-Benutzer oder Passwort-Hashes werden aus der Datenbank ausgelesen. Broken Authentication: Schwache Login- oder Session-Verwaltung führt zur Kontoübernahme. Ähh… was heißt das konkret?
28. Ähh… was heißt das konkret? Arbitrary File Upload: Upload einer PHP-Webshell über ein verwundbares Plugin. Remote Code Execution: Ausführung beliebiger PHP-Befehle auf dem Webserver. XSS: JavaScript stiehlt Administrator-Cookies oder erzeugt neue Admin-Benutzer. CSRF: Ein eingeloggter Administrator wird zum Ändern von Einstellungen oder Installieren eines Plugins verleitet.
29. Nochmal kurz zurück zum Survey:
30. Infizierte Website - 😱
31. Mein konkreter Fall: Lücke im Plugin Im Frühjahr 2026 wird eine Lücke im Plugin “Ninja Forms File Uploads” öffentlich. Da nicht alle das kostenpflichtige Plugin zeitnah aktualisiert haben, wurde die Lücke sofort ausgenutzt. Auch bei meinem Kunden … In seinem Konto sind leider 50+ WordPress-Installationen.
32. Spielen wir ein Spiel … Wie viele Anläufe werden benötigt, um diese Lücke(n) zu schließen?
33. Hier war die Welt noch in Ordnung …
34. Versuch #1
35. Versuch #2
36. Versuch #3
37. Versuch #4
38. Versuch #5
39. Versuch #6
40. 6 Anläufe für Sicherheit Wer hat richtig getippt?
41. Wie schlimm ist es? Sehr.
42. Wirklich schlimm.
43. Katastrophal wäre passender.
44. • Eigenen Uploader hochgeladen • Webshell hochgeladen • Framework mit UI für Kontrolle • Unzählige Remote Code Execution Backdoors installiert • User erstellt und versteckt • Persistenz + Verteilung + Kontrolle • … Was haben die Hacker gemacht?
45. Was hätte geholfen?
46. • Gute Passwörter? NOPE • WordPress-Version verstecken? NOPE • Login verstecken? NOPE • Zwei-Faktor-Authentifizierung? NOPE • https statt http? NOPE • wp-config.php eine Ebene höher? NOPE Was hätte in diesem Fall geholfen?
47. • Datenbank-Präfix ändern NOPE • Salt Keys in wp-config.php nutzen NOPE • Loginschutz via .htaccess NOPE* • wp-config.php / htaccess absichern NOPE • Directory Listing deaktivieren NOPE • File Editor deaktivieren NOPE* Aber bestimmt irgendwas hier, oder?
48. • /wp-includes via .htaccess absichern NOPE* • Ungenutzte User löschen NOPE • Nur so viele Rechte wie nötig NOPE • Inaktive Plugins/Themes löschen NOPE • Permissions NOPE Und hier …
49. • Backups JEIN … • PHP in /uploads nicht erlauben NOPE* • Anmeldeversuche beschränken NOPE • Security Header NOPE • XML-RPC schließen NOPE • REST API schließen NOPE Oder hier?
50. • Login Fehler nicht mehr Grund verraten lassen NOPE • readme.html / license.txt verstecken NOPE • Anmeldenamen verstecken NOPE • Updaten, Updaten, Updaten JA • Web Application Firewall (WAF) VIELLEICHT Echte WAFs können hier helfen. Aber dazu müssen sie die Gefahr kennen. Und das ist ein Business-Modell. Langsam wird es lustig …
51. Bei einer so schweren Lücke hilft fast gar nichts. Früher updaten hätte wirklich geholfen und alles verhindert. Der Rest (*) dämmt nur den Schaden ein. Beschränkt die Orte, wo geschrieben oder danach zugegriffen werden kann. Bonustipp: Wenn möglich die Projekte in einzelne Konten trennen, um Cross Site Contamination zu verhindern. Was hätte geholfen?
52. Alles Unsinn?
53. Gute Passwörter, 2FA, Login verstecken, Anmeldeversuche begrenzen, .htaccess-Schutz auf wp-login.php, … Alle diese Punkte erhöhen die Sicherheit des Logins, sofern er denn der Angriffsvektor ist. Zusatzvorteil: Serverlast vermieden, serverbasierte Statistiken nicht vermüllt mit Bots Was hilft wo?
54. https sorgt für verschlüsselte Verbindungen - insbesondere beim Versand von Formularen. In einem offenen W-LAN kann mit den geeigneten Tools (Wireshark) der Traffic von Fremden ausgelesen werden. Bei http sind Passwörter (Login-Formular) oder sensible Informationen wie Gesundheitsdaten/personenbezogene Daten (Kontaktformulare) dann unverschlüsselt und somit als Text einsehbar! Was hilft wo?
55. wp-config.php eine Ebene höher - bringt das was? Das wird kontrovers diskutiert. Ist keine hinreiche Sicherheitsstrategie. Hat aber bei mir schon mehrfach geholfen eine (schlechte) Attacke scheitern zu lassen, weil der Standard-Ort angenommen wurde. Manche sagen so, andere so …
56. Das Gleiche gilt für das Datenbankpräfix. Schlechte Skripte nehmen den Standard “wp_” an und scheitern. Auch das ist keine hinreichende Sicherheit. Eher “Dummheit der Gegenseite” und das kann sich schnell ändern … Manche sagen so, andere so …
57. define( 'DISALLOW_FILE_EDIT', true ); In meinem Fall wurde eine eigene UI hochgeladen. Der WP-Editor war gar nicht nötig. Wenn er nicht genutzt wird, kann das deaktiviert werden. Aber auch hier: Das ist keine hinreichende Strategie und auch kein Grund mit Warnungen bombardiert zu werden … Manche sagen so, andere so …
58. Backups lassen mich ruhiger schlafen, weil ich weiß, dass die Wiederherstellung deutlich schneller geht als eine Bereinigung. Bei High Traffic, Shops, viel kommentierten Blogs, Foren, etc. ist das aber schon nicht mehr so einfach. Datenbank häufiger sichern als die Dateien ist eine gute Lösung. Backups = Sicherheit? Geht so.
59. Sind ein sehr guter Schutz gegen XSS-Attacken. Leider aufgrund schlecht programmierter Plugins, häufig in WordPress kaum richtig zu nutzen, ohne Kollateralschäden zu verursachen. Soweit möglich umsetzen ist aber eine gute Idee! Security Header
60. Prinzipiell gute Möglichkeit, da /uploads der einzige Ort ist, wo in WordPress gespeichert werden darf/sollte. Hätte in meinem Fall aber nur ein paar der Backdoors nicht erreichbar gemacht. Aber insgesamt nichts verhindert. Nur in Verbindung mit Web Application Firewall und anderen Maßnahmen wirklich hilfreich. Dann aber tatsächlich. PHP in /uploads nicht erlauben / / WAFs
61. → Updates zeitnah einspielen ist oberste Priorität → Gute, seriöse, aktiv betreute Plugins/Themes schränken die Risiken ein → Inaktive Plugins löschen → Geschlossene Plugins schnell erkennen und ersetzen → Eine echte Web Application Firewall hilft Fazit
62. → Entwicklungsumgebungen, Staging-Sites, alte Versionen nach Relaunch werden häufig vergessen und sind noch online (und verwundbar!) → WordPress zeigt geschlossene Plugins nicht im Backend an, ein Plugin kann das nachrüsten! → Notfallplan haben - was tun, wenn es passiert? Bonustipps!
63. Tatortreiniger?
64. → Scanner vom Hoster hat angeschlagen → Firewall (WAF) und Exploit Scanner haben noch mehr gefunden → Logfile-Analyse hat noch mehr offenbart → Via SSH-Zugang direkt auf dem Server noch mehr gefunden → Monitoring aller Dateiänderungen Wie habe ich das bereinigt?
65. Fragen?
66. Danke! Slack // X (Twitter) // Mastodon // Bluesky // WordPress.org // GitHub @zodiac1978