WordPress KI im Core: Abilities API & AI Client erklärt

1. Der AI Client (wp_ai_client_prompt()) – seit WP 7.0 im Core

Bisher musstest du für OpenAI, Google Gemini oder Anthropic eigene HTTP-Requests schreiben oder dich auf anbieterspezifische Plugin-Abstraktionen verlassen. Seit WordPress 7.0 gibt es dafür einen einheitlichen Weg im Core.

• Keine Installation nötig: Ab WordPress 7.0 ist alles an Bord. Die frühere Composer-Abhängigkeit wordpress/php-ai-client solltest du entfernen – der Core lädt die Bibliothek selbst, ein zweiter Autoloader führt zu doppelten Klassendefinitionen und damit zu Fatal Errors. Wer noch WordPress unter 7.0 unterstützen muss, lädt seinen Composer-Autoloader nur bedingt:

  if ( ! function_exists( 'wp_get_wp_version' )
      || version_compare( wp_get_wp_version(), '7.0', '<' ) ) {
      require_once __DIR__ . '/vendor/autoload.php';
  }

• Zwei Schichten: Unten arbeitet der plattformunabhängige PHP AI Client (camelCase, Exceptions), darüber der WordPress-Wrapper WP_AI_Client_Prompt_Builder (snake_case, WP_Error, WordPress-HTTP-Transport und Hooks).
• Vendor-Lock-in beendet: Du schreibst deinen Code einmal. Der Seitenbetreiber entscheidet unter Einstellungen › Connectors, welcher Anbieter und welches Modell genutzt werden. Um Zugangsdaten muss sich dein Plugin-Code gar nicht kümmern – das übernimmt die Connectors API.
• Der Core bringt keine Anbieter mit: Das ist der Punkt, der in der Praxis am häufigsten übersehen wird. WordPress liefert nur die Abstraktionsschicht; die Anbieter kommen als separate Plugins. Das WordPress-Projekt pflegt dafür drei offizielle Implementierungen: AI Provider for Anthropic, AI Provider for Google und AI Provider for OpenAI. Ohne Provider-Plugin und ohne API-Key passiert nichts.
• Einfaches Beispiel:

  // Einfacher Text-Prompt – Modell wird automatisch gewählt
  $text = wp_ai_client_prompt( 'Schreibe eine kurze Einleitung über WordPress.' )
      ->generate_text();
  
  if ( is_wp_error( $text ) ) {
      return; // Fehler behandeln – immer prüfen!
  }
  
  echo wp_kses_post( $text );

• Erweitertes Beispiel mit Optionen:

  $text = wp_ai_client_prompt( 'Optimiere diesen SEO-Titel.' )
      ->using_system_instruction( 'Du bist ein erfahrener SEO-Redakteur.' )
      ->using_temperature( 0.5 )
      ->using_max_tokens( 200 )
      ->generate_text();

• Vor dem Aufrufen prüfen, ob ein passendes Modell verfügbar ist:

  $prompt = wp_ai_client_prompt( 'Analysiere diesen Text auf Lesbarkeit.' );
  
  if ( $prompt->is_supported_for_text_generation() ) {
      $result = $prompt->generate_text();
  } else {
      // Fallback: Feature ausblenden oder Hinweis anzeigen
  }

  Diese Prüfung kostet nichts: Sie löst keinen API-Aufruf aus, sondern vergleicht die Builder-Konfiguration deterministisch mit den Fähigkeiten der konfigurierten Modelle. Verlasse dich niemals darauf, dass KI-Funktionen verfügbar sind, nur weil WordPress 7.0 installiert ist – auf den meisten Installationen ist gar kein Anbieter eingerichtet.

Der AI Client nutzt intern die WordPress HTTP API (wp_remote_request()) – kein anbieterspezifischer cURL-Code nötig. Neben generate_text() gibt es generate_image(), Sprachausgabe und Video, dazu strukturierte JSON-Antworten über as_json_response() und Modellwünsche über using_model_preference().

add_filter( 'wp_ai_client_prevent_prompt', function ( $prevent, $builder ) {
    // Nur Administratoren dürfen Prompts auslösen
    if ( ! current_user_can( 'manage_options' ) ) {
        return true;
    }
    return $prevent;
}, 10, 2 );

2. Die Abilities API – bereits in WordPress 6.9

Das ist der wahre Gamechanger für Automatisierung – und er ist bereits verfügbar. Die Abilities API (seit WordPress 6.9 im Core) definiert, was dein WordPress tun kann, und teilt dies der Außenwelt maschinenlesbar mit. Sie bringt ein neues funktionales Primitiv in WordPress: eine standardisierte und entdeckbare Art, wie Plugins ihre Funktionen anbieten. Wichtig: In WordPress 6.9 wurde nur die serverseitige (PHP) Implementierung ausgeliefert. Mit WordPress 7.0 kommt zusätzlich die Client-Side Abilities API, die Abilities auch im Browser standardisiert registrieren und ausführen kann – für noch reichere Workflows direkt im Editor.

