Zum Hauptinhalt springen

Autor: thorsten.koetzsch

WooCommerce barrierefrei machen: Die 8 häufigsten Fehler im Checkout und wie Sie sie beheben

WooCommerce barrierefrei machen: Die 8 häufigsten Fehler im Checkout und wie Sie sie beheben

Viele Shop-Betreiber denken bei Barrierefreiheit zuerst an Schriftgrößen und Farben. Die meisten echten Barrieren stecken aber woanders: im Warenkorb und im Checkout. Genau dort, wo aus einem Besuch ein Kauf werden soll.

Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz (BFSG) für viele Online-Shops, die an Verbraucher verkaufen. Maßstab ist in der Praxis die WCAG 2.1 in Stufe AA. In diesem Artikel zeige ich Ihnen die acht Fehler, die ich in WooCommerce-Shops am häufigsten sehe, welches WCAG-Kriterium jeweils betroffen ist und wie Sie sie beheben.

Wen betrifft das?

Ein barrierefreier Checkout hilft nicht nur blinden Menschen mit Screenreader. Er hilft auch Menschen, die nur mit der Tastatur arbeiten, die eine Bildschirmlupe nutzen, die schlecht sehen oder sich schwer konzentrieren können. Und er hilft allen, die gerade mit einer Hand am Smartphone bestellen. Jeder abgebrochene Kauf ist verlorener Umsatz.

Finger einer Person tasten über Brailleschrift.

Die 8 häufigsten Fehler im Checkout

1. Fehlermeldungen, die niemand mitbekommt

Das Problem: Ein Kunde vergisst die Postleitzahl und klickt auf „Zahlungspflichtig bestellen“. WooCommerce zeigt oben eine rote Liste mit Fehlern an. Wer einen Screenreader nutzt, bekommt davon oft nichts mit und weiß nicht, welches Feld betroffen ist.

WCAG: 3.3.1 Fehlererkennung, 3.3.3 Fehlerempfehlung

Die Lösung: Fehler werden direkt am Feld angezeigt, das Feld wird als fehlerhaft markiert (aria-invalid="true") und mit der Meldung verknüpft (aria-describedby). Noch besser: Die Meldung erscheint schon beim Verlassen des Feldes und nicht erst nach dem Absenden.

2. Die Gesamtsumme ändert sich still

Das Problem: Ändert ein Kunde die Versandart oder löst einen Gutschein ein, aktualisiert WooCommerce Versandkosten und Gesamtsumme. Sehende Kunden merken das. Screenreader-Nutzer hören nichts und bestellen womöglich zu einem anderen Preis als gedacht.

WCAG: 4.1.3 Statusmeldungen

Die Lösung: Eine sogenannte Live-Region (aria-live) sagt Änderungen an, zum Beispiel: „Warenkorb aktualisiert. Gesamtsumme 49,90 Euro.“

3. Der Fokus springt weg

Das Problem: Nach jeder Aktualisierung lädt WooCommerce Teile der Seite neu. Wer mit der Tastatur arbeitet, landet danach plötzlich am Seitenanfang und muss sich erneut bis zur richtigen Stelle durchtabben.

WCAG: 2.4.3 Fokus-Reihenfolge, 2.1.1 Tastatur

Die Lösung: Vor der Aktualisierung merkt sich der Shop, welches Element den Fokus hatte, und setzt ihn danach wieder dorthin.

4. Versand- und Zahlungsarten ohne Zusammenhang

Das Problem: Die Auswahl für Versand und Zahlung besteht aus Radiobuttons. Fehlt die Gruppierung, hört ein Screenreader-Nutzer nur „PayPal, Optionsfeld“ und weiß nicht, worum es eigentlich geht.

WCAG: 1.3.1 Info und Beziehungen

Die Lösung: Die Optionen werden als Gruppe ausgezeichnet, mit fieldset und legend oder mit role="radiogroup" und einer Beschriftung wie „Zahlungsart“.

