Zum Hauptinhalt springen

wp2shell: Die WordPress-Lücke, die Ihre Website ohne Passwort übernimmt

wp2shell: Die WordPress-Lücke, die Ihre Website ohne Passwort übernimmt

Stand: 31. Juli 2026

Am Freitagabend des 17. Juli 2026 veröffentlichte das WordPress-Projekt ein Notfall-Update. Kein reguläres Wartungs-Release, kein Feature-Update – ein Notfall. Einen Tag später gab das Bundesamt für Sicherheit in der Informationstechnik (BSI) eine offizielle Cyber-Sicherheitswarnung heraus, Warnstufe 3 von 4: Orange.

Der Grund trägt den Namen wp2shell. Es handelt sich um eine Verkettung zweier Schwachstellen im WordPress-Kern, die zusammen etwas ermöglichen, das es in dieser Form seit Jahren nicht gab: Ein Angreifer kann eine völlig normale WordPress-Website übernehmen – ohne Benutzername, ohne Passwort, ohne dass ein einziges Plugin installiert sein muss.

Eine blanke Standardinstallation genügt.

Wenn Sie eine WordPress-Website betreiben, sind das die drei Sätze, die für Sie zählen:

  1. Betroffen sind die Versionen 6.9.0 bis 6.9.4 sowie 7.0.0 bis 7.0.1.
  2. Die Lücke ist geschlossen in 6.9.5 und 7.0.2 – prüfen Sie jetzt, welche Version bei Ihnen läuft.
  3. Ein Update allein reicht nicht, wenn Sie in den Tagen davor bereits angegriffen wurden.

Genau um diesen dritten Punkt geht es in diesem Artikel.

Auf einen Blick: Bin ich betroffen?

WordPress-Version Status
6.8.5 und älter

Von dieser Angriffskette nicht betroffen

6.9.0 – 6.9.4

Betroffen – sofort handeln

6.9.5 und neuer (6.9er-Zweig) Geschlossen
7.0.0 – 7.0.1

Betroffen – sofort handeln

7.0.2 und neuer (7.0er-Zweig)

Geschlossen

So prüfen Sie Ihre Version in 30 Sekunden: Melden Sie sich im WordPress-Backend an. Unten rechts im Dashboard steht „Version x.x.x“. Alternativ: Werkzeuge → Website-Zustand → Bericht.

Wichtig: Dass ältere Versionen wie 6.8.x von dieser Lücke nicht betroffen sind, heißt nicht, dass sie sicher sind. Sie enthalten schlicht andere, teils seit Monaten bekannte Schwachstellen. Wer noch auf 6.8 oder älter läuft, hat ein anderes Problem – aber ebenfalls ein Problem.


Was genau ist bei wp2shell passiert?

Entdeckt wurde die Schwachstelle vom Sicherheitsforschungsteam von Searchlight Cyber, konkret durch deren Angriffsflächen-Einheit Assetnote. Der Fund wurde verantwortungsvoll über das HackerOne-Programm von WordPress gemeldet – also erst an die Entwickler, nicht an die Öffentlichkeit.

Das Besondere an wp2shell: Es ist nicht eine Lücke, sondern zwei. Und genau darin liegt die Gefahr.

Schwachstelle 1: Die SQL-Injection (CVE-2026-60137)

Die erste Lücke steckt in WP_Query – das ist die zentrale Komponente, über die WordPress praktisch jede Datenbankabfrage abwickelt. Jeder Beitrag, jede Seite, jede Übersicht läuft darüber.

Ein bestimmter Parameter dieser Abfrage (author__not_in) wird nicht ausreichend gefiltert. Das erlaubt eine sogenannte SQL-Injection: Ein Angreifer schmuggelt eigene Datenbankbefehle in eine ganz normale Anfrage ein und bringt die Datenbank dazu, Daten herauszugeben, die sie nie herausgeben sollte.

Für sich allein wäre das bereits unangenehm – aber der Zugriff auf diesen Parameter war eigentlich abgesichert. Man musste angemeldet sein.

Schwachstelle 2: Die Routen-Verwechslung (CVE-2026-63030)

Genau hier setzt die zweite Lücke an. Sie steckt im sogenannten Batch-Endpunkt der WordPress-REST-Schnittstelle, erreichbar unter /wp-json/batch/v1. Diese Schnittstelle erlaubt es, mehrere Anfragen in einem einzigen Aufruf zu bündeln – praktisch für Apps und Integrationen, standardmäßig aktiv und ohne Anmeldung erreichbar.

Der Fehler: Bei einer bestimmten, verfremdeten Schreibweise des Anfragepfads lesen die Prüfung und die Ausführung diesen Pfad unterschiedlich. Die Sicherheitsprüfung sieht einen harmlosen Pfad und winkt durch. Die Ausführung leitet die Anfrage dann an einen anderen Handler weiter – einen, der die Anmeldepflicht nicht durchsetzt.

Die Verkettung

Und damit fällt die Absicherung der ersten Lücke. Über die Routen-Verwechslung wird die SQL-Injection erreichbar, ohne dass sich jemand anmelden muss.

Das BSI bewertet die einzelnen Lücken bereits hoch (CVE-2026-60137 mit CVSS 9.1). Die Kombination beider erreicht einen CVSS-Wert von 9.8 von 10 – praktisch das Maximum. Remote ausnutzbar, keine Authentifizierung, keine Nutzerinteraktion, keine besondere Konfiguration nötig.

Searchlight Cyber formulierte es so: Der Angriff habe keinerlei Voraussetzungen und funktioniere gegen eine Standardinstallation ohne Plugins.

Chronologie: Warum das Wochenende so kritisch war

Datum Ereignis
Fr, 17.07.2026

WordPress veröffentlicht Notfall-Updates 6.9.5 und 7.0.2. Searchlight Cyber macht die Lücke öffentlich – ohne technische Details, um Zeit zum Patchen zu geben. WordPress.org aktiviert erzwungene automatische Updates.

Sa, 18.07.2026

Das BSI veröffentlicht die Cyber-Sicherheitswarnung 2026-271984-1032, Warnstufe Orange.

Wochenende 18./19.07.

Sicherheitsforscher rekonstruieren die Lücke aus dem veröffentlichten Patch. Erste Proof-of-Concept-Codes kursieren.

Di, 21.07.2026

Die US-Behörde CISA nimmt beide CVEs in ihren Katalog der aktiv ausgenutzten Schwachstellen auf – bevor ein fertiger Exploit öffentlich war. Das heißt: Organisierte Angreifer waren bereits aktiv.

Mi, 22.07.2026

Ein vollständig funktionsfähiger, automatisierter Exploit wird öffentlich. Ab hier braucht ein Angreifer kein Fachwissen mehr – nur noch das Werkzeug.

seit 23.07.2026 Massenhafte automatisierte Angriffe. Bestätigt unter anderem durch Bitdefender, Patchstack und Wiz.

Der Zeitpunkt der Veröffentlichung – Freitagabend europäischer Zeit – wird in Fachkreisen kritisch diskutiert. Wer nicht aktiv Sicherheitsmeldungen verfolgt, hat ein ganzes Wochenende ahnungslos verbracht, während der Angriff bereits lief.

Genau das ist der Punkt, an dem die meisten kleinen Websitebetreiber verlieren: nicht am fehlenden Patch, sondern daran, dass niemand hinschaut. Genau dafür gibt es den WordPress-Wartungsvertrag.


Was Angreifer nach dem Einbruch tatsächlich tun

Die Lücke ist der Türöffner. Interessanter – und für Sie relevanter – ist, was danach passiert. Die Sicherheitsforscher von Bitdefender haben einen echten Vorfall im Detail untersucht. Der Ablauf ist erschreckend systematisch:

Schritt 1: Massenscan

Automatisierte Scanner klopfen millionenfach Websites ab und prüfen, ob der verwundbare Endpunkt erreichbar ist. Diese Phase ist noch kein Angriff – aber sie ist das Frühwarnsignal. Zwischen Scan und tatsächlichem Angriff liegen oft nur wenige Stunden.

Schritt 2: Der Einbruch – in etwa zwei Minuten

Läuft der eigentliche Angriff an, läuft er vollautomatisch durch. Vom ersten Aufruf bis zum Administratorzugang vergehen nach Bitdefender-Messungen rund zwei Minuten. Kein Mensch sitzt dabei an der Tastatur.

