KI Code Sicherheitsreview WordPress: Meine Erfahrungen

KI Code Sicherheitsreview WordPress Erfahrungen aus der Praxis

Ein KI Code Sicherheitsreview gehört heute in jeden professionellen WordPress-Übergabeprozess. Nicht weil KI alles erkennt, sondern weil sie mechanische Schwachstellen schneller aufspürt als erschöpfte Augen nach einem langen Entwicklungssprint. Meine Erfahrungen mit vier verschiedenen Tools zeigen ein klares Bild: Jedes deckt andere Bereiche ab, kein einziges ersetzt den manuellen Abschlusscheck. Was jedes davon wirklich findet, was keines davon sieht - und eine Drei-Phasen-Prüfliste, die im Solo-Betrieb tatsächlich durchhaltbar ist.

Vibe-Coding erzeugt eine besondere Art von Sicherheitsschulden in WordPress

Die Zahl, bei der man kurz innehalten sollte: Sicherheitsforscher haben mithilfe von KI-gesteuerter statischer Analyse und automatisierter Verifikation über 300 kritische Zero-Days im WordPress-Plugin-Ökosystem in etwa 72 Stunden aufgedeckt. Keine obskuren Randplugins. Plugins mit beachtlichen Installationszahlen, die auf produktiven Kundenwebsites laufen.

Was treibt das an? Die kurze Antwort lautet Vibe-Coding: Entwickler liefern LLM-generierten Plugin-Code aus, den sie nicht vollständig gelesen haben. Das Modell produziert funktionale Logik schnell, manchmal beeindruckend schnell. Der Entwickler übergibt, ohne die Eingabevalidierung, die Nonce-Checks oder die Rechteverifikation geprüft zu haben. Das Ergebnis ist ein doppeltes Vertrauensproblem. Der Entwickler vertraut dem KI-Output. Dann vertraut dieser KI-Output Benutzereingaben ohne ausreichende Validierung.

Bei einer einfachen Broschürenseite bleibt das Risiko überschaubar. Bei einer WooCommerce-Installation, die echte Transaktionen verarbeitet, oder einem Multisite-Netzwerk mit Kunden-Subsites ist ein fehlender esc_html()-Aufruf oder ein nicht vorhandener current_user_can()-Check ein ernst zu nehmender Angriffspunkt. Eine externe Prüfung eines per Vibe-Coding erstellten Plugins ergab über 100 einzelne Sicherheitsprobleme in einer einzigen Codebase. Das ist keine seltene Ausnahme; das ist der Stand der Dinge in einem beträchtlichen Teil der neu entwickelten Plugins.

Was das konkret bedeutet: Ein Plugin, das Benutzerformulare verarbeitet und Daten in der Datenbank speichert, kann ohne einen einzigen bewussten Fehler des Entwicklers mehrere kritische SQL-Injections und XSS-Lücken enthalten. Der Entwickler hat nie böswillig gehandelt; er hat dem KI-Output vertraut, ohne zu prüfen, ob dieser Output WordPress-Sicherheitskonventionen kennt und korrekt anwendet.

Das ist kein Argument gegen KI-gestützte Entwicklung. Es ist ein Argument dafür, den Sicherheitsreview-Schritt als nicht optional zu betrachten - nicht als einen Schritt, den man ergänzt, wenn die Zeit es erlaubt. KI schreibt Code. Die Verantwortung für diesen Code liegt weiterhin beim Entwickler, der ihn ausliefert. Diese Verantwortung kann man nicht an das Modell delegieren, das ihn erzeugt hat.

Was KI-Prüfwerkzeuge in WordPress-PHP wirklich erkennen

KI-Sicherheitsprüfwerkzeuge scannen Codestruktur, kein Laufzeitverhalten. Diese Unterscheidung ist das Erste, was man verinnerlichen sollte, bevor man sie in einen Lieferprozess integriert. Wer das nicht versteht, wird von den Lücken kalt erwischt.

Wo sie bei WordPress-PHP zuverlässig leisten: fehlende esc_html-, esc_url- und wp_kses-Aufrufe, ungeschützte AJAX-Handler ohne check_ajax_referer oder Rechteprüfungen, rohe $wpdb->query-Aufrufe mit interpolierten Variablen, unsichere Dateioperationen mit benutzergelieferten Pfaden, ungeschützte update_option-Aufrufe. Das sind die klassischen PHP-Schwachstellenmuster, die in WordPress-spezifischen Regelwerken gut dokumentiert und in der Community bekannt sind.

Ein praktikabler Prompt für Cursor oder Claude Code bei WordPress-Plugins: Scanne den vollständigen Plugin-Code auf fehlende Eingabebereinigung, ungeschützte AJAX-Hooks, direkte SQL-Abfragen ohne Prepared Statements und Options-Updates ohne Capability-Check. Liste jeden Befund mit Dateiname und Zeilennummer. Diese Formulierung liefert auswertbare Ergebnisse, nicht eine allgemeine Sicherheitsbeschreibung.