5. Mengenfelder ohne Namen

Das Problem: Im Warenkorb gibt es für jedes Produkt ein Mengenfeld. Für den Screenreader heißen alle gleich, oft einfach nur „Menge“. Bei fünf Produkten ist nicht klar, welches Feld zu welchem Artikel gehört.

WCAG: 4.1.2 Name, Rolle, Wert und 2.4.6 Überschriften und Beschriftungen

Die Lösung: Jedes Feld bekommt einen eindeutigen Namen, zum Beispiel „Menge für Kaffeebohnen Espresso 500 g“. Dasselbe gilt für „Entfernen“-Links.

6. Pflicht-Checkboxen ohne Kennzeichnung

Das Problem: In deutschen Shops müssen Kunden meist AGB und Widerrufsbelehrung bestätigen. Diese Checkboxen sind oft nur mit einem roten Sternchen markiert, und das sagt der Screenreader nicht verständlich an.

WCAG: 3.3.2 Beschriftungen oder Anweisungen

Die Lösung: Die Checkbox wird technisch als Pflichtfeld gekennzeichnet (aria-required="true"), und das Sternchen wird im Text erklärt.

7. Fehlende Autovervollständigung

Das Problem: Der Browser kann Name, Adresse und E-Mail automatisch ausfüllen. Das funktioniert aber nur, wenn die Felder richtig ausgezeichnet sind. Für Menschen mit motorischen oder kognitiven Einschränkungen ist das eine große Erleichterung.

WCAG: 1.3.5 Bestimmung des Zwecks einer Eingabe

Die Lösung: Jedes Feld erhält das passende autocomplete-Attribut, zum Beispiel given-name, postal-code oder email.

8. Kaum sichtbarer Fokus und schwacher Kontrast

Das Problem: Viele Themes entfernen den Fokusrahmen, weil er „nicht schön aussieht“. Wer mit der Tastatur arbeitet, sieht dann nicht mehr, wo er sich befindet. Dazu kommen hellgraue Hinweistexte auf weißem Grund.

WCAG: 2.4.7 Fokus sichtbar, 1.4.3 Kontrast (Minimum), 1.4.11 Nicht-Text-Kontrast

Die Lösung: Ein gut sichtbarer Fokusrahmen mit ausreichendem Kontrast zum Hintergrund und Texte mit einem Kontrastverhältnis von mindestens 4,5 zu 1.

Sonderfall: Germanized und German Market

Viele deutsche Shops nutzen Germanized oder German Market, um rechtliche Anforderungen wie Grundpreise, Lieferzeiten oder die Bestätigung der AGB abzubilden. Diese Plugins verändern den Checkout spürbar: Sie fügen Checkboxen, Hinweistexte und manchmal eine eigene Bestellübersicht hinzu.

Prüfen Sie deshalb immer die Kombination aus Theme, WooCommerce und diesen Plugins. Ein Checkout, der mit dem Standard-Theme barrierefrei ist, kann mit Germanized schon wieder Lücken haben. Besonders oft betroffen sind die Pflicht-Checkboxen aus Fehler 6 und die Fehlermeldungen aus Fehler 1.

Die Checkliste für Ihren Checkout

Gehen Sie diese Punkte einmal selbst durch. Jedes „Nein“ ist eine Baustelle:

  • Kann ich den gesamten Kauf ohne Maus abschließen?
  • Sehe ich bei jedem Schritt, wo sich der Fokus befindet?
  • Werden Fehlermeldungen direkt am betroffenen Feld angezeigt?
  • Sagt der Screenreader Änderungen an der Gesamtsumme an?
  • Bleibt der Fokus nach einer Aktualisierung an der richtigen Stelle?
  • Sind Versand- und Zahlungsarten als Gruppe mit Überschrift erkennbar?
  • Hat jedes Mengenfeld und jeder „Entfernen“-Link einen eindeutigen Namen?
  • Sind Pflicht-Checkboxen auch ohne Farbe als Pflicht erkennbar?
  • Füllt der Browser Name, Adresse und E-Mail automatisch aus?
  • Lässt sich die Seite auf 200 Prozent vergrößern, ohne dass Inhalte verschwinden?