• Ability registrieren:

  wp_register_ability( 'mein-plugin/erstelle-entwurf', array(
      'label'               => 'Beitragsentwurf erstellen',
      'category'            => 'content',
      'permission_callback' => function() {
          return current_user_can( 'edit_posts' );
      },
      'execute_callback'        => 'mein_plugin_erstelle_entwurf_callback',
      'input_schema'        => array(
          'type'       => 'object',
          'properties' => array(
              'titel'  => array( 'type' => 'string' ),
              'inhalt' => array( 'type' => 'string' ),
          ),
      ),
  ) );

• Function Calling ready: Abilities haben ein definiertes Input- und Output-Schema im JSON-Format. Ein KI-Modell kann diese Abilities als Werkzeuge (Function Calls) nutzen – die KI weiß dadurch, was sie in WordPress tun kann.
• MCP-Integration: Über den MCP Adapter werden registrierte Abilities direkt für externe KI-Assistenten (wie Claude oder ChatGPT) als Tools verfügbar – mit einem einzigen Meta-Parameter:

  wp_register_ability( 'mein-plugin/meine-ability', array(
      // ...
      'meta' => array(
          'mcp' => array(
              'public' => true, // Pflicht für MCP-Zugriff
          ),
      ),
  ) );

• Headless & Automatisierung: Externe Tools wie n8n, Make oder autonome KI-Agenten können die REST API abfragen, sehen die verfügbaren Abilities und können selbstständig Beiträge erstellen, übersetzen oder veröffentlichen.

3. Bildgenerierung als geplante Ability

Auch Bildgenerierung soll als registrierte Ability verfügbar werden. Die Roadmap des AI Experiments Plugins listet Bildgenerierung für Version 0.2.0. Das Prinzip folgt dem generellen Abilities-Muster: Eine registrierte Ability nimmt einen Prompt und eine gewünschte Bildgröße als Input entgegen, ruft den konfigurierten Bildanbieter auf und gibt die attachment_id des gespeicherten Bildes zurück.

• Das Bild wird physisch auf deinem Server gespeichert – kein externer Hosting-Dienst nötig.
• Der exakte Endpunkt und die finale API-Signatur werden mit dem offiziellen Release dokumentiert. Verlasse dich für produktiven Code nicht auf inoffizielle Vorschaupfade.
• Perfekt für automatisierte Workflows: Ein n8n-Agent kann Beitragstext generieren und ein passendes Titelbild erstellen lassen – alles über standardisierte Abilities-Endpunkte.

1. Die SQL-Injection: CVE-2026-60137

Der Parameter author__not_in von WP_Query – über die REST API als author_exclude erreichbar – wurde nicht korrekt typisiert. Wurde er statt als Array als einfacher String übergeben, landete sein Inhalt direkt in der zusammengesetzten SQL-Abfrage. Der Fehler kam mit WordPress 6.8 in den Core.

Das war für sich genommen bereits ernst, aber begrenzt: Eine Sperrliste verhinderte, dass unangemeldete Nutzer den Parameter überhaupt erreichen. GitHub bewertet die Lücke isoliert als moderat, die NVD-Einordnung liegt mit rund 9,1 deutlich höher – der Unterschied erklärt sich daraus, dass die NVD-Bewertung die Verkettung mitdenkt.

Die Lehre für eigenen Code: Niemals einen Query-Parameter ungeprüft in SQL geben. Für Listen von IDs gibt es wp_parse_id_list(), für einzelne Werte absint(). Und wenn du eine eigene Abfrage baust, gehört jeder Wert durch $wpdb->prepare().

// Falsch: Parameter wandert ungeprüft weiter
$ids = $request->get_param( 'exclude' );

// Richtig: erzwungene Typisierung auf eine Liste von Integern
$ids = wp_parse_id_list( $request->get_param( 'exclude' ) );

2. Die Routen-Verwirrung: CVE-2026-63030

Das ist der kritische Teil – und der eigentlich interessante. WordPress 6.9 hat einen Batch-Endpunkt eingeführt (/wp-json/batch/v1, alternativ ?rest_route=/batch/v1), mit dem ein Client mehrere API-Operationen in einem einzigen Request bündeln kann. Das ist genau die Art von Effizienz, die Automatisierung und Agenten-Workflows brauchen.

Der Batch-Prozessor in WP_REST_Server::serve_batch_request_v1() arbeitet in zwei getrennten Durchläufen: erst validieren, dann ausführen. Dabei pflegt er zwei parallele Arrays. Schlug die Pfad-Zerlegung eines Teil-Requests fehl, wurde der Fehler in das Validierungs-Array geschrieben – aber nicht in das Array der Routen-Treffer. Damit lief die Indizierung der beiden Arrays auseinander.

Die Folge: Jeder nachfolgende Teil-Request wurde dem falschen Handler zugeordnet. Ein Angreifer konnte damit einen Request unter dem Kontext einer anderen Route ausführen lassen – und so die Sperrliste umgehen, die die SQL-Injection auf angemeldete Nutzer beschränkte. Aus einer eingehegten Lücke wurde eine, die jeder aus dem offenen Internet erreicht.

