Ein einziger wp_ajax_-Handler, der Einstellungen ohne check_ajax_referer() speichert, erlaubt einer anderen Website, einen angemeldeten Admin diese ändern zu lassen, und jeder Abonnent kann ihn aufrufen, wenn current_user_can() fehlt. Eine register_rest_route() mit DELETE und ohne permission_callback steht dem gesamten Internet offen, und "WHERE id = " . $_GET['id'] in einer $wpdb-Abfrage ist auch nach sanitize_text_field() eine SQL-Injection. Das sind die Fehler hinter den meisten Sicherheitswarnungen zu Plugins. Dieser Skill findet sie und die weiteren unten aufgeführten Fehler in WordPress-Plugins, bevor Sie veröffentlichen oder bei WordPress.org einreichen, und erklärt Ihnen, wie Sie jeden davon beheben.

Ihr Agent führt einen Scanner über den Plugin- oder Theme-Ordner aus: jede .php-Datei und die readme.txt des Plugins. Er verfolgt Anfragedaten ($_GET, $_POST, $_REQUEST, $_COOKIE, $_FILES, Anfrage-Header, filter_input(), REST-Anfrageparameter) durch Zuweisungen, foreach-Schleifen, ternäre Ausdrücke, wp_unslash() und String-Aufbau innerhalb jeder Funktion und weiß, welche WordPress-Funktionen einen Wert bereinigen (sanitize_text_field, absint, sanitize_key), maskieren (esc_html, esc_attr, esc_url, wp_kses_post) oder vorbereiten ($wpdb->prepare-Platzhalter). Er ordnet add_action()-Hooks, Admin-Seiten und REST-Routen über alle Dateien hinweg anhand des Namens ihren Handlern zu, einschließlich des Hook-Loaders aus dem Plugin-Boilerplate und der Nonce- oder Berechtigungs-Helfer, die der Handler aufruft. Die Beispiele aus dem Plugin-Handbuch (AJAX mit check_ajax_referer, die Einstellungsseite, REST-Endpunkte mit __return_true auf GET-Routen, der REST-Controller) werden nicht als BLOCK gemeldet. Er führt nie PHP oder WordPress aus. Er liefert BLOCK, REVIEW oder NOT FLAGGED, jeweils mit Datei, Zeile, Begründung und einem sichereren Vorgehen. Geheimnisse in angezeigten Zeilen werden nie ausgegeben.

Was geprüft wird

BLOCK (vor der Auslieferung beheben)

• W01: $wpdb-Abfragen (query, get_results, get_row, get_var, get_col oder der an prepare übergebene Abfrage-String), die mit Anfragedaten gebaut werden, die weder in eine Zahl umgewandelt noch als Platzhalter übergeben wurden
• W02: REST-Routen mit den Methoden POST, PUT, PATCH oder DELETE und ohne permission_callback (wenn der Callback selbst current_user_can() prüft, ist es W12)
• W03: wp_ajax_-, admin_post_-, Admin-Seiten- und admin_init-Handler, die aufgrund der Anfrage Daten ändern, ohne eine Nonce zu prüfen, einschließlich ignorierter Ergebnisse von wp_verify_nonce() und Prüfungen, die nur laufen, wenn das Nonce-Feld vorhanden ist (Handler, die auch für wp_ajax_nopriv_ registriert sind, sind absichtlich öffentlich und werden W11 überlassen)
• W04: Anfragedaten, die ohne Maskierung mit echo, print, kurzen Echo-Tags, printf, _e oder wp_die ausgegeben werden, einschließlich $_SERVER['PHP_SELF'], REQUEST_URI und Anfrage-Headern
• W05: Anfragedaten in unserialize(), maybe_unserialize(), extract(), include oder require, eval(), call_user_func(), einem variablen Funktionsnamen oder einem Shell-Befehl
• W06: aus der Anfrage übernommene Optionsnamen und User-Meta-Schlüssel (update_option, delete_option, update_user_meta und ähnliche) oder ein ganzes $_POST-Array, das an wp_update_user() übergeben wird

REVIEW (vor dem Release prüfen)