Warum Overlays keine Lösung sind

Vielleicht haben Sie schon Plugins gesehen, die eine Toolbar mit Schriftgröße und Kontrastmodus einblenden. Solche Overlays verändern den eigentlichen Code nicht. Die Fehler oben bleiben bestehen, denn Screenreader und Tastatur greifen auf den Code zu, nicht auf die Toolbar. Barrierefreiheit muss im Code umgesetzt werden.

Eine Person hält eine Kreditkarte und kauft am Laptop online ein.

So gehen Sie vor

  1. Selbst testen: Bestellen Sie einmal komplett nur mit der Tastatur. Kommen Sie ohne Maus bis zur Bestellbestätigung? Testen Sie zusätzlich mit einem Screenreader, zum Beispiel NVDA unter Windows oder VoiceOver auf dem Mac.
  2. Die häufigsten Fehler beheben: Für Warenkorb und Checkout habe ich das kostenlose Plugin Checkoutable entwickelt. Es behebt die oben beschriebenen Fehler direkt im Code, ohne Overlay, und jede Korrektur lässt sich einzeln abschalten.
  3. Den ganzen Shop prüfen lassen: Warenkorb und Checkout sind nur ein Teil. Produktseiten, Filter, Navigation und Kundenkonto gehören ebenso dazu. Mit dem BFSG-Schnellcheck prüfe ich Ihren Shop zum Festpreis und Sie erhalten eine priorisierte Liste, was zu tun ist.

Fazit

Die meisten Barrieren im WooCommerce-Checkout lassen sich mit überschaubarem Aufwand beheben. Wer jetzt handelt, verringert das Risiko bei Kontrollen und verkauft gleichzeitig an mehr Kunden.

Ob das BFSG für Ihren Shop gilt, klären Sie bitte mit Ihrer Rechtsberatung. Bei der technischen Umsetzung helfe ich Ihnen gern.

Schnellcheck anfragen

Weiterlesen

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

inqiro: Wie ich einen DSGVO-konformen KI-Chatbot für WordPress entwickelt habe

inqiro: Wie ich einen DSGVO-konformen KI-Chatbot für WordPress entwickelt habe

Von der Idee bis zur Veröffentlichung auf WordPress.org — ein Einblick in Architektur, Entwicklungsprozess und die Hürden des Plugin-Review-Prozesses.

Wer heute einen KI-Chatbot auf seiner WordPress-Website einbinden möchte, hat grundsätzlich zwei Möglichkeiten: Er nutzt einen externen Dienst wie Tidio, Intercom oder Chatbot.com — oder er findet etwas, das direkt in WordPress lebt, DSGVO-konform auf deutschen Servern läuft und die Inhalte seiner Website tatsächlich kennt. Die zweite Option gab es so nicht. Also habe ich sie gebaut.

Das Ergebnis heißt inqiro — ein KI-Chatbot-Plugin für WordPress, das seit März 2026 kostenlos im offiziellen WordPress.org-Verzeichnis verfügbar ist. In diesem Artikel beschreibe ich, wie das Plugin funktioniert, welche technischen Entscheidungen ich getroffen habe, warum WordPress.org mein Plugin dreimal abgelehnt hat — und was ich dabei gelernt habe.

Das Problem: Chatbots, die nichts wissen

Klassische Chatbot-Lösungen haben ein fundamentales Problem: Sie wissen nichts über die Website, auf der sie eingebunden sind. Sie beantworten generische Fragen, leiten den Besucher auf Kontaktformulare weiter oder geben Antworten, die nichts mit dem eigentlichen Angebot zu tun haben.

