Wenn eine WordPress-Website gehackt wird, lautet die erste Frage fast immer: Wer wollte uns etwas? Die Antwort ist in den meisten Fällen: niemand.
Angriffe auf WordPress laufen automatisiert. Ein Bot kennt Ihr Unternehmen nicht. Er kennt eine Liste bekannter Sicherheitslücken und sucht Websites, auf denen eine davon noch offen steht. Ihre Branche, Ihre Größe, Ihr Umsatz spielen dabei keine Rolle. Es zählt genau eine Eigenschaft: ob die Lücke bei Ihnen geschlossen ist.
Das ist die unangenehme Nachricht und zugleich die beruhigende. Wo niemand gezielt vorgeht, braucht es auch keine besondere Abwehr — es braucht Routine. Dieser Artikel beschreibt, wo die Lücken tatsächlich entstehen, welche fünf Maßnahmen daran wirklich etwas ändern und welche verbreiteten Ratschläge wenig bringen.
Wo die Lücken tatsächlich entstehen
Nicht Ihr Passwort — Ihre Plugins
Der Jahresbericht von Patchstack zählt für 2025 11.334 neue Schwachstellen im WordPress-Ökosystem, 42 Prozent mehr als im Vorjahr. Entscheidend ist aber nicht die Gesamtzahl, sondern wo diese Lücken sitzen:
| Wo | Anteil |
|---|---|
| Plugins | 91 % |
| Themes | 9 % |
| WordPress-Core | 6 Schwachstellen im ganzen Jahr |
Sechs gegen über elftausend. WordPress selbst ist nicht das Problem. Das Problem ist die Software, die Sie zusätzlich installiert haben — das Formular-Plugin, der Slider, das Backup-Tool, der Page Builder, das Plugin für die Preistabelle, das vor drei Jahren einmal gebraucht wurde.
Daraus folgt eine unbequeme Regel: Jedes Plugin ist eine Entscheidung mit Folgekosten. Nicht nur die Lizenz, sondern die Verpflichtung, es dauerhaft aktuell zu halten — oder es zu entfernen.
Das Zeitfenster zwischen Lücke und Patch
Die Zahl aus demselben Bericht, die am wenigsten bekannt ist und am meisten erklärt: Bei 46 Prozent der veröffentlichten Schwachstellen lag zum Zeitpunkt der Veröffentlichung noch kein Patch vor.
Fast die Hälfte. Das heißt: Die Lücke ist öffentlich bekannt, Angreifer kennen sie und beginnen zu scannen — aber es gibt noch kein Update, das Sie einspielen könnten. Wer Sicherheit mit „Updates machen“ gleichsetzt, hat für diese Situation keine Antwort.
Genau deshalb reicht die Standardempfehlung „halten Sie alles aktuell“ nicht aus. Sie ist richtig, aber unvollständig. Was in diesem Zeitfenster hilft, steht weiter unten.
Warum niemand Sie persönlich angreift
Ein Bot arbeitet eine Liste ab. Er ruft Adressen auf, prüft, welche Version welches Plugins antwortet, und wenn eine bekannte Lücke passt, versucht er sie. Das kostet ihn Sekundenbruchteile und skaliert auf Millionen von Websites.
Deshalb hilft es auch nichts, klein und unauffällig zu sein. Die Website eines Handwerksbetriebs mit vierzig Besuchern am Tag wird genauso gescannt wie ein Konzernauftritt. Und sie ist für den Angreifer sogar attraktiver: ein gekaperter Server, der Spam versendet oder Schadsoftware verteilt, fällt dort länger nicht auf.
Was ein Vorfall nach sich zieht
Die Vorstellung ist meist: Die Website ist weg, man spielt ein Backup ein, fertig. Das ist der angenehmste Fall. Die anderen Folgen treffen häufiger und dauern länger.
Google markiert die Seite als schädlich. Wird Schadsoftware ausgeliefert, nimmt Google die Adresse in seine Warnliste auf. Besucher sehen dann statt Ihrer Startseite eine rote Warnseite. Das Entfernen der Markierung passiert nicht automatisch nach der Bereinigung — es muss beantragt und geprüft werden, und das dauert.
Ihre E-Mails kommen nicht mehr an. Ein gekaperter Webserver wird gern zum Spam-Versand genutzt. Die Folge: Ihre Domain landet auf Blacklists. Und dann erreicht nicht nur der Spam niemanden mehr, sondern auch Ihr Angebot an den Kunden, der gestern angefragt hat. Diesen Zusammenhang sehen die wenigsten kommen, und er hält am längsten an.
Es kann eine Meldepflicht entstehen. Sobald personenbezogene Daten betroffen sein könnten — und ein Kontaktformular speichert personenbezogene Daten — greift Art. 33 DSGVO: Der Verantwortliche meldet die Verletzung der zuständigen Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt wurde. Ausgenommen sind Fälle, in denen voraussichtlich kein Risiko für die Rechte und Freiheiten natürlicher Personen entsteht.
Die 72 Stunden laufen ab Kenntnis. Wer nicht überwacht, erlangt Kenntnis spät — und steht dann vor der Frage, seit wann der Zugriff bestand und welche Daten betroffen waren. Ohne Protokolle und ohne saubere Backup-Historie lässt sich das nicht beantworten.
Die Wiederherstellung ist Arbeit. Backup einspielen allein genügt nicht: Man muss wissen, von wann ein sauberer Stand existiert, wie der Zugriff erfolgte und ob die Lücke danach geschlossen ist. Sonst ist die Website in drei Tagen wieder kompromittiert — über denselben Weg.
Hinweis: Wir sind keine Rechtsanwälte und leisten keine Rechtsberatung. Wir beschreiben hier die technische Seite. Ob und wie in Ihrem konkreten Fall zu melden ist, klären Sie mit einem Anwalt oder Ihrem Datenschutzbeauftragten.
Fünf Maßnahmen, die wirklich etwas ändern
1. Updates wöchentlich — und danach prüfen
Der Abstand zwischen „Lücke bekannt“ und „Lücke bei Ihnen geschlossen“ ist das Zeitfenster, in dem Angriffe funktionieren. Jede Woche, die ein Update liegenbleibt, verlängert es.
Entscheidend ist der zweite Teil: prüfen, ob danach noch alles funktioniert. Ein Update, das das Kontaktformular zerlegt, ist kein Sicherheitsgewinn, sondern ein stiller Umsatzausfall. Deshalb gehört zur Routine eine Staging-Umgebung für die riskanten Fälle und eine Kontrolle nach jedem Durchgang.
Wir aktualisieren wöchentlich, in allen Paketen, und prüfen nach jedem Update.
2. Virtual Patching für das Zeitfenster
Hier liegt die Maßnahme, die in den üblichen Checklisten fehlt — und die Antwort auf die 46 Prozent von oben.
Wenn eine Lücke veröffentlicht ist, aber der Hersteller noch kein Update geliefert hat, haben Sie drei Möglichkeiten: das Plugin deaktivieren und auf die Funktion verzichten, abwarten und hoffen, oder die Lücke auf Serverebene blockieren, bevor der Aufruf überhaupt bei WordPress ankommt. Das letzte heißt Virtual Patching.
Wir setzen dafür Patchstack ein, und das ist eine bewusste Entscheidung, keine Gewohnheit. Patchstack pflegt eine eigene Schwachstellen-Datenbank und liefert Schutzregeln oft, bevor ein offizielles Update existiert. Damit deckt das Werkzeug genau den Zeitraum ab, in dem reine Update-Routine nichts ausrichten kann.
Wer stattdessen ein Plugin einsetzt, das in erster Linie scannt und meldet, bekommt eine E-Mail — und steht vor demselben Problem wie vorher.
3. Backups, die getestet sind
Fast jedes Hosting wirbt mit Backups. Drei Fragen entscheiden, ob sie im Ernstfall tragen:
- Wie weit reichen sie zurück? Ein Zugriff, der drei Wochen unbemerkt bestand, lässt sich mit einem Sieben-Tage-Backup nicht mehr sauber zurücksetzen. Im Starter bewahren wir 30 Tage auf, im Business 50.
- Wo liegen sie? Liegt die Sicherung auf demselben Server wie die Website, ist sie bei einem kompromittierten Server mitbetroffen. Im Business laufen die Sicherungen über zwei voneinander unabhängige Systeme bei zwei Anbietern in zwei Ländern, verschlüsselt und getrennt von der Website.
- Wurde die Rücksicherung je durchgespielt? Ein Backup, das nie zurückgespielt wurde, ist eine Annahme, kein Sicherheitsnetz.
4. Eine PHP-Version, die noch Updates bekommt
PHP ist die Sprache, in der WordPress läuft. Jede Version hat ein festes Ende, danach bekommt sie keine Sicherheitsupdates mehr — und das betrifft nicht ein Plugin, sondern das Fundament der gesamten Website.
Der Stand laut offizieller PHP-Lebenszyklus-Übersicht:
| Version | Status |
|---|---|
| 8.0 und älter | End of Life — keine Sicherheitsupdates mehr |
| 8.1 | End of Life |
| 8.2 | nur noch Sicherheitsupdates, bis 31.12.2026 |
| 8.3 | nur noch Sicherheitsupdates, bis 31.12.2027 |
| 8.4 | aktiv unterstützt |
Viele ältere WordPress-Installationen laufen noch auf 7.4 oder 8.0. Das ist still und unauffällig — bis es das nicht mehr ist. Prüfen lässt sich das in WordPress unter Werkzeuge → Website-Zustand → Bericht.
5. Zugänge: Wer hat eigentlich Administrator-Rechte?
Die Frage lohnt sich einmal jährlich. In gewachsenen Installationen finden sich regelmäßig: die Agentur von vor drei Jahren, ein ehemaliger Praktikant, ein Dienstleister für eine einmalige Aufgabe, und ein Konto namens „admin“, dessen Passwort niemand mehr kennt.
Jeder dieser Zugänge ist ein möglicher Einstieg — nicht weil die Person etwas vorhätte, sondern weil ihr Rechner, ihr Passwortmanager oder ihr E-Mail-Konto nicht mehr in Ihrer Kontrolle ist. Nicht mehr benötigte Konten löschen, nicht nur die Rolle herabstufen. Und Zwei-Faktor-Authentifizierung für alle, die wirklich Administrator bleiben.
Was davon in welchem Umfang zur laufenden Betreuung gehört, haben wir in unserem Artikel zum WordPress-Wartungsvertrag aufgeschlüsselt.
Was oft empfohlen wird und wenig bringt
Sicherheits-Checklisten im Netz sind lang. Das ist ihr Problem: Sie stellen zwanzig Maßnahmen nebeneinander, als wären sie gleich viel wert. Vier davon tauchen fast immer auf und verdienen eine Einordnung.
Die Login-Adresse verstecken. /wp-admin auf eine geheime Adresse umzulegen fühlt sich wirksam an. Gegen automatisierte Angriffe auf Plugin-Lücken hilft es nicht — die laufen über ganz andere Adressen und interessieren sich für Ihr Login-Formular überhaupt nicht. Gegen simples Passwortraten hilft es ein wenig, aber das war nach den Zahlen oben nie der Hauptweg. Dafür bricht es regelmäßig Werkzeuge, die den Standardpfad erwarten.
Alles-in-einem-Sicherheitsplugins. Ein Plugin mit vierzig Funktionen, von der Firewall bis zum Dateiscanner, wirkt gründlich. Zwei Einwände: Es ist selbst ein Plugin — also selbst Teil der 91 Prozent und selbst zu aktualisieren. Und die meisten Funktionen laufen bei jedem Seitenaufruf mit und kosten Ladezeit. Wir setzen lieber ein schlankes Werkzeug mit einer klaren Aufgabe ein als eine Suite, die alles ein bisschen macht.
Scanner, die nur melden. Ein Dienst, der Ihnen eine E-Mail schickt, sobald ein Plugin verwundbar ist, informiert Sie — mehr nicht. Die Frage ist immer, was danach passiert und wer es tut. Ohne eine Person, die den Befund abarbeitet, verwandelt sich der Scanner in einen Ordner ungelesener E-Mails.
„Nehmen Sie lieber einen Baukasten, WordPress ist unsicher.“ Die Zahlen sagen etwas anderes: sechs Schwachstellen im Core gegen über elftausend im Ökosystem. Unsicher ist nicht WordPress, unsicher ist eine ungepflegte Installation mit zwanzig Plugins, von denen die Hälfte vergessen wurde. Das ist ein Pflegeproblem, kein Plattformproblem.
Und eine Einschränkung, die wir uns selbst auferlegen: Hundertprozentige Sicherheit kann niemand zusagen — wir auch nicht. Was sich erreichen lässt, ist ein kleines Zeitfenster, ein funktionierendes Backup und jemand, der merkt, wenn etwas passiert. Wer Ihnen mehr verspricht, verkauft Ihnen ein Gefühl.
Wenn Sie es selbst machen möchten
Das ist machbar, wenn im Unternehmen jemand die Zeit und die Routine hat. Ehrlich geplant gehört dazu:
- Ein fester Wochentermin für Updates. Nicht „wenn Zeit ist“ — ein Termin im Kalender, mit Vertretung für Urlaub und Krankheit. Rechnen Sie pro Website mit etwa einer halben Stunde, solange nichts schiefgeht.
- Ein Hosting mit Staging-Umgebung. Ohne Staging testen Sie Updates auf der Live-Website.
- Ein Backup-Dienst mit externem Speicherort, getrennt vom Webserver, mit mehr als sieben Tagen Historie.
- Ein Werkzeug für Schwachstellen, das nicht nur meldet, sondern blockiert.
- Ein jährlicher Blick auf die Benutzerliste und auf die PHP-Version.
Der Posten, der am häufigsten unterschätzt wird, ist nicht die Zeit, sondern die Vertretung. Updates verschieben sich selten aus Nachlässigkeit — sie verschieben sich wegen Urlaub, Krankheit oder eines großen Projekts. Nach drei verschobenen Wochen ist der Abstand zwischen installierter und aktueller Version so groß, dass Updates selbst riskant werden. Und dann bleiben sie erst recht liegen.
Wenn Sie zunächst nur wissen möchten, wie Ihre Website aktuell dasteht: Wir haben beschrieben, wie Sie sie in sechs Bereichen selbst prüfen — ohne Werkzeuge, in einer halben Stunde.
Wenn es schon passiert ist
Die Reihenfolge entscheidet. Der häufigste Fehler ist, sofort ein Backup einzuspielen — damit ist die Website kurz wieder da, die Lücke aber unverändert offen, und die Spuren, die zeigen würden, was passiert ist, sind überschrieben.
- Hoster informieren. Er sieht Serverprotokolle, die Sie nicht sehen, und muss ohnehin wissen, dass auf seinem System etwas läuft.
- Website vom Netz nehmen, solange Schadsoftware ausgeliefert werden könnte. Eine kurze Wartungsseite ist besser als eine Google-Warnung, die Sie wochenlang begleitet.
- Zugänge zurücksetzen — WordPress-Benutzer, FTP/SFTP, Datenbank, Hosting-Konto. Von einem Gerät aus, bei dem Sie sicher sind, dass es sauber ist.
- Umfang feststellen, bevor Sie wiederherstellen. Seit wann besteht der Zugriff? Welcher Backup-Stand ist nachweislich sauber? Wurden personenbezogene Daten berührt? Von dieser Antwort hängt die Frist aus Art. 33 DSGVO ab — und sie läuft bereits.
- Ursache schließen, dann zurückspielen. In dieser Reihenfolge, nicht umgekehrt.
- Nachbereiten: Google-Warnung aufheben lassen, Blacklist-Einträge prüfen, E-Mail-Zustellbarkeit testen.
Das BSI hat zu diesem Ablauf eine eigene Handreichung veröffentlicht: Prävention und Erste Hilfe bei Webseiten-Kompromittierung oder Defacement. Wenn Sie gerade mittendrin stecken, ist das der nüchternste Leitfaden, den es auf Deutsch gibt.
Und der unangenehme Teil: Punkt 4 lässt sich ohne Protokolle und ohne saubere Backup-Historie schlicht nicht beantworten. Deshalb steht die Vorbereitung weiter oben in diesem Artikel — sie entscheidet darüber, ob dieser Abschnitt für Sie überhaupt bearbeitbar ist.
Wenn Sie es abgeben möchten
Wir arbeiten auch im Auftrag von Agenturen und sehen deshalb regelmäßig, in welchem Zustand Websites übergeben werden. Das Muster ist fast immer dasselbe: technisch sauber gebaut, dann ein Jahr unangetastet — weil im Projektpreis keine Betreuung vorgesehen war und niemand zuständig blieb. Nicht aus Nachlässigkeit, sondern weil Zuständigkeit nie vereinbart wurde.
Was bei uns zur Sicherheit gehört, in jedem Paket ab 190 € im Monat (netto, zzgl. MwSt.):
- Wöchentliche Updates von Core, Plugins und Themes, mit Kontrolle danach
- Firewall-Schutz und laufende Überwachung auf Schwachstellen
- Wöchentliche Backups, 30 Tage Aufbewahrung — im Business täglich, 50 Tage, über zwei unabhängige Systeme bei zwei Anbietern in zwei Ländern
- 24/7 Uptime-Monitoring: Die Benachrichtigung kommt bei uns an, nicht beim Kunden
- Ein monatlicher Bericht ohne Fachjargon, mit Sicherheits-Status und abgewehrten Angriffen
- Ein fester Ansprechpartner, der Ihre Website kennt — in der Regel antworten wir innerhalb eines Werktages
Der vollständige Leistungsvergleich steht auf der Seite Pakete & Preise. Wie sich diese Preise zusammensetzen und welche Posten dahinterstecken, haben wir in einem eigenen Artikel offen durchgerechnet: Was kostet WordPress-Wartung?
Erst einmal wissen, wo Sie stehen
Wenn Sie nicht sicher sind, wie es um Ihre Website steht, fangen Sie nicht mit einem Vertrag an, sondern mit einem Befund. Unser kostenloser Website-Check prüft sechs Bereiche — Gesamteindruck und Wirkung, Performance, Sicherheit, SEO, Mobile sowie Recht und DSGVO. Sie erhalten innerhalb von 48 Stunden ein PDF. Ohne Telefonat, ohne Verkaufsgespräch, ohne Zugangsdaten.
Wenn Sie Ihre Situation lieber direkt besprechen möchten, schreiben Sie uns über das Kontaktformular oder rufen Sie an: +49 157 54071854.
Häufige Fragen
Wie erkenne ich, ob meine WordPress-Website gehackt wurde?
Selten daran, dass die Seite kaputt aussieht — Angreifer haben kein Interesse daran, aufzufallen. Typische Anzeichen: unbekannte Benutzerkonten in der Benutzerliste, Weiterleitungen auf fremde Seiten (oft nur vom Smartphone oder nur über Google-Treffer), eine Google-Warnung in den Suchergebnissen, Spam-Beschwerden über Ihre Domain, plötzlich stark gestiegene Serverlast. Ein erster Blick: Werkzeuge → Website-Zustand → Bericht, und die Benutzerliste.
Reicht ein Sicherheits-Plugin aus?
Nein, aus zwei Gründen. Erstens ist ein Plugin selbst Teil der 91 Prozent — es muss ebenfalls aktuell gehalten werden. Zweitens löst Software nur den technischen Teil. Die Fragen „Wurde das Update eingespielt?“, „Funktioniert die Website danach noch?“ und „Wer reagiert auf die Meldung?“ beantwortet kein Plugin. Werkzeug und Zuständigkeit sind zwei verschiedene Dinge.
Wie oft müssen WordPress-Updates gemacht werden?
Eine feste Pflicht gibt es nicht. Praktisch entscheidet der Abstand zwischen Veröffentlichung einer Lücke und Ihrem Update darüber, ob ein Angriff funktioniert. Quartalsweise ist in diesem Rhythmus zu langsam. Wir machen es wöchentlich.
Mein Hoster hat eine Firewall — reicht das?
Die Firewall des Hosters arbeitet auf Netzwerkebene: Sie wehrt Überlastungsangriffe ab und filtert offensichtlich bösartigen Verkehr. Eine Anfrage, die aussieht wie ein normaler Seitenaufruf, aber eine bekannte Lücke in einem bestimmten Plugin ausnutzt, sieht sie nicht als Angriff — dafür müsste sie wissen, welche Plugins in welcher Version bei Ihnen laufen. Genau das ist die Aufgabe einer WordPress-spezifischen Schutzschicht. Beides zusammen ergibt Sinn, eines ersetzt das andere nicht.
Wir verkaufen nichts online und haben kaum Besucher. Betrifft uns das trotzdem?
Ja. Für den Angreifer ist Ihre Website kein Ziel, sondern eine Ressource: ein Server, von dem sich Spam versenden oder Schadsoftware verteilen lässt. Wenig Besucher sind dabei eher ein Vorteil für ihn, weil es länger niemandem auffällt. Und sobald ein Kontaktformular existiert, verarbeiten Sie personenbezogene Daten — damit greifen die technischen Anforderungen aus Art. 32 DSGVO unabhängig von Ihrer Besucherzahl.
Können Sie Sicherheit garantieren?
Nein, und wir würden jedem misstrauen, der das zusagt. Was wir zusagen können: wöchentliche Updates mit Kontrolle, Schutz auch in der Phase, in der es noch kein Update gibt, getestete Backups mit nachvollziehbarer Historie, Überwachung rund um die Uhr und einen Ansprechpartner, der im Ernstfall erreichbar ist.
Quellen
- Patchstack: State of WordPress Security in 2026 — 11.334 neue Schwachstellen im Jahr 2025, 42 Prozent mehr als im Vorjahr, 91 Prozent davon in Plugins, 9 Prozent in Themes, 6 im WordPress-Core; bei 46 Prozent lag zum Zeitpunkt der Veröffentlichung kein Patch vor.
- PHP: Supported Versions — Lebenszyklus der PHP-Versionen mit den Enddaten für aktive Unterstützung und Sicherheitsupdates.
- Art. 32 DSGVO — Sicherheit der Verarbeitung — angemessene technische und organisatorische Maßnahmen nach dem Stand der Technik, einschließlich rascher Wiederherstellbarkeit der Daten.
- Art. 33 DSGVO — Meldung von Verletzungen des Schutzes personenbezogener Daten an die Aufsichtsbehörde — Meldung unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden, außer wenn voraussichtlich kein Risiko für die Rechte und Freiheiten natürlicher Personen entsteht.
- BSI: Prävention und Erste Hilfe bei Webseiten-Kompromittierung oder Defacement — Handreichung des Bundesamts für Sicherheit in der Informationstechnik.