Über die SQL-Injection wird zunächst die Datenbank ausgelesen – unter anderem der Passwort-Hash des Administrators, der sich später offline knacken lässt. Anschließend missbraucht die Angriffskette zwei völlig legitime WordPress-Mechanismen (den oEmbed-Cache für Link-Vorschauen und ein zwischengespeichertes Customizer-Änderungsset), um einen manipulierten Wert in die Optionen-Tabelle zu schreiben. Das Ergebnis: ein voll funktionsfähiges Administratorkonto, das der Angreifer selbst kontrolliert.

Schritt 3: Die Persistenz

Mit Administratorrechten installiert der Angreifer ein präpariertes Plugin. Das ist kein Hack mehr – das ist die normale WordPress-Funktion, die jeder Administrator hat.

Dieses Plugin legt sogenannte Webshells ab: kleine PHP-Dateien an zufällig benannten Pfaden innerhalb von wp-content, die Befehle über normale HTTP-Aufrufe entgegennehmen. Damit hat der Angreifer eine Fernsteuerung für Ihren Server – dauerhaft, auch nachdem die eigentliche Lücke geschlossen wurde.

Beobachtet wurden dabei mehrere Varianten:

  • Webshells mit eigenem Zugangstoken, damit kein Dritter sie mitbenutzen kann
  • Eine minimale Variante, die bei Aufruf einen HTTP-404-Fehler zurückgibt – damit taucht sie in normalen Server-Logs schlicht nicht auf
  • Eigene, versteckte REST-API-Hintertüren, die Befehle in kodierter Form entgegennehmen

Schritt 4: Was danach kommt

Ab hier wird es unternehmensspezifisch. Beobachtet und vom BSI genannt werden:

  • Datendiebstahl – Kundendaten, Kontaktformular-Einträge, Bestelldaten, Zugangsdaten
  • Backdoors – dauerhafte Zugänge, oft mehrfach redundant angelegt
  • Cryptomining – Ihre Serverleistung wird zum Schürfen von Kryptowährung missbraucht
  • SEO-Spam und Weiterleitungen – Ihre Website verkauft plötzlich Potenzmittel oder leitet Besucher auf Betrugsseiten
  • Versand von Spam-Mails über Ihren Server, was Ihre Domain auf Blacklists befördert
  • Ransomware – bei Angriffsmustern dieser Art in der Vergangenheit ein regelmäßiger nächster Schritt, sobald ein menschlicher Angreifer den Zugang übernimmt

Ist bei Ihnen bereits einer dieser Fälle eingetreten, hilft die WordPress-Notfall-Reparatur – Bereinigung und Absicherung zum Festpreis.

Der wichtigste Befund: Auch gescheiterte Angriffe hinterlassen Spuren

Das ist der Teil, den ich für die praktisch wichtigste Erkenntnis der gesamten Bitdefender-Analyse halte.

In dem untersuchten Fall lief der Angriff dreimal, bevor er vollständig erfolgreich war. Die ersten beiden Versuche legten jeweils ein Administratorkonto an – und blieben dann stecken. Kein Plugin, keine Webshell. Erst der dritte Durchlauf ging komplett durch.

Der Grund dafür ist strukturell: Die Aufräumroutine des Angriffswerkzeugs läuft nur bei vollständigem Erfolg. Bricht der Angriff vorher ab, bleibt das angelegte Administratorkonto einfach liegen.

Für Sie bedeutet das zweierlei:

Erstens: Suchen Sie nicht zuerst nach einer Webshell. Suchen Sie nach einem Administratorkonto, das Sie nicht angelegt haben. Das ist der zuverlässigste erste Indikator.

Zweitens: Ein solches verwaistes Konto ohne weitere Spuren ist kein Fehlalarm. Es ist der Beweis, dass Ihre Website gezielt angegriffen wurde, dass die Kette zumindest teilweise durchlief – und dass der Angreifer wiederkommen kann. Wenn Sie so einen Fund haben und ihn nicht selbst einordnen möchten: Das ist genau der Fall für ein WordPress-Sicherheitsaudit.


Woran erkenne ich, dass meine Website betroffen ist?

Gehen Sie diese Liste durch. Ein einziger Treffer genügt, um von einer Kompromittierung auszugehen.

Im WordPress-Backend

  • Unbekannte Benutzerkonten mit Administratorrechten. Gehen Sie auf Benutzer → Alle Benutzer und filtern Sie nach „Administrator“. Jeder Eintrag, den Sie nicht selbst angelegt haben, ist ein Alarmsignal.
  • Benutzernamen mit den Präfixen w2s_ oder wp2_ – das sind die Standardwerte des öffentlichen Angriffswerkzeugs.
  • Administratorkonten mit E-Mail-Adressen der Domain @wp2shell.invalid
  • Unbekannte Plugins unter Plugins → Installierte Plugins, insbesondere solche, die Sie nicht zuordnen können. Der Ordnername kann beliebig sein.
  • Neue Beiträge oder Seiten, die Sie nicht erstellt haben
  • Probleme beim Login oder plötzlich geänderte Passwörter

Auf dem Server / per FTP

  • Unbekannte PHP-Dateien an zufällig benannten Pfaden innerhalb von wp-content/, die zu keinem installierten Plugin gehören
  • Plugin-Verzeichnisse unter wp-content/plugins/, die Sie nicht kennen
  • Dateien mit auffällig neuem Änderungsdatum – sortieren Sie Ihr FTP-Programm nach Änderungsdatum und schauen Sie auf alles seit dem 17. Juli 2026