Der Grund ist technisch nachvollziehbar: Diese Dienste sind nicht mit den Inhalten der jeweiligen Website verbunden. Sie kennen keine Produkte, keine Preise, keine Öffnungszeiten, keine FAQs. Sie sind im Grunde genommen intelligente Weiterleitungsmaschinen.

Was ich gesucht habe, war etwas anderes: Ein Chatbot, der die Website liest, versteht und auf Basis dieser Inhalte antwortet — ohne manuelle Pflege, ohne Copy-Paste von FAQs, ohne externes Training.

Die Architektur: Wie inqiro funktioniert

Das Herzstück von inqiro ist ein dreistufiger Prozess: Crawlen, Verstehen, Antworten.

1. Content-Crawling
Nach der Installation scannt inqiro automatisch alle veröffentlichten Seiten, Beiträge und — sofern WooCommerce aktiv ist — auch Produkte. Der Crawler extrahiert den lesbaren Text, bereinigt ihn von HTML-Markup und teilt ihn in sogenannte Chunks auf: überschaubare Textabschnitte, die semantisch zusammengehören.

Dieser Prozess läuft in zwei Situationen automatisch: täglich über einen WordPress-Cron-Job und sofort, wenn ein Beitrag oder eine Seite veröffentlicht oder aktualisiert wird. Der Website-Betreiber muss nach der initialen Einrichtung nichts weiter tun.

2. Embeddings: Text wird zu Vektoren
Der zweite Schritt ist der entscheidende. Die gecrawlten Text-Chunks werden in sogenannte Embeddings umgewandelt — mathematische Vektoren, die die semantische Bedeutung eines Textes repräsentieren.

Was bedeutet das konkret? Zwei Texte, die inhaltlich ähnlich sind, erhalten ähnliche Vektoren — auch wenn sie nicht dieselben Wörter verwenden. Eine Frage wie „Wie viel kostet das?" und ein Produkttext mit „Preis: 49 Euro" werden als semantisch verwandt erkannt, obwohl sie keine gemeinsamen Wörter teilen.

Diese Vektoren werden in der WordPress-Datenbank gespeichert und ermöglichen eine blitzschnelle semantische Suche: Wenn ein Besucher eine Frage stellt, wird diese ebenfalls in einen Vektor umgewandelt und mit den gespeicherten Chunks verglichen. Die ähnlichsten Textabschnitte werden als Kontext an die KI übergeben.

3. Retrieval-Augmented Generation (RAG)
Das Verfahren dahinter heißt Retrieval-Augmented Generation, kurz RAG. Die KI erhält nicht einfach eine Frage — sie erhält die Frage zusammen mit den relevantesten Inhalten der Website als Kontext. Die Antwort basiert also auf echten Inhalten, nicht auf dem allgemeinen Weltwissen des Sprachmodells.

Das verhindert sogenannte Halluzinationen: Die KI erfindet keine Antworten, weil sie immer auf reale Textbausteine zurückgreift. Wenn eine Information nicht auf der Website vorhanden ist, sagt der Chatbot ehrlich, dass er es nicht weiß.

DSGVO-Konformität durch den deutschen Proxy-Server

Ein zentrales Designprinzip von inqiro ist der Datenschutz. Chat-Anfragen werden nicht direkt vom Browser des Besuchers an OpenAI oder Anthropic gesendet — sie laufen über einen zwischengeschalteten Lizenzserver, der in Deutschland gehostet wird.

Das hat mehrere Vorteile:

  • Die IP-Adresse des Besuchers erreicht die US-amerikanischen KI-Anbieter nicht direkt
  • Nutzungslimits werden zentral und fälschungssicher verwaltet
  • Ein vollständiger Auftragsverarbeitungsvertrag (AVV) gemäß Art. 28 DSGVO gilt automatisch
  • Der Datentransfer zu OpenAI und Anthropic ist über das EU-US Data Privacy Framework und Standardvertragsklauseln abgesichert