Wo sie durchgehend unzuverlässig sind: Geschäftslogikfehler in der WooCommerce-Bestellverarbeitung, Race Conditions in der Bestandsverwaltung, Auth-Flow-Schwachstellen, die von der Ausführungsreihenfolge abhängen, kontextspezifische Probleme in Multisite-Umgebungen oder unter bestimmten Hosting-Einschränkungen. Diese Klasse von Problemen erfordert ein Verständnis der Geschäftsabsicht, das statische Analyse grundsätzlich nicht erbringen kann.

Das mentale Modell, das hilft: KI-Sicherheitsreview ist ein Erstfilter. Er hebt den Boden, nicht die Decke. Wer das versteht, setzt ihn richtig ein - als Schicht in einem Prozess, nicht als Ersatz für einen Prozess. Ein reifer Prüfprozess kombiniert statische Analyse, KI-gestützten Review und manuelle Verifikation; jede Schicht fängt das auf, was die vorherige übersehen hat.

Vier Tools, die in einem WordPress-Sicherheitsdurchlauf ihren Platz verdienen

SonarQube Community Edition bietet kostenlose, selbst gehostete PHP-Statikanalyse mit einer soliden Regelmaschine für WordPress-Schwachstellenmuster und Quality Gates für CI-Pipelines. Die Einschränkung: Der Einrichtungsaufwand macht es für einmalige Projektprüfungen ohne bestehende gemeinsame Instanz unpraktisch. Für Agenturen mit eigenem Server und regelmäßigem Prüfbedarf ist es die erste Wahl. Die kostenlose Community Edition reicht für PHP-Projekte und WordPress-spezifische Regeln aus; die bezahlten Editionen fügen Reporting und Branch-Analyse hinzu, die für Solo-Freiberufler in der Regel nicht erforderlich sind.

Cursor führt den Sicherheitsreview direkt im Entwicklungswerkzeug via Agent-Modus durch. Man gibt ihm einen fokussierten Prompt gegen ein vollständiges Plugin-Verzeichnis und erhält in wenigen Minuten eine strukturierte Auswertung der gefundenen Schwachstellen. Der Free-Tier ist für gelegentliche Nutzung ausreichend; Pro für 20 US-Dollar monatlich rechnet sich, sobald die Prüfarbeit regelmäßig ist. Der Vorteil gegenüber separaten Tools: kein Kontextwechsel, der Code bleibt offen, und Korrekturen lassen sich direkt vornehmen.

Tabnine ermöglicht On-Premises- und Air-Gap-Betrieb für volle Vertraulichkeit von Kundencode. Das ist die richtige Wahl, wenn NDAs oder die Datensensibilität der Kundenprojekte den Einsatz cloud-gehosteter KI-Tools ausschließen. Für Agenturen im Gesundheits-, Finanz- oder Behördenbereich ist das keine optionale Überlegung, sondern eine vertragliche oder regulatorische Anforderung. Die on-premises Variante erfordert eigene Serverinfrastruktur, liefert dafür aber volle Kontrolle über Datenflüsse.

Claude Code ermöglicht agentischen Review vollständiger Plugin-Verzeichnisse mit strukturiertem Output, der sauber genug ist, um ihn direkt an Kunden weiterzugeben. Die Ausgabe lässt sich als Markdown-Bericht exportieren und als Bestandteil der Übergabedokumentation nutzen. Die Falsch-Positiv-Rate bei WordPress-PHP ist nicht trivial: kontextabhängige Sicherheitsfunktionen wie current_user_can() werden manchmal als fehlend markiert, obwohl sie an anderer Stelle in der Ausführungskette gesetzt werden. Jeder Befund braucht manuelle Verifikation, bevor er in den offiziellen Prüfbericht einfließt.

Was KI konsistent übersieht - und die Haftung, die das schafft

Geschäftslogikfehler in WooCommerce-Abläufen sind für statische Analyse grundsätzlich unsichtbar. Das gilt für das Stapeln von Gutscheinen, die zusammen unbeabsichtigte Rabattkombinationen ermöglichen, genauso wie für Auth-Flow-Schwachstellen, die nur unter bestimmten Ausführungssequenzen auftreten. Diese Problemklasse erfordert menschliches Urteilsvermögen über Geschäftsabsicht und Ausführungskontext.

Ein konkretes Beispiel: Ein Plugin, das beim Checkout prüft, ob ein Gutschein gültig ist, tut das möglicherweise auf Basis des aktuellen Warenkorbstatus. Eine Race Condition beim parallelen Checkout von zwei Tabs führt dazu, dass der Check zweimal mit demselben validen Status läuft - und der Gutschein zweimal abgezogen wird. Kein statisches Analysewerkzeug erkennt dieses Muster, weil es keinen Codefehler im klassischen Sinne enthält.