In den Server-Logs

  • Ungewöhnlich viele POST-Anfragen an /wp-json/batch/v1 oder /?rest_route=/batch/v1
  • HTTP-207-Antworten (Multi-Status) von genau diesem Endpunkt – das ist laut Bitdefender ein besonders zuverlässiger Hinweis auf einen Ausnutzungsversuch
  • Anfragepfade mit dreifachem Schrägstrich (///) an den Batch-Endpunkt
  • User-Agent-Einträge, die wp2shell oder rezwp2shell enthalten – schwacher Indikator, da Angreifer das trivial ändern können

Von außen sichtbar

  • Google zeigt Warnungen („Diese Website kann Ihren Computer schädigen“) oder Ihre Seite verschwindet aus dem Index
  • Weiterleitungen auf fremde Seiten, oft nur bei Besuchern von Mobilgeräten oder von Google kommend
  • Search Console meldet unbekannte Seiten in fremden Sprachen
  • Ihr Hoster meldet sich wegen auffälligem Traffic oder Spam-Versand

Ein Hinweis zu den Namensmustern: w2s_, wp2shell.invalid und ähnliche Bezeichnungen sind Voreinstellungen des öffentlich verfügbaren Angriffswerkzeugs. Jeder halbwegs versierte Angreifer ändert sie in zwei Minuten. Verlassen Sie sich also nicht darauf, sie zu finden – die verlässlichen Indikatoren sind die verhaltensbasierten: ein Konto, das niemand angelegt hat. Eine Datei, die niemand hochgeladen hat.

Unsicher, ob ein Fund relevant ist? Schicken Sie mir kurz, was Sie gefunden haben – über das Kontaktformular oder telefonisch. Eine Ersteinschätzung kostet Sie nichts.

Was Sie jetzt tun sollten – in dieser Reihenfolge

Fall A: Ihre Website ist bereits auf 6.9.5 oder 7.0.2 – und war es schnell

Wenn die erzwungenen automatischen Updates bei Ihnen gegriffen haben, bevor die Angriffswelle richtig anlief, stehen Ihre Chancen gut. Trotzdem:

  1. Verlassen Sie sich nicht darauf, dass das Auto-Update lief. Prüfen Sie die Versionsnummer manuell. Bei stark angepassten Installationen sind automatische Updates häufig deaktiviert – oft aus Sorge vor Kompatibilitätsproblemen.
  2. Gehen Sie die Erkennungs-Checkliste oben trotzdem einmal durch. Das kostet 20 Minuten. Alternativ übernehme ich die Prüfung im WordPress-Sicherheitsaudit.
  3. Prüfen Sie Ihre Website zusätzlich mit dem kostenlosen Checker unter wp2shell.com, den Searchlight Cyber bereitstellt.

Fall B: Sie laufen noch auf einer betroffenen Version

  1. Aktualisieren Sie sofort auf 6.9.5 bzw. 7.0.2. Nicht „beim nächsten Wartungsfenster“ – jetzt.
  2. Falls ein Update kurzfristig nicht möglich ist: Lassen Sie anonyme Zugriffe auf /wp-json/batch/v1 über eine Web Application Firewall blockieren. Das ist auch die Empfehlung des BSI. Cloudflare hat dafür eigene Regeln ausgerollt. Wichtig: Das ist ein Notpflaster, kein Ersatz für das Update.
  3. Anschließend: Kompromittierungsprüfung. Siehe Fall C.

Fall C: Sie haben Anzeichen eines Angriffs gefunden

Hier gilt eine Regel, die sich nicht verhandeln lässt: Ein Update schließt die Tür.

-> Es wirft niemanden raus, der schon drin ist.

Wenn ein Angreifer eine Webshell hinterlassen hat, funktioniert diese nach dem Update genauso weiter wie vorher. Das Update entfernt nichts.

Machen Sie in dieser Reihenfolge:

  1. Nichts löschen. So verständlich der Impuls ist – Sie zerstören damit Beweise, die Sie später für die Dokumentationspflicht brauchen.
  2. Sichern Sie den aktuellen Zustand – Dateien und Datenbank, als forensische Kopie. Getrennt von Ihren regulären Backups.
  3. Sichern Sie die Server-Logs. Viele Hoster löschen diese nach 7 bis 14 Tagen. Beim wp2shell-Zeitfenster ab dem 17. Juli wird das jetzt knapp.
  4. Nehmen Sie die Website vom Netz oder in den Wartungsmodus – insbesondere, wenn personenbezogene Daten betroffen sein könnten.
  5. Setzen Sie alle Zugangsdaten neu: WordPress-Benutzer, Datenbank, FTP/SFTP, Hosting-Panel, und die Sicherheitsschlüssel in der wp-config.php.
  6. Prüfen Sie die Dokumentationspflicht – dazu gleich mehr.
  7. Holen Sie professionelle Hilfe, wenn Sie unsicher sind. Eine übersehene Hintertür bedeutet, dass Sie in vier Wochen wieder von vorn anfangen. Die WordPress-Notfall-Reparatur deckt genau diesen Fall ab.

Zum Thema „einfach ein Backup einspielen“: Das ist der häufigste Fehler. Wenn Sie ein Backup vom 20. Juli einspielen, spielen Sie mit hoher Wahrscheinlichkeit die Hintertür gleich mit ein. Ein Backup hilft nur, wenn es nachweislich vor dem ersten Angriff entstanden ist – und wenn Sie danach sofort patchen, bevor die Seite wieder öffentlich erreichbar ist.


Die rechtliche Seite: Welche Fristen jetzt gelten

Das ist der Teil, den fast alle unterschätzen. Ein Website-Hack ist in Deutschland nicht nur ein technisches Problem – er kann eine meldepflichtige Datenschutzverletzung sein.

Die folgenden Ausführungen sind eine allgemeine Orientierung und ersetzen keine Rechtsberatung. Für Ihren konkreten Fall wenden Sie sich bitte an Ihren Datenschutzbeauftragten oder einen Fachanwalt.

Die 72-Stunden-Frist (Art. 33 DSGVO)

Werden bei einem Angriff personenbezogene Daten verletzt – und das ist bei einem Serverzugriff dieser Art regelmäßig anzunehmen –, müssen Sie den Vorfall der zuständigen Aufsichtsbehörde melden. Die Frist beträgt 72 Stunden ab Kenntniserlangung.

Drei Punkte, die dabei regelmäßig zu Problemen führen:

  • Die Frist läuft durch. Wochenenden und Feiertage zählen mit. Wer am Freitagnachmittag entdeckt, dass die Seite kompromittiert ist, hat bis Montagnachmittag Zeit.
  • „Kenntnis“ bedeutet nicht „vollständige Aufklärung“. Der begründete Verdacht reicht aus, um die Uhr zu starten. Sie müssen nicht warten, bis Sie alles verstanden haben – Sie dürfen und sollen die Meldung gegebenenfalls nachträglich ergänzen.
  • Wer die Frist versäumt, muss das begründen. Eine verspätete Meldung ist möglich, aber begründungspflichtig.

Für Verantwortliche in Nordrhein-Westfalen ist die zuständige Behörde die Landesbeauftragte für Datenschutz und Informationsfreiheit NRW (LDI NRW). Diese stellt ein Online-Meldeformular bereit.

Die Benachrichtigung der Betroffenen (Art. 34 DSGVO)

Besteht durch den Vorfall voraussichtlich ein hohes Risiko für die Rechte und Freiheiten der Betroffenen, müssen Sie zusätzlich die betroffenen Personen selbst informieren – unverzüglich, ohne feste Stundenfrist, aber ohne schuldhaftes Zögern.

Bei Gesundheitsdaten, Kontodaten oder Zugangsdaten ist von einem hohen Risiko in aller Regel auszugehen.

Die Dokumentationspflicht (Art. 33 Abs. 5 DSGVO)

Diese gilt immer – auch dann, wenn Sie zu dem Ergebnis kommen, dass keine Meldung erforderlich ist. Sie müssen dokumentieren:

  • was passiert ist
  • welche Auswirkungen der Vorfall hatte
  • welche Abhilfemaßnahmen Sie ergriffen haben
  • und, falls Sie nicht gemeldet haben: warum nicht

Diese Dokumentation muss der Aufsichtsbehörde auf Verlangen vorgelegt werden können. Deshalb der Punkt weiter oben: nichts löschen, bevor Sie dokumentiert haben.

Wenn eine Agentur oder ein Hoster im Spiel ist (Art. 33 Abs. 2 DSGVO)

Sind Sie als Dienstleister für die Website eines Kunden verantwortlich, sind Sie in der Regel Auftragsverarbeiter. Dann gilt: Sie müssen Ihren Auftraggeber unverzüglich informieren, sobald Ihnen die Verletzung bekannt wird. Die 72-Stunden-Frist gegenüber der Behörde läuft beim Verantwortlichen – aber sie startet praktisch mit Ihrer Meldung.

Für Arztpraxen, Anwälte und Steuerberater: § 203 StGB

Berufsgeheimnisträger haben eine zusätzliche Schwelle. Der unbefugte Zugriff Dritter auf Patienten- oder Mandantendaten kann strafrechtliche Relevanz nach § 203 StGB entfalten. Zwar setzt der Straftatbestand ein Offenbaren voraus – aber die berufsrechtlichen Sorgfaltspflichten hinsichtlich der technischen Absicherung bestehen unabhängig davon und werden im Schadensfall geprüft.

Für Praxen kommt hinzu: Kontaktformulare mit Terminwünschen und Symptomschilderungen, Rückrufbitten, Online-Terminbuchungen – all das sind Gesundheitsdaten im Sinne von Art. 9 DSGVO. Diese unterliegen dem strengsten Schutzniveau, das die DSGVO kennt.

Bußgeldrahmen

Verstöße gegen die Melde- und Dokumentationspflichten nach Art. 33 fallen unter Art. 83 Abs. 4 DSGVO: bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes, je nachdem, was höher ist.

Bei einem Einzelunternehmen oder einer Praxis liegen realistische Bußgelder deutlich darunter. Aber der entscheidende Punkt ist ein anderer: Aufsichtsbehörden bewerten den Umgang mit dem Vorfall mindestens so stark wie den Vorfall selbst. Wer sauber dokumentiert, fristgerecht meldet und nachvollziehbar reagiert, steht am Ende deutlich besser da als jemand, der den Vorfall aussitzt.

Warum wp2shell anders ist als der typische WordPress-Hack

Die allermeisten WordPress-Angriffe laufen über veraltete Plugins. Ein Kontaktformular-Plugin, das seit zwei Jahren kein Update mehr bekommen hat. Ein Slider, dessen Entwickler das Projekt eingestellt hat. Ein Theme aus einem dubiosen Marktplatz.

Die Konsequenz daraus war bisher: Wer seine Plugins schlank hält, aktuell hält und aus vertrauenswürdigen Quellen bezieht, hat einen großen Teil des Risikos im Griff.

wp2shell durchbricht diese Logik. Die Lücke steckt im Kern – in dem Teil von WordPress, den jede einzelne Installation hat, ohne Ausnahme. Es gibt keine Konfiguration, mit der Sie sich hätten schützen können. Kein „ich benutze ja kaum Plugins“. Kein „meine Seite ist zu klein, um interessant zu sein“.

Der letzte Punkt ist ohnehin der hartnäckigste Irrtum. Die Scanner, die derzeit das Netz durchkämmen, wissen nicht, ob Ihre Praxis fünf oder fünfzig Mitarbeiter hat. Sie prüfen nur eines: Ist der Endpunkt erreichbar, ja oder nein. Eine Zahnarztpraxis in Frechen ist für einen automatisierten Scanner exakt so interessant wie ein Konzern.

Was zählt, ist nicht Ihre Größe. Was zählt, ist Ihre Reaktionszeit.


So schützen Sie sich künftig

Aus wp2shell lässt sich eine Lehre ziehen, die über diese eine Lücke hinausgeht: Der Patch war am 17. Juli verfügbar. Angegriffen wurde ab dem 21. Juli. Dazwischen lagen vier Tage.

Wer in diesen vier Tagen aktualisiert hat, war sicher. Wer erst zwei Wochen später hingeschaut hat, hatte möglicherweise schon Besuch.

Die Frage ist also nicht, ob Sicherheitslücken auftreten – das werden sie, regelmäßig. Die Frage ist, wie schnell Sie davon erfahren und wie schnell reagiert wird.

Konkret bedeutet das:

  1. Automatische Updates für den WordPress-Kern aktivieren. Bei wp2shell hat das viele Seiten gerettet. Sich darauf zu verlassen ist trotzdem keine Strategie – aber es abzuschalten ist fahrlässig.
  2. Ein aktuelles Backup-Konzept, mit Aufbewahrung über mehrere Wochen und Speicherung außerhalb des Webservers. Ein Backup, das auf demselben Server liegt, den der Angreifer kontrolliert, ist kein Backup.
  3. Eine Web Application Firewall als vorgelagerte Schutzschicht. Sie filtert bekannte Angriffsmuster, bevor sie WordPress überhaupt erreichen – und kauft Ihnen im Ernstfall genau die Tage, auf die es ankommt.
  4. Regelmäßige Kontrolle der Benutzerkonten. Einmal im Monat auf die Administratorliste schauen dauert 30 Sekunden.
  5. Jemand muss die Sicherheitsmeldungen verfolgen. Das ist der Punkt, an dem die meisten kleinen Betriebe systematisch verlieren – nicht aus Nachlässigkeit, sondern weil es schlicht niemandes Aufgabe ist. Im WordPress-Wartungsvertrag übernehme ich genau das: BSI-Warnungen im Blick behalten und kritische Updates innerhalb weniger Stunden einspielen.

Häufige Fragen zu wp2shell

  • Reicht das Update auf 6.9.5 oder 7.0.2 aus?

    Um die Lücke zu schließen: ja. Um eine bereits erfolgte Kompromittierung zu beseitigen: nein. Das Update entfernt keine Hintertüren, die vor dem Update installiert wurden.

  • Meine Website hat automatisch aktualisiert – bin ich damit sicher?

    Wahrscheinlich, aber prüfen Sie es. Erstens greifen erzwungene Updates nicht bei allen Installationen, insbesondere nicht bei deaktivierten Auto-Updates. Zweitens sagt der Zeitpunkt des Updates nichts darüber aus, ob Sie vorher bereits angegriffen wurden.

  • Ich benutze gar keine Plugins. Bin ich sicher?

    Nein. Genau das macht wp2shell besonders: Die Lücke steckt im WordPress-Kern und ist in einer Standardinstallation ohne jedes Plugin ausnutzbar.

  • Meine Seite läuft auf WordPress 6.7. Muss ich handeln?

    Von dieser konkreten Angriffskette sind Sie nicht betroffen. Sie laufen allerdings auf einer Version, die keine Sicherheitsupdates mehr erhält – das ist ein eigenständiges, ebenso ernstes Risiko.

  • Wie erkenne ich, ob jemand nur gescannt oder tatsächlich angegriffen hat?

    Reine Scans hinterlassen typischerweise nur Log-Einträge. Ein zumindest teilweise erfolgreicher Angriff hinterlässt fast immer ein Administratorkonto, das Sie nicht angelegt haben. Das ist der zuverlässigste Trennstrich.

  • Muss ich den Vorfall melden, wenn nur ein fremdes Administratorkonto vorhanden war und sonst nichts?

    Das ist im Einzelfall zu bewerten. Ein fremder Administratorzugang bedeutet grundsätzlich, dass ein Zugriff auf sämtliche in der Datenbank gespeicherten personenbezogenen Daten möglich war. Die Dokumentationspflicht nach Art. 33 Abs. 5 DSGVO greift in jedem Fall. Zur Meldepflicht sollten Sie datenschutzrechtlichen Rat einholen.

  • Kann mein Hoster das für mich prüfen?

    Manche Hoster haben eigene Scans durchgeführt und Kunden informiert. Verlassen Sie sich nicht darauf. Der Hoster ist für den Server verantwortlich, nicht für den Inhalt Ihrer WordPress-Installation.

Betroffen? Handeln Sie jetzt – nicht nächste Woche

Wenn Sie beim Durchgehen der Checkliste einen Treffer hatten, oder wenn Sie schlicht nicht sicher sind, welche WordPress-Version bei Ihnen läuft: Warten Sie nicht ab.

Ich prüfe Ihre WordPress-Installation gezielt auf die wp2shell-Spuren – unbekannte Administratorkonten, fremde Plugins, versteckte PHP-Dateien und verdächtige Log-Einträge. Sie bekommen eine klare Aussage: kompromittiert oder nicht, und wenn ja, was zu tun ist.

Ist Ihre Website bereits kompromittiert, übernehme ich die vollständige Bereinigung: Entfernung aller Hintertüren, Absicherung der Installation, Zurücksetzen sämtlicher Zugangsdaten – und eine nachvollziehbare Dokumentation des Vorfalls, die Sie für Ihre Aufzeichnungspflicht nach Art. 33 Abs. 5 DSGVO verwenden können. Eine kurze Nachricht über das Kontaktformular genügt.

Zur WordPress-Notfallhilfe

Fazit

wp2shell wird als Lehrstück in Erinnerung bleiben – weniger wegen seiner technischen Raffinesse als wegen seines Zeitplans. Der Patch war innerhalb von Stunden verfügbar. Die Angriffe begannen wenige Tage später. Dazwischen lag ein Wochenende, in dem sehr viele Betreiber schlicht nicht hingeschaut haben.

Die eigentliche Schwachstelle war am Ende nicht author__not_in und nicht der Batch-Endpunkt. Die eigentliche Schwachstelle war, dass zwischen „Patch verfügbar“ und „Patch eingespielt“ bei den meisten kleinen Websites niemand steht.

Prüfen Sie Ihre Versionsnummer. Prüfen Sie Ihre Administratorliste. Beides zusammen kostet Sie fünf Minuten – und beantwortet die Frage, ob Sie hier nur mitlesen oder betroffen sind.

Quellen

  • Searchlight Cyber / Assetnote: „wp2shell: Pre Authentication RCE in WordPress Core“ (17.07.2026) – slcyber.io, Prüftool unter wp2shell.com
  • BSI: Cyber-Sicherheitswarnung 2026-271984-1032 (18.07.2026, Update 20.07.2026), Warnstufe 3 („Orange“)
  • Bitdefender: „Technical Advisory: wp2shell – Unauthenticated Remote Code Execution and Full Site Takeover in WordPress Core“ (27.07.2026)
  • heise online: „WordPress-Lücke ‚wp2shell‘ wird angegriffen“ (Juli 2026)
  • CISA Known Exploited Vulnerabilities Catalog, Aufnahme am 21.07.2026
  • WordPress.org Security Release 6.9.5 / 7.0.2 (17.07.2026)

Weiterlesen

WordPress-Updates ignoriert? Was im schlimmsten Fall passiert

WordPress-Updates ignoriert? Was im schlimmsten Fall passiert

„Läuft doch alles.“ – Das ist der Satz, den ich am häufigsten höre, bevor eine Website gehackt wird.

WordPress-Updates erscheinen im Dashboard als kleine rote Zahl. Viele Website-Besitzer ignorieren sie – aus Zeitmangel, aus Angst etwas kaputt zu machen oder schlicht, weil sie nicht wissen, warum diese Updates so wichtig sind.

In diesem Artikel zeige ich Ihnen, was wirklich passiert, wenn WordPress-Updates über Wochen, Monate oder Jahre ausbleiben. Und warum diese kleine rote Zahl der Unterschied zwischen einer funktionierenden Website und einem ernsthaften Problem sein kann.

Die Zahlen sprechen eine klare Sprache

WordPress betreibt über 43 Prozent aller Websites weltweit. Diese Verbreitung macht es zum attraktivsten Ziel für automatisierte Hackerangriffe. Experten schätzen, dass täglich rund 13.000 WordPress-Websites gehackt werden – das sind etwa 4,7 Millionen pro Jahr.

Der erschreckende Teil: Die überwältigende Mehrheit dieser Angriffe wäre vermeidbar gewesen. Veraltete Plugins sind für rund 92 Prozent aller gemeldeten WordPress-Sicherheitslücken verantwortlich. Nicht der WordPress-Kern ist das Problem – sondern die Erweiterungen, die niemand aktualisiert.

In einer Umfrage unter Betreibern gehackter Websites gaben 60 Prozent an, dass der Angriff über eine bekannte Sicherheitslücke in einem Plugin oder Theme erfolgte. Die Schwachstellen waren längst behoben – die Betreiber hatten das Update nur nicht eingespielt.

Was passiert, wenn Sie Updates ignorieren?

Stellen Sie sich vor, ein Schlüsseldienst veröffentlicht eine Mitteilung: „Achtung, Schlösser der Serie X haben einen Defekt. Bitte tauschen Sie den Zylinder aus.“ Sie ignorieren die Mitteilung. Was passiert?

Genau das Gleiche passiert bei WordPress. Wenn eine Sicherheitslücke entdeckt und öffentlich dokumentiert wird, wissen zwei Gruppen davon: die Entwickler, die einen Patch veröffentlichen – und die Angreifer, die jetzt gezielt nach Websites suchen, die den Patch noch nicht eingespielt haben.

Und diese Suche passiert nicht manuell. Automatisierte Bots scannen das Internet rund um die Uhr nach verwundbaren Installationen. Wird Ihre Website gefunden, erfolgt der Angriff vollautomatisch. Innerhalb von Stunden nach Bekanntwerden einer Lücke starten die ersten Exploits.

Die fünf Eskalationsstufen: Vom verpassten Update zur Katastrophe

Stufe 1: Das Update wird ignoriert. Im Dashboard erscheint die Meldung „Update verfügbar“. Sie klicken nicht drauf – vielleicht morgen. Aus morgen werden Wochen, aus Wochen Monate.

Stufe 2: Angreifer finden Ihre Website. Bots prüfen automatisch, welche Plugin-Version Sie einsetzen. Stimmt die Version mit einer bekannten Schwachstelle überein, wird Ihre Seite als Ziel markiert.

Stufe 3: Schadcode wird eingeschleust. Je nach Art der Lücke können Angreifer Dateien manipulieren, Weiterleitungen auf Spam-Seiten einbauen, Malware an Ihre Besucher verteilen oder sich über Backdoors dauerhaften Zugang verschaffen. Das Tückische: Oft merken Sie davon zunächst nichts.

Stufe 4: Google reagiert. Google erkennt die Malware und markiert Ihre Website als „möglicherweise gehackt“ oder „gefährlich“. Ihre Besucher sehen eine Warnmeldung, Ihr Google-Ranking bricht ein. Bei einem Online-Shop bedeutet das: null Umsatz, von jetzt auf gleich.

Stufe 5: Der Schaden wird sichtbar. Kunden beschweren sich, der Hoster sperrt Ihre Website, Sie müssen einen Experten für die Bereinigung beauftragen. Im schlimmsten Fall sind Kundendaten betroffen und es droht eine DSGVO-Meldepflicht.

Und all das, weil ein Update nicht eingespielt wurde.

„Aber wenn ich update, geht vielleicht etwas kaputt“

Das ist die häufigste Ausrede – und sie ist verständlich. Ja, es kann passieren, dass nach einem Update ein Plugin nicht mehr mit dem Theme kompatibel ist oder eine Funktion anders aussieht. Aber lassen Sie uns das ins Verhältnis setzen.

Ein Update-Konflikt bedeutet im schlimmsten Fall: Eine Seite zeigt kurzzeitig einen Fehler, der sich beheben lässt. Ein ausgelassenes Sicherheitsupdate bedeutet im schlimmsten Fall: Ihre komplette Website wird kompromittiert, Kundendaten sind gefährdet und Sie zahlen für Bereinigung, Reputationsschaden und im schlimmsten Fall DSGVO-Bußgelder.

Die Angst vor Update-Problemen ist wie die Angst vor Nebenwirkungen einer Impfung – während man gleichzeitig die Krankheit ignoriert.

Der Ausweg: Updates nie blind einspielen, sondern mit Backup. Wer vorher ein Backup erstellt, kann im Fall eines Problems den alten Zustand in Minuten wiederherstellen. Kein Risiko, kein Stress.

Nicht nur Plugins: Was alles aktualisiert werden muss

Viele Website-Besitzer denken bei „WordPress-Update“ nur an den blauen Button im Dashboard. Tatsächlich gibt es drei Ebenen, die alle aktuell gehalten werden müssen:

Der WordPress-Kern. Das Fundament Ihrer Website. Sicherheitsupdates werden in der Regel alle ein bis zwei Monate veröffentlicht und sollten sofort eingespielt werden. Seit Juli 2025 erhalten WordPress-Versionen vor 4.7 keine Sicherheitsupdates mehr.

Plugins. Die mit Abstand größte Angriffsfläche. Bei über 60.000 verfügbaren Plugins im WordPress-Verzeichnis werden wöchentlich Hunderte neue Sicherheitslücken bekannt. Allein in einer einzigen Woche im März 2025 wurden 417 neue Plugin-Schwachstellen dokumentiert.

Themes. Oft vergessen, aber genauso relevant. Ein veraltetes Theme kann dieselben Schwachstellen aufweisen wie ein veraltetes Plugin. Auch deaktivierte Themes sind ein Risiko – die Dateien liegen weiterhin auf dem Server und können angegriffen werden.

Ein wichtiger Punkt, den viele übersehen: Auch deaktivierte Plugins sind angreifbar. Solange die Dateien auf dem Server liegen, kann eine Sicherheitslücke ausgenutzt werden. Nicht benötigte Plugins sollten daher nicht nur deaktiviert, sondern komplett gelöscht werden.

Was eine regelmäßige Wartung konkret verhindert

Ein professioneller Wartungsvertrag nimmt Ihnen genau diese Arbeit ab – und zwar nicht einmal im Quartal, sondern kontinuierlich. Das bedeutet konkret:

Updates werden zeitnah eingespielt – mit vorherigem Backup, damit im Fehlerfall sofort zurückgerollt werden kann. Tägliche Sicherheitsscans erkennen verdächtige Veränderungen, bevor daraus ein Problem wird. Nicht mehr gepflegte Plugins werden identifiziert und durch sichere Alternativen ersetzt. Und wenn doch einmal etwas passiert, haben Sie einen Ansprechpartner, der Ihre Website kennt und sofort handeln kann.

Die monatlichen Kosten dafür sind ein Bruchteil dessen, was eine Bereinigung nach einem Hack kostet – von Umsatzausfall und Reputationsschaden ganz zu schweigen.

Prüfen Sie jetzt: Wie aktuell ist Ihre Website?

Loggen Sie sich in Ihr WordPress-Dashboard ein und schauen Sie nach, wie viele Updates ausstehen. Wenn dort mehr als eine Handvoll roter Zahlen stehen, ist es höchste Zeit zu handeln.

Sie sind sich unsicher, ob Ihre Website Sicherheitslücken aufweist? Ich biete einen kostenlosen Website-Sicherheitscheck an – schnell, verständlich und unverbindlich.

Jetzt kostenlosen Sicherheitscheck anfordern

Sie erhalten eine klare Einschätzung, wo Handlungsbedarf besteht und welche Maßnahmen Priorität haben.

Fazit: Updates sind keine Option – sie sind Pflicht

WordPress-Updates sind kein lästiges Detail, das man irgendwann mal erledigt. Sie sind die wichtigste einzelne Maßnahme, die Sie für die Sicherheit Ihrer Website ergreifen können.

Die Frage ist nicht, ob Ihre veraltete Website irgendwann angegriffen wird. Die Frage ist nur, wann. Und ob Sie dann vorbereitet sind – oder ob Sie dann einen Experten für die Bereinigung beauftragen müssen, der Ihnen genau das erklärt, was Sie in diesem Artikel gelesen haben.

Sie haben ein konkretes Problem?

Wenn Sie den Fehler nicht selbst beheben können oder unsicher sind, wo die Ursache liegt: Ich helfe Ihnen gerne. In den meisten Fällen kann ich das Problem innerhalb weniger Stunden identifizieren und beheben – zum Festpreis, ohne versteckte Kosten.

Weiterlesen

WordPress in der Arztpraxis: Warum Ihre Praxis-Website ein unterschätztes DSGVO-Risiko ist

WordPress in der Arztpraxis

Warum Ihre Praxis-Website ein unterschätztes DSGVO-Risiko ist

Ihre Praxis-Website funktioniert, Patienten finden Sie online, Termine kommen rein. Alles in Ordnung – oder?

Was die meisten Praxisinhaber nicht wissen: Hinter der Oberfläche ihrer WordPress-Website lauern Sicherheitslücken, die nicht nur technische Probleme verursachen, sondern handfeste datenschutzrechtliche Konsequenzen nach sich ziehen können. Und im Gesundheitswesen wiegen diese Konsequenzen besonders schwer.

In diesem Artikel zeige ich Ihnen, warum gerade Arztpraxen bei ihrer Website genau hinsehen sollten, welche konkreten Risiken bestehen und was Sie tun können, um Ihre Praxis – und Ihre Patienten – zu schützen.

Arztpraxen und WordPress:
Eine weit verbreitete Kombination

WordPress betreibt über 43 Prozent aller Websites weltweit. Bei den Systemen, die auf einem bekannten CMS basieren, liegt der Marktanteil sogar bei über 60 Prozent. Diese Verbreitung hat einen entscheidenden Nachteil: WordPress ist das mit Abstand häufigste Angriffsziel für automatisierte Hackerangriffe.

Arztpraxen bilden hier keine Ausnahme. Viele Praxis-Websites wurden vor Jahren erstellt – oft von einem Bekannten, einer kleinen Agentur oder im Rahmen eines Paketangebots. Danach passierte häufig: nichts. Kein regelmäßiges Update, keine Sicherheitsprüfung, keine Wartung.

Das Problem dabei: WordPress ist kein statisches System. Es ist eine lebendige Software mit regelmäßigen Updates für den Kern, für Themes und für jedes einzelne installierte Plugin. Jedes nicht eingespielte Update ist ein potenzielles Einfallstor.


Warum Arztpraxen besonders gefährdet sind

Hier wird es für Praxisinhaber richtig relevant. Denn Arztpraxen verarbeiten eine besondere Kategorie personenbezogener Daten: Gesundheitsdaten.

Die DSGVO zählt Gesundheitsdaten zu den besonders schützenswerten personenbezogenen Angaben. Artikel 9 stellt erhöhte Anforderungen an deren Verarbeitung – und bei Verstößen drohen entsprechend höhere Konsequenzen.

Jetzt denken Sie vielleicht: „Gesundheitsdaten? Auf meiner Website werden doch keine Patientenakten gespeichert.“ Stimmt.

Aber denken Sie an Folgendes:

Verfügt Ihre Website über ein Kontaktformular, über das Patienten Termine anfragen? Dann ist es nur eine Frage der Zeit, bis jemand dort schreibt: „Ich brauche einen Termin wegen meiner Rückenschmerzen“ oder „Ich möchte mein Rezept für [Medikament] verlängern lassen.“ Gerade für Arztpraxen ist es bedeutsam, dass über Webformulare Gesundheitsdaten direkt abgefragt werden oder durch Freitexteingaben übertragen werden können. (siehe Dr. DSGVO)

Und genau hier beginnt das Risiko.

Die Risikokette: Vom veralteten Plugin zum Datenschutzvorfall

Lassen Sie mich die Kette einmal konkret aufzeigen, wie sie in der Praxis abläuft:

Ihre WordPress-Installation ist nicht aktuell. Vielleicht wurde seit Monaten oder Jahren kein Update durchgeführt. Das Theme stammt noch aus der Erstinstallation, Plugins haben den Vermerk „Update verfügbar“ – oder schlimmer: Sie erhalten gar keine Updates mehr, weil der Entwickler das Plugin eingestellt hat.

Bekannte Sicherheitslücken bleiben offen. WordPress-Sicherheitslücken werden öffentlich dokumentiert. Das ist eigentlich gut, denn so können Entwickler schnell reagieren. Aber es bedeutet auch: Angreifer wissen genau, welche Schwachstellen existieren und bei welchen Plugin-Versionen sie ausgenutzt werden können.

Automatisierte Angriffe scannen Ihre Website. Hackerangriffe auf WordPress erfolgen fast nie gezielt gegen ein bestimmtes Unternehmen. Stattdessen scannen Bots das Internet automatisch auf bekannte Schwachstellen und greifen verwundbare Websites an.

Im schlimmsten Fall werden Daten kompromittiert. Angreifer können Kontaktformular-Eingaben abfangen, Weiterleitungen auf Phishing-Seiten einbauen, Malware an Ihre Besucher verteilen oder sich dauerhaft Zugang zu Ihrem System verschaffen.

Und dann greift die DSGVO. Ein solcher Vorfall ist eine meldepflichtige Datenschutzverletzung. Artikel 33 der DSGVO schreibt vor: Sie müssen den Vorfall innerhalb von 72 Stunden der zuständigen Landesdatenschutzbehörde melden. Sind die Rechte und Freiheiten der betroffenen Patienten gefährdet, müssen Sie zusätzlich jeden einzelnen betroffenen Patienten persönlich informieren – nach Artikel 34 DSGVO.


Konsequenzen, die über Bußgelder hinausgehen

Bei Datenschutzverstößen im Gesundheitswesen sind die Aufsichtsbehörden besonders wachsam. Die DSGVO sieht für Datenschutzverstöße Bußgelder von bis zu 20 Millionen Euro oder vier Prozent des weltweiten Jahresumsatzes vor. (Quelle: Datenschutz) In der Praxis fallen die Strafen für einzelne Arztpraxen deutlich geringer aus – die Aufsichtsbehörden sind jedoch zunehmend wachsam und verhängen verstärkt Bußgelder, auch gegen Arztpraxen und medizinische Einrichtungen.

Doch das Bußgeld ist häufig nicht das eigentliche Problem. Für eine Arztpraxis ist der Reputationsschaden oft weitaus gravierender. Stellen Sie sich vor, Sie müssen Hunderte Patienten anschreiben und mitteilen, dass deren Gesundheitsdaten möglicherweise kompromittiert wurden. Das Vertrauen, das eine Arzt-Patienten-Beziehung ausmacht, lässt sich danach nur schwer wiederherstellen.

Einige Behörden haben bereits angekündigt, Arztpraxen in den kommenden Monaten stärker unter die Lupe nehmen zu wollen. Die Schonfrist der ersten Jahre nach Einführung der DSGVO ist definitiv vorbei.

Die häufigsten Schwachstellen auf Praxis-Websites

In meiner täglichen Arbeit als WordPress-Entwickler sehe ich bei Praxis-Websites immer wieder dieselben Probleme:

Veraltete WordPress-Kerninstallation. Manche Praxis-Websites laufen noch auf WordPress-Versionen, die seit Jahren keine Sicherheitsupdates mehr erhalten.

Nicht aktualisierte oder aufgegebene Plugins. Sicherheitslücken in Plugins und Themes stellen mittlerweile das Haupteinfallstor für Angreifer und Malware-Kampagnen dar. Besonders kritisch wird es, wenn ein Plugin vom Entwickler nicht mehr gepflegt wird – dann bleiben entdeckte Schwachstellen für immer offen.

Fehlende SSL-Verschlüsselung oder fehlerhafte Konfiguration. Eine HTTPS-Verbindung ist Pflicht, sobald personenbezogene Daten übertragen werden. Wenn in Webformularen Gesundheitsdaten übertragen werden, kann eine fehlende Verschlüsselung bereits ein sehr hohes Risiko für die Betroffenen darstellen.

Unzureichende oder fehlerhafte Cookie-Banner. Viele Praxis-Websites nutzen Cookie-Banner, die den Anforderungen der DSGVO nicht entsprechen – etwa weil sie Tracking-Cookies bereits vor der Einwilligung setzen.

Fehlende oder unvollständige Datenschutzerklärung. Die Datenschutzerklärung muss alle auf der Website eingesetzten Dienste korrekt aufführen. Wird beispielsweise Google Fonts direkt von Google-Servern geladen, ohne dass dies datenschutzkonform eingebunden ist, liegt bereits ein Verstoß vor.

Kein Schutz gegen automatisierte Angriffe auf Formulare. Ungeschützte Webformulare bieten einen leichten Angriffspunkt für automatisierte Programme und können für Denial-of-Service-Attacken und massenhaften Missbrauch ausgenutzt werden.


Was Sie als Praxisinhaber jetzt tun sollten

Die gute Nachricht: Die meisten dieser Risiken lassen sich mit überschaubarem Aufwand beseitigen und dauerhaft unter Kontrolle halten. Die schlechte Nachricht: Es erfordert regelmäßige, fachkundige Aufmerksamkeit – nicht einmal im Jahr, sondern kontinuierlich.

Ein professioneller WordPress-Wartungsvertrag umfasst typischerweise:

  • Regelmäßige Updates von WordPress-Kern, Themes und allen Plugins – zeitnah nach Erscheinen, nicht erst Monate später
  • Tägliche Sicherheitsscans und Monitoring auf Malware und verdächtige Aktivitäten
  • Regelmäßige Backups, die im Notfall eine schnelle Wiederherstellung ermöglichen
  • SSL-Überwachung und Prüfung der verschlüsselten Datenübertragung
  • Performance-Monitoring, damit Ihre Website schnell lädt und Patienten nicht abspringen
  • Einen festen Ansprechpartner, der Ihre Website kennt und im Notfall sofort handeln kann

Die monatlichen Kosten dafür liegen in der Regel deutlich unter dem, was eine einzige Privatpatientenabrechnung einbringt. Gemessen am Risiko eines Datenschutzvorfalls ist das eine der sinnvollsten Investitionen, die Sie für Ihre Praxis tätigen können.

Kostenloser Praxis-Website-Check:
Wo steht Ihre Website?

Sie sind sich nicht sicher, ob Ihre Praxis-Website betroffen ist? Das ist verständlich – denn die meisten Schwachstellen sind von außen nicht sichtbar.

Deshalb biete ich einen kostenlosen Website-Sicherheitscheck speziell für Arztpraxen an. Dabei prüfe ich Ihre Website auf die wichtigsten Risikofaktoren und erstelle Ihnen einen verständlichen Bericht – keine technischen Hieroglyphen, sondern klare Handlungsempfehlungen.

Jetzt kostenlosen Praxis-Website-Check anfordern

Sie erhalten einen verständlichen PDF-Report mit einer Ampel-Bewertung Ihrer Website in den Bereichen Sicherheit, Datenschutz und Performance. Sie erfahren konkret, wo Handlungsbedarf besteht und welche Maßnahmen Priorität haben. Unverbindlich und ohne versteckte Kosten.


Fazit: Datenschutz auf der Praxis-Website ist keine Kür – es ist Pflicht

Als Arzt kennen Sie das Prinzip der Prävention besser als die meisten Menschen. Vorsorge ist günstiger, wirksamer und weniger schmerzhaft als Behandlung im Akutfall. Genau so verhält es sich mit der Sicherheit Ihrer Praxis-Website.

Eine regelmäßig gewartete WordPress-Installation ist kein Luxus, sondern eine Grundvoraussetzung für den datenschutzkonformen Betrieb Ihrer Online-Präsenz. Die Frage ist nicht, ob Ihre Website irgendwann angegriffen wird – sondern ob Sie darauf vorbereitet sind, wenn es passiert.

Weiterlesen

WordPress White Screen of Death – Ursachen und Lösung

WordPress White Screen of Death – Ursachen und Lösung

Sie öffnen Ihre WordPress-Website und sehen – nichts. Keine Fehlermeldung, keine Hinweise, nur eine komplett weiße Seite. Der sogenannte White Screen of Death (WSOD) gehört zu den häufigsten und gleichzeitig frustrierendsten WordPress-Problemen. Die gute Nachricht: In den meisten Fällen lässt sich die Ursache schnell eingrenzen und beheben.

In diesem Beitrag zeige ich Ihnen, welche Ursachen hinter dem weißen Bildschirm stecken und wie Sie Schritt für Schritt vorgehen, um Ihre Website wiederherzustellen.

Was ist der White Screen of Death?

Der White Screen of Death bedeutet, dass WordPress die Seite nicht mehr rendern kann. Der Server antwortet zwar, liefert aber keinen sichtbaren Inhalt aus. Manchmal betrifft das nur das Frontend (die Website für Besucher), manchmal auch das Backend (den Admin-Bereich unter /wp-admin/). In einigen Fällen zeigt der Browser statt einer weißen Seite auch die Meldung „Diese Seite funktioniert nicht“ oder einen HTTP 500 Fehler.

Die häufigsten Ursachen

Plugin-Konflikt: Das ist mit Abstand die häufigste Ursache. Ein Plugin-Update führt zu einer Inkompatibilität mit einem anderen Plugin, dem Theme oder der WordPress-Version. Besonders kritisch wird es, wenn mehrere Plugins gleichzeitig aktualisiert werden – dann ist schwer nachvollziehbar, welches Plugin das Problem verursacht.

Theme-Fehler: Ein fehlerhaftes Theme-Update oder ein Syntaxfehler in der functions.php kann den gesamten Seitenaufbau verhindern. Besonders bei Child-Themes, die nach einem Update des Parent-Themes nicht mehr kompatibel sind, tritt das häufig auf.

PHP-Speicherlimit erreicht: WordPress und seine Plugins benötigen Arbeitsspeicher. Wenn das PHP-Speicherlimit zu niedrig eingestellt ist, bricht die Seitenausführung ab – ohne Fehlermeldung. Standardmäßig sind bei vielen Hostern nur 64 MB oder 128 MB konfiguriert, was bei umfangreichen Websites nicht ausreicht.

PHP-Fehler im Code: Ein Syntaxfehler in einer Plugin- oder Theme-Datei – etwa eine fehlende Klammer oder ein falsch geschriebener Funktionsname – führt zu einem fatalen PHP-Fehler. WordPress kann die Seite dann nicht mehr aufbauen.

Veraltete PHP-Version: Manche Plugins oder Themes sind nicht mit neueren PHP-Versionen kompatibel. Wenn Ihr Hoster die PHP-Version aktualisiert hat, kann das zu Inkompatibilitäten führen. Umgekehrt können auch zu alte PHP-Versionen Probleme verursachen, wenn Plugins neuere PHP-Funktionen verwenden.

Beschädigte Core-Dateien: Selten, aber möglich – beschädigte oder fehlende WordPress-Core-Dateien können den White Screen auslösen. Das passiert etwa bei einem abgebrochenen Update oder nach einem Hack.

Schritt-für-Schritt: So beheben Sie den White Screen of Death

  • Debug-Modus aktivieren

    Schritt 1

    Verbinden Sie sich per FTP oder über den Dateimanager Ihres Hosters mit Ihrem Webspace. Öffnen Sie die Datei wp-config.php im WordPress-Hauptverzeichnis und suchen Sie die Zeile:

    define('WP_DEBUG', false);

    Ändern Sie diese in:

    define('WP_DEBUG', true); 
    define('WP_DEBUG_LOG', true);
    define('WP_DEBUG_DISPLAY', false);

    Laden Sie die Seite neu. Der Fehler wird jetzt in die Datei wp-content/debug.log geschrieben. Öffnen Sie diese Datei – die letzte Zeile zeigt Ihnen in der Regel, welches Plugin oder welche Datei das Problem verursacht.

  • Plugins deaktivieren

    Schritt 2

    Wenn der Debug-Log auf ein Plugin hinweist, benennen Sie den Plugin-Ordner per FTP um. Navigieren Sie zu wp-content/plugins/ und benennen Sie den Ordner des verdächtigen Plugins um, z.B. von „contact-form-7″ zu „contact-form-7-deaktiviert“. Laden Sie die Seite neu.

    Falls Sie nicht wissen, welches Plugin schuld ist, benennen Sie den gesamten Ordner wp-content/plugins/ um, z.B. in „plugins-backup“. Damit werden alle Plugins auf einen Schlag deaktiviert. Wenn die Seite danach wieder lädt, benennen Sie den Ordner zurück und deaktivieren die Plugins einzeln, bis Sie den Übeltäter gefunden haben.

  • Theme wechseln

    Schritt 3

    Wenn das Deaktivieren aller Plugins nicht hilft, ist möglicherweise das Theme schuld. Benennen Sie Ihren Theme-Ordner unter wp-content/themes/ um. WordPress fällt dann automatisch auf ein Standard-Theme zurück (z.B. Twenty Twenty-Four). Wenn die Seite danach funktioniert, liegt das Problem im Theme.

  • PHP-Speicherlimit erhöhen

    Schritt 4

    Fügen Sie in der wp-config.php folgende Zeile hinzu (vor der Zeile „That’s all, stop editing!“):

    define('WP_MEMORY_LIMIT', '256M');

    Alternativ können Sie das Speicherlimit auch in der .htaccess-Datei setzen:

    php_value memory_limit 256M

    Bei manchen Hostern müssen Sie das Limit über die Hosting-Verwaltungsoberfläche anpassen.

  • Core-Dateien prüfen

    Schritt 5

    Laden Sie eine frische Kopie von WordPress von wordpress.org herunter. Ersetzen Sie die Ordner wp-admin/ und wp-includes/ auf Ihrem Server durch die frischen Dateien. Wichtig: Ersetzen Sie nicht den Ordner wp-content/ – dort liegen Ihre Themes, Plugins und Medien.

Vorbeugen ist besser als reparieren

Der White Screen of Death lässt sich in den meisten Fällen vermeiden:

Aktualisieren Sie Plugins und Themes nicht alle gleichzeitig, sondern einzeln – so können Sie Probleme sofort dem richtigen Update zuordnen. Erstellen Sie vor jedem Update ein vollständiges Backup (Dateien und Datenbank). Nutzen Sie eine Staging-Umgebung, um Updates zuerst in einer Testumgebung zu prüfen. Und halten Sie Ihre PHP-Version auf einem aktuellen, aber stabilen Stand (aktuell PHP 8.3, 8.4 oder 8.5).

Ein regelmäßiger WordPress-Wartungsvertrag nimmt Ihnen diese Arbeit ab. Updates werden kontrolliert eingespielt, tägliche Backups erstellt und Probleme erkannt, bevor sie zu Ausfällen führen.

Wann Sie einen Profi hinzuziehen sollten

Wenn die oben genannten Schritte nicht helfen, der Debug-Log kryptische Fehlermeldungen zeigt, Sie keinen FTP-Zugang haben oder sich unsicher sind – dann verschwenden Sie keine Zeit mit Experimentieren. Jede Stunde, die Ihre Website offline ist, kostet Sie potentielle Kunden und Umsatz.

Ich repariere WordPress-Websites zum Festpreis – schnell, zuverlässig und ohne versteckte Kosten. Melden Sie sich direkt bei mir und Ihre Website läuft wieder.

Das Problem besteht noch?

Wenn Sie den Fehler nicht selbst beheben können oder unsicher sind, wo die Ursache liegt: Ich helfe Ihnen gerne. In den meisten Fällen kann ich das Problem innerhalb weniger Stunden identifizieren und beheben – zum Festpreis, ohne versteckte Kosten.

Weiterlesen

WordPress gehackt – was tun? Soforthilfe für Ihre Website

WordPress gehackt – was tun? Soforthilfe für Ihre Website

Ihre WordPress-Website zeigt plötzlich fremde Inhalte, leitet auf dubiose Seiten weiter oder Google warnt vor Malware? Dann wurde Ihre Seite wahrscheinlich gehackt. Das ist ärgerlich – aber kein Grund zur Panik. In diesem Beitrag erkläre ich Ihnen Schritt für Schritt, was Sie jetzt tun sollten.

Ich bin WordPress-Entwickler seit 2009 und habe in den letzten Jahren dutzende gehackte Websites wiederhergestellt. Die gute Nachricht: In den meisten Fällen lässt sich der Schaden vollständig beheben.

Typische Anzeichen: Wurde meine WordPress-Seite gehackt?

Nicht immer ist ein Hack sofort offensichtlich. Manchmal bemerken Sie es erst, wenn Google Ihre Seite abstraft oder ein Besucher Sie darauf hinweist. Hier sind die häufigsten Anzeichen:

Ihre Website leitet Besucher automatisch auf fremde Seiten weiter – oft auf Glücksspiel- oder Pharma-Seiten. Es erscheinen plötzlich fremde Inhalte, Links oder Pop-ups. Google zeigt den Hinweis „Diese Website wurde möglicherweise gehackt“. Ihr Hosting-Anbieter hat Ihre Seite gesperrt. Sie können sich nicht mehr einloggen, obwohl Ihre Zugangsdaten korrekt sind. Es tauchen Benutzerkonten auf, die Sie nicht angelegt haben. Oder Ihre Seite zeigt die Meldung „Error establishing a database connection“.

Wenn eines oder mehrere dieser Anzeichen zutreffen, sollten Sie sofort handeln.

Schritt 1: Ruhe bewahren und Seite offline nehmen

Der wichtigste erste Schritt: Nehmen Sie Ihre Website offline, bevor weiterer Schaden entsteht. Damit schützen Sie Ihre Besucher vor Malware und verhindern, dass Google Ihre Seite weiter abstraft.

Am einfachsten geht das über Ihren Hosting-Anbieter. Rufen Sie dort an und bitten Sie darum, die Seite vorübergehend zu deaktivieren. Alternativ können Sie eine Wartungsseite (Maintenance Mode) aktivieren, wenn Sie noch Zugang zum Dashboard haben.

Was Sie jetzt auf keinen Fall tun sollten: Einfach weitermachen und hoffen, dass das Problem von alleine verschwindet. Das wird es nicht. Hacker richten Backdoors ein – versteckte Zugänge, über die sie jederzeit wieder reinkommen.

Schritt 2: Passwörter sofort ändern

Ändern Sie umgehend alle relevanten Passwörter. Das betrifft nicht nur Ihr WordPress-Login, sondern auch den FTP-Zugang zu Ihrem Server, Ihre Datenbank-Passwörter, das Passwort Ihres Hosting-Kundenbereichs und die E-Mail-Adresse, die mit dem WordPress-Admin-Konto verknüpft ist.

Verwenden Sie sichere Passwörter mit mindestens 16 Zeichen, Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen. Ein Passwort-Manager hilft, den Überblick zu behalten.

Schritt 3: Backup sichern

Bevor Sie irgendetwas reparieren, sichern Sie den aktuellen Stand Ihrer Website – auch wenn er kompromittiert ist. Warum? Weil Sie bei der Bereinigung möglicherweise Inhalte verlieren, die Sie später wiederherstellen möchten.

Erstellen Sie ein vollständiges Backup inklusive Datenbank und allen Dateien. Wenn Ihr Hoster automatische Backups anlegt, prüfen Sie ob ein sauberes Backup von vor dem Hack existiert. Das ist Gold wert, denn ein sauberes Backup macht die Wiederherstellung deutlich einfacher.

Schritt 4: Malware finden und entfernen

Jetzt wird es technisch. Die Malware muss gefunden und restlos entfernt werden. Das ist der schwierigste Teil, denn Hacker verstecken ihren Code oft an mehreren Stellen gleichzeitig.

Typische Verstecke für Malware sind die Datei wp-config.php, die functions.php Ihres Themes, der Ordner wp-content/uploads (dort werden PHP-Dateien versteckt), unbekannte Dateien im Hauptverzeichnis und manipulierte Plugin-Dateien.

Suchen Sie nach PHP-Funktionen wie eval(), base64_decode(), gzinflate() oder str_rot13(). Diese werden von Hackern genutzt, um schädlichen Code zu verschleiern. Auch Dateien mit zufälligen Buchstabenkombinationen als Namen (z.B. xkdf83.php) sind verdächtig.

Wenn Sie ein sauberes Backup haben, ist der schnellste Weg: WordPress komplett neu installieren, sauberes Backup der Datenbank einspielen und alle Plugins und Themes frisch vom Anbieter herunterladen.

Schritt 5: Sicherheitslücken schließen

Die Malware zu entfernen reicht nicht – Sie müssen auch das Einfallstor schließen. Sonst steht der Hacker morgen wieder vor der Tür.

Die drei häufigsten Einfallstore sind veraltete Plugins (mit Abstand die häufigste Ursache), schwache Passwörter (besonders bei Benutzernamen wie „admin“) und eine veraltete WordPress-Version.

Nach der Bereinigung sollten Sie WordPress, alle Plugins und Ihr Theme aktualisieren. Löschen Sie alle Plugins und Themes, die Sie nicht aktiv nutzen – deaktivieren reicht nicht. Prüfen Sie Ihre Benutzerliste auf unbekannte Konten. Deaktivieren Sie XML-RPC, wenn Sie es nicht benötigen. Schützen Sie Ihre wp-login.php mit einer zusätzlichen Authentifizierung.

Schritt 6: Google informieren

Wenn Google Ihre Website als gehackt markiert hat, müssen Sie nach der Bereinigung eine erneute Überprüfung beantragen. Das geht über die Google Search Console unter dem Punkt „Sicherheitsprobleme“. Google prüft Ihre Seite dann erneut und entfernt die Warnung, wenn alles sauber ist. Das kann einige Tage dauern.

Damit es nicht wieder passiert

Ein Hack ist immer auch ein Weckruf. Ihre Website braucht regelmäßige Pflege – genau wie ein Auto regelmäßig zum TÜV muss. Dazu gehören zeitnahe Updates von WordPress, Plugins und Themes, tägliche Backups die extern gespeichert werden, Sicherheitsmonitoring und regelmäßige Malware-Scans sowie starke Passwörter und eingeschränkte Benutzerrechte.

Genau das leiste ich mit meinen WordPress-Wartungsverträgen. Damit wird Ihre Website regelmäßig aktualisiert, überwacht und gesichert – bevor Probleme entstehen.

Sie brauchen sofort Hilfe?

Wenn Ihre WordPress-Website gehackt wurde und Sie sich die Bereinigung nicht selbst zutrauen: Ich übernehme das für Sie. Schnell, gründlich und zum Festpreis. Rufen Sie mich an oder schreiben Sie mir – in den meisten Fällen ist Ihre Seite innerhalb weniger Stunden wieder sauber und sicher.

Weiterlesen