Chat-Daten selbst werden primär in der WordPress-Datenbank des jeweiligen Betreibers gespeichert — nicht auf meinen Servern. Diese Architektur unterscheidet inqiro grundlegend von US-amerikanischen Chatbot-Diensten, bei denen alle Gesprächsdaten auf fremden Servern landen.

Die technische Umsetzung

Das Plugin folgt dem WordPress-Coding-Standard und nutzt ausschließlich WordPress-native Funktionen: wpdb für Datenbankoperationen, wp_remote_post() für HTTP-Anfragen, wp_handle_upload() für Datei-Uploads. Auf externe PHP-Bibliotheken wurde bewusst verzichtet — keine Composer-Dependencies in der Produktionsversion.

Die Architektur ist in spezialisierte Klassen aufgeteilt:

  • INQIRO_Crawler — Content-Extraktion und Chunking
  • INQIRO_Embeddings — Vektorisierung und semantische Suche
  • INQIRO_Chat — Anfrageverarbeitung und KI-Routing
  • INQIRO_Widget — Frontend-Widget-Rendering
  • INQIRO_REST — REST-API-Endpunkte

JavaScript-Frontend ohne jQuery
Das Chat-Widget ist in Vanilla JavaScript geschrieben — keine jQuery-Abhängigkeit, kein Framework-Overhead. Das hält die Ladezeit minimal und verhindert Konflikte mit anderen Plugins oder Themes.

Das Widget unterstützt Streaming-Antworten: Die KI-Antwort erscheint Zeichen für Zeichen — ähnlich wie bei ChatGPT — anstatt als kompletter Block. Technisch geschieht das über Server-Sent Events (SSE) mit einem Character-Queue-System, das unabhängig von der Chunk-Größe der API-Antwort eine gleichmäßige Darstellung sicherstellt.

E2E-Testing mit Playwright
Das Plugin ist mit einer umfangreichen End-to-End-Test-Suite abgesichert, die über 350 Tests umfasst. Die Tests simulieren echte Browser-Interaktionen: Widget öffnen, Nachrichten senden, Bot-Antworten empfangen, Admin-Einstellungen ändern. Vor jedem Release läuft die komplette Suite durch — kein Commit ohne grünes Ergebnis.

Der WordPress.org Review-Prozess: Dreimal abgelehnt

Was ich unterschätzt hatte: Die Veröffentlichung im offiziellen WordPress.org-Plugin-Verzeichnis ist kein einfacher Upload-Prozess. Ein Team von Freiwilligen prüft jeden Plugin-Code manuell auf Einhaltung der Richtlinien. Mein Plugin wurde dreimal abgelehnt.

Runde 1: Automatischer Vorab-Check
Schon der erste automatische Scan scheiterte an einem Custom-Updater. WordPress.org-Plugins dürfen keinen eigenen Update-Mechanismus mitbringen — Updates laufen ausschließlich über das WordPress.org-SVN-Repository. Die Lösung war einfach: Die entsprechende Klasse wurde aus dem WordPress.org-Branch entfernt.

Runde 2: Manuelle Prüfung — die eigentliche Herausforderung
Die zweite Ablehnung traf härter. Die Reviewer hatten mehrere Probleme identifiziert:

Trialware-Verdacht: Das Plugin hatte im Admin-Bereich Einstellungsfelder, die für Free-Nutzer deaktiviert (ausgegraut) waren. WordPress.org verbietet das explizit — Guideline 5 besagt: Alle im Plugin enthaltenen Funktionen müssen vollständig nutzbar sein. Deaktivierte Features sind nicht erlaubt, auch wenn sie auf eine externe Bezahlversion hinweisen.

Meine Lösung: Statt das Plugin mit gesperrten Features vollzustopfen, habe ich für WordPress.org eine echte Lite-Version erstellt. Pro- und Business-spezifische Admin-Seiten wurden vollständig entfernt, nicht nur deaktiviert.