• W11: Handler, die Daten ohne current_user_can() ändern (wp_ajax_ und admin_post_ für jeden angemeldeten Benutzer; wp_ajax_nopriv_, admin_init und init für Einstellungen, Benutzer, Plugins und Dateien), einschließlich is_admin() als Berechtigungsprüfung
• W12: GET-Routen ohne permission_callback, schreibende Routen, deren permission_callback __return_true ist, immer true zurückgibt oder is_user_logged_in ist, sowie schreibende Routen ohne permission_callback, deren Callback selbst current_user_can() prüft
• W13: Anfragedaten, die mit update_option, update_post_meta, update_user_meta oder set_theme_mod ohne Bereinigungsfunktion gespeichert werden, und register_setting() ohne sanitize_callback
• W14: nicht maskierte Ausgabe von get_option, get_post_meta, get_user_meta, get_theme_mod, get_transient, add_query_arg(), remove_query_arg(), get_query_var(), REST-Parametern sowie von Anfragedaten, die nur bereinigt wurden
• W15: $wpdb-Abfragen, die aus REST-Parametern oder aus mit esc_sql()/esc_like() maskierten Anfragedaten zusammengesetzt werden statt mit prepare()
• W16: Dateiaufrufe (unlink, readfile, file_get_contents, fopen, file_put_contents, copy, rename, $wp_filesystem) mit Pfaden aus der Anfrage, move_uploaded_file() ohne Prüfung des Dateityps und wp_handle_upload() mit 'test_type' => false
• W17: deaktivierte TLS-Prüfungen: 'sslverify' => false, CURLOPT_SSL_VERIFYPEER oder CURLOPT_SSL_VERIFYHOST aus, 'verify_peer' => false, der Filter https_ssl_verify, der false zurückgibt (Loopback-Anfragen an die eigene Website werden nicht gemeldet)
• W18: PHP-Dateien des Plugins, die Code vor jeder ABSPATH-Prüfung ausführen, und uninstall.php ohne WP_UNINSTALL_PLUGIN-Prüfung (Schutzabfragen wie if ( ! defined( 'ABSPATH' ) ) { header( ... ); exit; } und die Prüfung ! function_exists( 'add_action' ) von Akismet zählen)
• W19: Probleme im Kopf von readme.txt: keine Zeile === Plugin Name ===, fehlende Angaben zu Contributors, Tested up to, Stable tag oder License, Stable tag: trunk, ein Stable tag, der von Version in der Haupt-Plugin-Datei abweicht, Tested up to älter als die letzten drei großen WordPress-Releases, mehr als 5 Tags, eine Kurzbeschreibung über 150 Zeichen, der Standardtext der Vorlage

Was enthalten ist

• Der Scanner (Python 3.9+, nur Standardbibliothek)
• Ein Regelleitfaden mit Begründung, sichererem Vorgehen und offizieller WordPress- oder PHP-Quelle für jede Regel
• Ein riskantes und ein sicheres Beispiel-Plugin (Hauptdatei, AJAX- und REST-Handler, readme.txt) sowie der echte Bericht, den der Scanner für das riskante erzeugt

Einschränkungen

Er liest jede Datei so, wie sie geschrieben ist. Anfragedaten werden innerhalb einer Funktion verfolgt; Werte, die zwischen Funktionen übergeben, von einer anderen Methode in Klasseneigenschaften gespeichert oder durch Filter geleitet werden, werden nicht verfolgt, und die Ausgabe von Funktionen, die er nicht kennt, gilt als sicher. Hooks, deren Namen oder Callbacks zur Laufzeit gebildet werden, sowie Nonce- oder Berechtigungsprüfungen, die mehr als einen Aufruf vom Handler entfernt sind, werden nicht erkannt. JavaScript, block.json sowie vendor- und tests-Ordner werden nicht gelesen. Dateien, die nur Klassen oder Funktionen definieren, müssen keinen ABSPATH-Schutz haben (Plugin Check ist hier strenger), und Theme-Dateien werden darauf nicht geprüft. Tested up to wird mit einem datierten Stichtag verglichen: 6.9, das älteste der letzten drei großen Releases im November 2026. NOT FLAGGED ist keine Garantie.

Inhalt

Eine ZIP-Datei mit 17 Dateien: SKILL.md, der Scanner in scripts/ (8 Python-Dateien), references/rules.md (jede Regel mit Begründung und sichererem Vorgehen) und examples/ (6 Beispieldateien plus report.md, die echte Scanner-Ausgabe für das riskante Beispiel).

Verwendung: Dies ist ein Agent-Skill: ein Ordner mit einer SKILL.md-Datei und Python-Skripten, die ein KI-Coding-Agent wie Claude Code, Cursor oder Codex CLI ausführen kann. Entpacken Sie ihn in den Skills-Ordner Ihres Agenten (für Claude Code: ~/.claude/skills/) und bitten Sie dann Ihren Agenten, Ihr Projekt zu prüfen. Die Skripte laufen auch eigenständig mit Python 3.9 oder neuer, ohne dass etwas installiert werden muss. Sie lesen nur Ihre Dateien: kein Netzwerkzugriff, und nichts wird irgendwohin gesendet.