Die Lage bei Offenlegungen ist nicht ermutigend: 52 Prozent der Plugin-Entwickler veröffentlichen keine Patches vor der öffentlichen Bekanntgabe einer Schwachstelle. Die mediane Zeit von der öffentlichen Bekanntgabe bis zur weitverbreiteten Ausnutzung liegt bei etwa fünf Stunden. Der Schluss daraus: Den Sicherheitsreview vor der Übergabe durchführen, nicht als Reaktion auf einen Meldungsbericht. Für Freiberufler, die mehrere Kundenwebsites parallel betreuen, bedeutet das: Eine einzige übersehene Schwachstelle in einem weit verbreiteten Plugin kann gleichzeitig mehrere Kundensites gefährden.

Eine Pre-Delivery-Prüfliste, die in der Praxis standhält

Phase 1 (15 Minuten): PHP_CodeSniffer mit WordPress-VIP-Go-Ruleset oder SonarQube. Alle kritischen Befunde schließen, bevor Phase 2 beginnt. Diese Phase ist maschinell, schnell und reproduzierbar. Die Ausgabe lässt sich direkt in die Übergabedokumentation übernehmen. Kritisch bedeutet hier: Befunde der Kategorien SQL Injection, XSS und Privilege Escalation haben absoluten Vorrang.

Phase 2 (20 Minuten): Cursor oder Claude Code, fokussierter Prompt auf Eingabebehandlung, AJAX-Schutz, Datenbankabfragen, Dateioperationen und Option-Management. Alle Befunde protokollieren, einschließlich verworfener Falsch-Positiver mit kurzer Begründung, warum sie verworfen wurden. Das Protokoll gehört zur Dokumentation der Übergabe - auch die Einträge, die man nicht weiterverfolgt hat.

Phase 3 (25 Minuten): Manueller Grenzstellenreview jedes AJAX-Endpoints, REST-Endpoints und Admin-Action-Hooks. Prüfen: Nonce-Check vorhanden und korrekt positioniert; Rechtecheck verwendet die geeignete Berechtigung für den jeweiligen Kontext; Eingabe vor der Verarbeitung bereinigt und vor der Ausgabe escaped. Dieser Schritt ist nicht automatisierbar. Er muss manuell und konzentriert durchgeführt werden - er ist der einzige Schritt, der Geschäftslogikprobleme aufdecken kann.

Das Protokoll aller drei Phasen wird zur Übergabedokumentation. Bei Kundenrückfragen oder späteren Prüfungen zeigt es, dass der Sicherheitsreview stattgefunden hat und nach einem nachvollziehbaren Verfahren durchgeführt wurde.

Die EU-Compliance-Frist, auf die die meisten Freiberufler nicht vorbereitet sind

Ab September 2026 verlangt die EU von Plugin- und Theme-Entwicklern, die an EU-Nutzer ausliefern, ein dokumentiertes Schwachstellen-Offenlegungsprogramm. Das umfasst einen definierten Reaktionszeitraum, einen dedizierten Sicherheitskontakt und ein dokumentiertes Verfahren für den Umgang mit gemeldeten Schwachstellen. Das gilt auch für private Plugins und Einzelkundenlösungen, nicht nur für öffentlich verbreitete Plugins im WordPress.org-Verzeichnis.

Ein protokollierter Drei-Phasen-Review ist Teil eines nachweisbaren Sorgfaltspflichtprozesses. Im Streitfall - bei einem Kundenvorfall oder einer Behördenanfrage - macht ein dokumentierter Prozess den Unterschied zwischen einer vertretbaren Vorgehensweise und einer, die man nicht erklären kann. Wer jetzt einen reproduzierbaren Prüfprozess einführt, ist zum Stichtag September 2026 nicht im Rückstand. Die Pflicht zur Dokumentation ist zugleich eine Gelegenheit: Ein nachvollziehbarer Sicherheitsprozess ist ein Qualitätsmerkmal gegenüber Kunden, die zunehmend nach Belegen für professionelle Sorgfalt fragen.

Wann ein gezielter Durchlauf verhältnismäßig ist - und wann nicht

Broschürenseite oder Block-Theme ohne eigene AJAX-Logik oder Datenverarbeitung: Der Drei-Phasen-Prozess ist der richtige Rahmen. Das Risikoprofil rechtfertigt keinen umfangreicheren Aufwand. Eigenes Plugin mit Authentifizierungslogik, Bestellverarbeitung, Dateiuploads oder privilegiertem Datenzugriff: Ein formales Review mit dokumentierten Befunden ist der angemessene Prüfumfang. Der Drei-Phasen-Prozess ist hier der Ausgangspunkt, nicht das Ende.

Der Prüfaufwand sollte dem Risiko entsprechen, das der Code im Produktionseinsatz trägt. Den Drei-Phasen-Prozess für ein einfaches Kontaktformular-Plugin anzuwenden ist sinnvoll; ihn für ein benutzerdefiniertes WooCommerce-Payment-Plugin als ausreichend zu betrachten, ist es nicht. Das ist die Unterscheidung, die in der Praxis zählt - und die im Streitfall erklärt werden muss.