Inline-Scripts: Mehrere Templates enthielten <script>-Tags direkt im HTML. WordPress verlangt, dass JavaScript über wp_add_inline_script() eingebunden wird. Alle betroffenen Stellen wurden entsprechend umgeschrieben.

CDN-Abhängigkeit: Chart.js wurde von einem externen CDN geladen. WordPress.org verlangt, dass alle JavaScript-Bibliotheken lokal im Plugin gebündelt werden.

Kurze Präfixe: Alle Funktionen, Klassen und Optionen müssen eindeutige, mindestens vier Zeichen lange Präfixe haben. Mein ursprünglicher Präfix iq_ war zu kurz. Über 1.600 Vorkommnisse mussten auf inqiro_ umgeschrieben werden — inklusive einer Migrationsfunktion für bestehende Installationen.

ip-api.com ohne Opt-in: Das Plugin nutzte ip-api.com für Geo-Statistiken ohne explizite Nutzer-Einwilligung. WordPress.org wertet das als „Phoning Home". Die Funktion wurde hinter eine Opt-in-Einstellung gestellt, die standardmäßig deaktiviert ist.

Runde 3: Fast am Ziel
Die dritte Runde brachte noch zwei kleinere Probleme: move_uploaded_file() musste durch wp_handle_upload() ersetzt werden, und JS-Variablen mit zu kurzen Präfixen wurden beanstandet. Beide Punkte waren schnell behoben. Nach insgesamt rund sechs Wochen und drei Einreichungsrunden kam die Genehmigung.

Was ich aus dem Review-Prozess gelernt habe

Der WordPress.org Review-Prozess ist streng — und das ist gut so. Die Anforderungen existieren, weil schlechte Plugins echten Schaden anrichten können: Datenschutzverletzungen, Sicherheitslücken, irreführende Nutzerführung. Einige Lektionen für andere Plugin-Entwickler:

Trialware ist nicht erlaubt — aber Serviceware schon. Der entscheidende Unterschied: Wenn ein Feature lokal im Plugin-Code vorhanden ist, muss es vollständig nutzbar sein. Wenn ein Feature hingegen auf einem externen Server verarbeitet wird, darf es an eine Lizenz geknüpft sein. Das ist der Unterschied zwischen einem gesperrten Feature und einem Service.

Zwei getrennte Branches sind essenziell. main für die Vollversion, releases/wordpress_org für die Lite-Version. Ohne diese Trennung wird jeder Release zur Fehlerquelle.

Den Plugin Check Plugin nutzen. Das offizielle WordPress-Plugin-Check-Plugin identifiziert viele der häufigen Probleme bevor man einreicht. Es spart erheblich Zeit.

Präfixe von Anfang an richtig wählen. Nachträgliches Umbenennen von 1.600 Vorkommnissen ist mühsam. Mindestens vier Zeichen, eindeutig, konsequent.

Das Freemium-Modell: Was kostenlos ist, was nicht

inqiro ist auf WordPress.org als vollständig funktionsfähiges Free-Plugin verfügbar — kein Bait-and-Switch, keine deaktivierten Features. Die kostenlose Version enthält automatisches Content-Crawling, KI-Antworten basierend auf Website-Inhalten, ein anpassbares Chat-Widget, Gesprächsverlauf, DSGVO-Features und 50 Chats pro Monat.

Für professionelle Nutzung gibt es auf inqiro.de erweiterte Pläne:

  • Pro (29 €/Monat): 5.000 Chats, Lead-Erfassung, proaktive Nachrichten, Branding entfernen, Flow Builder
  • Business (79 €/Monat): 20.000 Chats, eigener API-Key, WooCommerce-Integration, Gesprächsübergabe an Agenten, Live-Chat-Inbox, Kalender-Integration

Für wen ist inqiro geeignet?

WordPress-Agenturen können inqiro als White-Label-Produkt für ihre Kunden einsetzen. Das Plugin lässt sich vollständig an das Corporate Design des jeweiligen Kunden anpassen — Farben, Bot-Name, Avatar, Begrüßungstext.