Der Patch stellt sicher, dass Validierungs- und Request-Array zu jedem Zeitpunkt synchron bleiben. Bemerkenswert ist die Angriffsmechanik: Die eigentliche Schadlogik steckt in verschachtelten Teil-Requests im Body und ist im äußeren Request überhaupt nicht sichtbar – klassische Filterregeln greifen daher oft nicht.

Die Lehre für eigenen Code: Wer parallele Arrays führt, muss deren Ausrichtung nach jedem Fehlerfall prüfen. Ein Fehlerpfad, der in ein Array schreibt und in ein zweites nicht, ist ein Sicherheitsproblem, kein Schönheitsfehler.

Schritt 1: Version prüfen und aktualisieren

Im Backend unter Dashboard › Aktualisierungen. Alles außer 7.0.2, 6.9.5, 6.8.6 oder neuer ist verwundbar. Per WP-CLI geht es schneller und lässt sich über viele Installationen skripten:

# Aktuelle Version anzeigen
wp core version

# Innerhalb des eigenen Zweigs auf die neueste Fassung aktualisieren
wp core update --minor

# Danach verifizieren
wp core version
wp core verify-checksums

wp core update --minor bleibt bewusst im aktuellen Zweig: Eine 6.9.4 wird zu 6.9.5, nicht zu 7.0.2. Das ist bei einem Notfall-Update meist das gewünschte Verhalten, weil es keine Breaking Changes mitbringt. Für den Sprung auf 7.0 brauchst du mindestens PHP 7.4 – und einen ruhigen Moment, nicht diesen.

Auto-Updates aktiviert lassen. Genau für solche Fälle existiert der Hintergrund-Updater. Wer ihn abschaltet, tauscht Kontrolle gegen ein Zeitfenster, in dem die Seite offen steht.

Schritt 2: Wenn sofortiges Aktualisieren nicht geht

Nur als Überbrückung, nicht als Lösung: Der Batch-Endpunkt lässt sich auf Server- oder WAF-Ebene sperren. Beide Zugriffswege müssen abgedeckt sein – der Pfad und der Query-Parameter.

# Nginx
location ~* ^/wp-json/batch/v1 { return 403; }

if ( $arg_rest_route ~* "^/batch/v1" ) { return 403; }

# Apache (.htaccess)
RewriteEngine On
RewriteRule ^wp-json/batch/v1 - [F,L]
RewriteCond %{QUERY_STRING} rest_route=/batch/v1 [NC]
RewriteRule .* - [F,L]

Vorsicht: Der Block-Editor nutzt den Batch-Endpunkt für einige Speichervorgänge. Eine Sperre kann Redaktionsabläufe beschädigen. Sie ersetzt das Update nicht, sie kauft dir Stunden.

Am Rand notiert, weil es kursiert: Nach Analysen von Rapid7 und Cloudflare wird der Code-Execution-Pfad nur erreicht, wenn kein persistenter Object Cache aktiv ist. Ein Redis- oder Memcached-Setup war also weniger exponiert. Das ist eine interessante Beobachtung und kein Schutzkonzept – die SQL-Injection bleibt in jedem Fall erreichbar.

Schritt 3: Prüfen, ob es zu spät war

Weil die Ausnutzung Stunden nach der Veröffentlichung begann, empfiehlt Rapid7 ausdrücklich, auch nach dem Update nach Spuren zu suchen. Das Update entfernt keine Hintertür, die vorher gelegt wurde. Worauf zu schauen ist:

• Zugriffslogs nach Anfragen an /wp-json/batch/v1 oder rest_route=/batch/v1 durchsuchen, insbesondere zwischen dem 17. Juli und dem Zeitpunkt deines Updates.
• Auf SQL-Muster im Parameter author_exclude achten. Laut Patchstack trug rund drei Viertel der blockierten Anfragen dort einen Injection-Versuch. Typische Verschleierungen: wechselnde Groß-/Kleinschreibung, eingebettete Kommentare, MySQL-Conditional-Comments und URL-Kodierung – AnD, AND/**/, /*!AND*/.
• Dateiintegrität prüfen: wp core verify-checksums und wp plugin verify-checksums --all.
• Unbekannte PHP-Dateien suchen, vor allem im Upload-Verzeichnis, in dem eigentlich kein PHP liegen darf: find wp-content/uploads -name "*.php".
• Benutzerliste kontrollieren: wp user list --role=administrator – neu angelegte Admin-Konten sind ein klassisches Persistenz-Merkmal.
• Plugin-Liste kontrollieren auf Einträge, die niemand installiert hat.

Bei einem bestätigten Einbruch gilt Datenbankzugriff als gegeben: Passwörter aller Nutzer zurücksetzen, die Sicherheitsschlüssel und Salts in der wp-config.php erneuern (das wirft alle Sessions raus), das Datenbank-Passwort wechseln – und, falls die Seite bereits auf 7.0 mit eingerichteten Connectors lief, jeden KI-API-Key beim Anbieter widerrufen und neu ausstellen. Ein Key, der einmal in einer ausgelesenen Datenbank stand, ist verbrannt.