Wie KI-Plugins für WordPress unsichere Sicherheitslücken erzeugen

LLMs wie ich werden oft genutzt, um schnell WordPress-Plugins zu erstellen. Doch die Ergebnisse sind nicht selten ein Sicherheitsrisiko: Nicht validierte Benutzereingaben, veraltete Funktionen und fehlende Zugriffskontrollen machen solche Automatisprodukte zu einem Problem für Entwickler und Site-Betreiber. Die Ursache liegt nicht in mangelnder Intelligenz der Modelle, sondern im grundlegenden Design des KI-Systems. Es generiert Code basierend auf statistischen Mustern aus Trainingsdaten – einschließlich veralteter oder unsicherer Code-Snippets aus Foren und Tutorials. Doch es gibt einen Ausweg: eine neue Architektur, die KI mit deterministischen Sicherheitsprüfungen kombiniert.

Warum KI-generierte WordPress-Plugins oft unsicher sind

WordPress-Plugins basieren auf Hooks und Filtern, die durch Aktionen und Filter definiert werden. Ein LLM generiert oft einen monolithischen Code-Block mit mehreren Hundert Zeilen – doch genau hier liegt das Problem. Typische Fehler sind:

• Fehlende Priorisierung bei Hook-Registrierung: Ein Plugin registriert einen Hook ohne korrekte Priorität, was zu unerwartetem Verhalten führen kann.
• Direkte Datenbankzugriffe mit ungesicherten Eingaben: Code wie $wpdb->query("UPDATE ... WHERE id = " . $_GET['id']) wird zwar ausgeführt, öffnet aber Tür und Tor für SQL-Injection-Angriffe.
• Veraltete Funktionen: Das Modell nutzt möglicherweise veraltete WordPress-Funktionen, die in neueren Versionen nicht mehr unterstützt werden.
• Fehlende Authentifizierung: AJAX-Handler oder REST-Endpunkte werden ohne permission_callback oder wp_verify_nonce() erstellt, was Angreifern die Kontrolle ermöglicht.

Diese Fehler entstehen nicht durch Nachlässigkeit der Entwickler, sondern durch die Art und Weise, wie LLMs Code generieren. Das Modell priorisiert statistische Plausibilität über Sicherheit – ein Muster, das aus veralteten oder unsachgemäßen Code-Beispielen in Trainingsdaten stammt.

Die Lösung: Eine mehrstufige Architektur für sicheren KI-Code

Um das Problem zu lösen, wurde eine Architektur entwickelt, die KI in einen deterministischen Prozess einbettet. Statt eines einzigen Generierungsaufrufs wird der Prozess in drei Phasen unterteilt:

Phase 1: Absichtserkennung und Blueprint-Erstellung

Bevor auch nur eine Zeile PHP-Code geschrieben wird, analysiert ein spezialisierter Agent die Benutzeranfrage und erstellt ein strukturiertes Blueprint-Dokument. Statt einer vagen Anfrage wie „Erstelle ein Plugin, das Beiträge zur Überprüfung markiert“ wird ein maschinenlesbares Manifest generiert, das folgende Details enthält:

{
  "plugin_slug": "beitrags-ueberpruefung",
  "capabilities_required": ["edit_others_posts"],
  "hooks": [
    {
      "type": "action",
      "name": "admin_menu",
      "callback": "register_ueberpruefung_seite"
    },
    {
      "type": "ajax",
      "name": "beitrag_markieren",
      "auth": "logged_in",
      "nonce": true
    }
  ],
  "data_layer": {
    "storage": "post_meta",
    "meta_key": "_ueberpruefung"
  },
  "files": [
    "beitrags-ueberpruefung.php",
    "includes/class-ueberpruefung-controller.php",
    "admin/views/ueberpruefung-liste.php"
  ]
}

Dieses Manifest dient als verbindliche Spezifikation. Es definiert nicht nur die Struktur des Plugins, sondern auch die Sicherheitsanforderungen – etwa ob eine Nonce für AJAX-Aufrufe erforderlich ist. Durch diese Vorab-Definition wird Sicherheit zu einer Planungsentscheidung, nicht zu einer nachträglichen Überprüfung.

Phase 2: Kontextbewusste Code-Generierung

Im nächsten Schritt wird das Blueprint in tatsächlichen PHP-Code umgewandelt. Ein weiterer Agent generiert die einzelnen Module – Controller, Datenbanklogik und View-Templates – als separate Dateien. Der entscheidende Unterschied: Der Agent arbeitet nicht isoliert, sondern berücksichtigt die Abhängigkeiten zwischen den Modulen. Ein in der Controller-Datei deklarierte Funktion ist dem Agenten bekannt, wenn er die View-Templates generiert.

Phase 3: Deterministische Sicherheitsprüfung

Nach der Code-Generierung kommt der kritische Schritt: die automatisierte Sicherheitsprüfung. Ein dedizierter Agent analysiert den generierten Code nicht durch subjektive Bewertung, sondern durch strukturierte Code-Analyse. Dabei werden folgende Regeln erzwungen:

• Jeder AJAX- oder REST-Endpunkt muss eine Zugriffskontrolle (current_user_can()) und eine Nonce-Prüfung (wp_verify_nonce()) enthalten.
• Alle Eingaben aus Superglobals (wie $_GET, $_POST) müssen vor der Verwendung sanitiert werden (sanitize_text_field(), esc_attr()).
• Dynamische Ausgaben müssen an der Stelle der Ausgabe escapet werden (spätes Escaping).

Falls eine dieser Regeln verletzt wird, wird der generierte Code zurückgewiesen und der Prozess wiederholt. Diese Phase stellt sicher, dass nur Code, der alle Sicherheitsanforderungen erfüllt, an den Entwickler ausgeliefert wird.

Fazit: KI und Sicherheit sind kein Widerspruch

Die Kombination aus KI-generiertem Code und strikten Sicherheitsprüfungen zeigt, dass es möglich ist, die Effizienz von LLMs zu nutzen, ohne dabei Sicherheitsrisiken in Kauf zu nehmen. Durch die Aufteilung des Prozesses in klar definierte Phasen – Blueprint-Erstellung, kontextbewusste Generierung und deterministische Auditierung – wird Sicherheit zu einem integralen Bestandteil des Workflows. Entwickler können sich auf die Kreativität der KI verlassen, während die Architektur sicherstellt, dass der generierte Code den höchsten Sicherheitsstandards entspricht. Die Zukunft von KI in der WordPress-Entwicklung liegt nicht in der reinen Automatisierung, sondern in der intelligenten Kombination von maschineller Intelligenz und menschlicher Sicherheitsvorsicht.