WooCommerce-Shops profitieren von der automatischen Produktkenntnis: Der Chatbot kann Produkte empfehlen, Preise nennen und Produkte direkt in den Warenkorb legen — ohne dass der Shopbetreiber die Produktdaten manuell einpflegen muss.

Arztpraxen und lokale Dienstleister schätzen besonders die DSGVO-Konformität und die Möglichkeit, häufige Patientenfragen automatisch zu beantworten — Öffnungszeiten, Leistungen, Anfahrt — ohne dass die Praxis dauerhaft erreichbar sein muss. Das Argument der deutschen Server und des automatisch geltenden AVV ist in diesem Segment besonders relevant.

Fazit

Der Weg von der ersten Zeile Code bis zur Veröffentlichung auf WordPress.org war länger und anspruchsvoller als erwartet — technisch, konzeptionell und im Hinblick auf die Einhaltung von Richtlinien. Das Ergebnis ist ein Plugin, das ich selbst täglich nutze und das echten Mehrwert für WordPress-Betreiber liefert.

Wenn Sie einen KI-Chatbot suchen, der Ihre Website tatsächlich kennt, DSGVO-konform auf deutschen Servern läuft und sich nahtlos in WordPress integriert — dann ist inqiro vielleicht genau das Richtige.

inqiro kostenlos herunterladen

inqiro für Ihre Website einrichten lassen?

Sie möchten inqiro professionell auf Ihrer Website einrichten lassen — mit Training auf Ihre Inhalte, individuellem Design und technischer Betreuung? Ich helfe Ihnen gerne weiter.

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

Fehler beim Aufbau einer Datenbankverbindung – WordPress reparieren

Fehler beim Aufbau einer Datenbankverbindung – WordPress reparieren

Sie öffnen Ihre Website und statt Ihrer Inhalte erscheint nur eine weiße Seite mit der Meldung „Fehler beim Aufbau einer Datenbankverbindung“ – oder auf Englisch „Error establishing a database connection“. Ihre Website ist komplett down. Keine Startseite, kein Dashboard, nichts.

Dieser Fehler ist einer der häufigsten WordPress-Probleme überhaupt. Er bedeutet, dass WordPress keine Verbindung zur MySQL-Datenbank herstellen kann – und ohne Datenbank funktioniert nichts, denn dort liegen alle Ihre Inhalte, Einstellungen und Benutzerdaten.

Die gute Nachricht: In den meisten Fällen lässt sich das Problem beheben, ohne dass Daten verloren gehen.

Ursache 1: Falsche Zugangsdaten in der wp-config.php

Das ist die mit Abstand häufigste Ursache. In der Datei wp-config.php stehen die Zugangsdaten für die Datenbank. Wenn dort ein falscher Datenbankname, Benutzername, Passwort oder Server eingetragen ist, kann WordPress keine Verbindung aufbauen.

Wann passiert das? Oft nach einem Umzug zu einem neuen Hoster, nach Änderungen am Hosting-Paket, wenn der Hoster die Datenbank-Server umstrukturiert oder wenn jemand versehentlich die Datei bearbeitet hat.

So prüfen Sie es: Verbinden Sie sich per FTP mit Ihrem Webspace und öffnen Sie die wp-config.php. Dort finden Sie vier relevante Zeilen:

define('DB_NAME', 'ihre_datenbank');
define('DB_USER', 'ihr_benutzername');
define('DB_PASSWORD', 'ihr_passwort');
define('DB_HOST', 'localhost');

Vergleichen Sie diese Werte mit den Datenbank-Zugangsdaten in Ihrem Hosting-Dashboard. Besonders der DB_HOST ist tückisch – bei manchen Hostern heißt er nicht „localhost“, sondern hat eine eigene Adresse.

Ursache 2: Der Datenbankserver ist nicht erreichbar

Manchmal liegt das Problem nicht bei Ihrer Website, sondern beim Datenbankserver Ihres Hosters. Das erkennen Sie daran, dass die Fehlermeldung plötzlich auftaucht, ohne dass Sie irgendetwas geändert haben.

Prüfen Sie zuerst die Statusseite Ihres Hosting-Anbieters nach aktuellen Störungen. Kontaktieren Sie den Support und fragen Sie gezielt: „Ist der MySQL-Datenbankserver erreichbar?“

In diesem Fall können Sie nur warten. Der Hoster muss das Problem auf seiner Seite beheben. Bei guten Hostern dauert das Minuten, bei schlechteren kann es Stunden dauern.

Ursache 3: Die Datenbank ist beschädigt

Eine beschädigte Datenbank kann verschiedene Ursachen haben – ein Serverabsturz während eines Schreibvorgangs, zu wenig Speicherplatz oder ein abgebrochenes Plugin-Update.

WordPress bietet eine eingebaute Reparaturfunktion. Fügen Sie folgende Zeile in Ihre wp-config.php ein:

define('WP_ALLOW_REPAIR', true);

Rufen Sie dann www.ihre-domain.de/wp-admin/maint/repair.php auf. Dort haben Sie zwei Optionen: „Datenbank reparieren“ und „Datenbank reparieren und optimieren“.

Wichtig: Entfernen Sie die Zeile unbedingt wieder aus der wp-config.php, sobald die Reparatur abgeschlossen ist. Diese Seite ist ohne Login erreichbar.

Ursache 4: Speicherlimit erreicht

WordPress und seine Plugins brauchen Arbeitsspeicher. Wenn das PHP Memory Limit zu niedrig gesetzt ist, kann die Datenbankverbindung fehlschlagen – besonders bei größeren Websites mit vielen Plugins.

Sie können das Memory Limit erhöhen:

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

Nicht jeder Hoster erlaubt diese Anpassung. Wenn die Änderung keine Wirkung zeigt, kontaktieren Sie Ihren Hoster und fragen Sie nach dem maximal verfügbaren PHP Memory Limit.

Ursache 5: Zu viele gleichzeitige Verbindungen

Wenn Ihre Website plötzlich viel Traffic bekommt oder ein Bot Ihre Seite aggressiv crawlt, kann die maximale Anzahl gleichzeitiger Datenbankverbindungen überschritten werden. Das ist besonders bei günstigen Shared-Hosting-Paketen ein Problem.

Anzeichen: Der Fehler tritt nur sporadisch auf, oder vor allem zu bestimmten Uhrzeiten, wenn der Server unter Last steht.

Kurzfristige Lösung: Caching-Plugin installieren (z.B. WP Super Cache), damit nicht bei jedem Seitenaufruf eine Datenbankabfrage nötig ist. Langfristige Lösung: Wechseln Sie auf ein besseres Hosting-Paket oder einen Managed-WordPress-Hoster.

Sonderfall: Gehackte Website

Ein oft übersehener Grund für Datenbankfehler: Ihre Website wurde gehackt. Manche Malware manipuliert die wp-config.php oder die Datenbank direkt. Wenn keine der oben genannten Ursachen zutrifft und der Fehler plötzlich auftritt, sollten Sie einen Hack nicht ausschließen.

In meinem Beitrag WordPress gehackt – was tun? erkläre ich, wie Sie einen Hack erkennen und was dann zu tun ist.

Vorbeugen ist besser als reparieren

Datenbank-Fehler treten seltener auf, wenn Ihre Website regelmäßig gewartet wird. Dazu gehören tägliche Backups, regelmäßige Updates und ein Monitoring, das Sie sofort informiert, wenn Ihre Seite nicht mehr erreichbar ist.

All das ist Teil meiner WordPress-Wartungsverträge. Sie müssen sich um nichts kümmern – ich behalte Ihre Website im Blick.

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