Un seul gestionnaire wp_ajax_ qui enregistre des réglages sans check_ajax_referer() permet à un autre site de faire modifier ces réglages par un administrateur connecté, et n'importe quel abonné peut l'appeler si current_user_can() est absent. Un register_rest_route() avec DELETE et sans permission_callback est ouvert à tout Internet, et "WHERE id = " . $_GET['id'] dans une requête $wpdb est une injection SQL même après sanitize_text_field(). Ce sont les erreurs à l'origine de la plupart des avis de sécurité sur les extensions. Ce skill les détecte, ainsi que les autres erreurs d'extensions WordPress ci-dessous, avant que vous ne publiiez ou ne soumettiez sur WordPress.org, et vous indique comment corriger chacune d'elles.

Votre agent exécute un scanner sur le dossier de l'extension ou du thème : chaque fichier .php et le readme.txt de l'extension. Il suit les données de requête ($_GET, $_POST, $_REQUEST, $_COOKIE, $_FILES, en-têtes de requête, filter_input(), paramètres de requête REST) à travers les affectations, les boucles foreach, les ternaires, wp_unslash() et la construction de chaînes à l'intérieur de chaque fonction, et sait quelles fonctions WordPress assainissent (sanitize_text_field, absint, sanitize_key), échappent (esc_html, esc_attr, esc_url, wp_kses_post) ou préparent (espaces réservés de $wpdb->prepare) une valeur. Il associe les hooks add_action(), les pages d'administration et les routes REST à leurs gestionnaires par leur nom dans tous les fichiers, y compris le chargeur de hooks du boilerplate d'extension et les fonctions d'aide de nonce ou de permission appelées par le gestionnaire. Les exemples du manuel des extensions (AJAX avec check_ajax_referer, la page de réglages, les points de terminaison REST avec __return_true sur les routes GET, le contrôleur REST) ne sont pas signalés comme BLOCK. Il n'exécute jamais PHP ni WordPress. Il renvoie BLOCK, REVIEW ou NOT FLAGGED, avec le fichier, la ligne, la raison et une approche plus sûre. Les secrets présents dans les lignes affichées ne sont jamais imprimés.

Ce qui est vérifié

BLOCK (à corriger avant la mise en production)

• W01 : requêtes $wpdb (query, get_results, get_row, get_var, get_col, ou la chaîne de requête passée à prepare) construites avec des données de requête qui n'ont pas été converties en nombre ni passées comme espace réservé
• W02 : routes REST avec les méthodes POST, PUT, PATCH ou DELETE et sans permission_callback (lorsque le callback vérifie lui-même current_user_can(), c'est W12)
• W03 : gestionnaires wp_ajax_, admin_post_, de page d'administration et admin_init qui modifient des données en fonction de la requête sans vérification de nonce, y compris les résultats de wp_verify_nonce() ignorés et les vérifications qui ne s'exécutent que si le champ nonce est présent (les gestionnaires également enregistrés pour wp_ajax_nopriv_ sont publics par conception et relèvent de W11)
• W04 : données de requête affichées avec echo, print, les balises d'echo courtes, printf, _e ou wp_die sans échappement, y compris $_SERVER['PHP_SELF'], REQUEST_URI et les en-têtes de requête
• W05 : données de requête dans unserialize(), maybe_unserialize(), extract(), include ou require, eval(), call_user_func(), un nom de fonction variable ou une commande shell
• W06 : noms d'options et clés de métadonnées utilisateur pris dans la requête (update_option, delete_option, update_user_meta et similaires), ou un tableau $_POST entier passé à wp_update_user()

REVIEW (à vérifier avant la publication)

• W11 : gestionnaires qui modifient des données sans current_user_can() (wp_ajax_ et admin_post_ pour tout utilisateur connecté ; wp_ajax_nopriv_, admin_init et init pour les réglages, les utilisateurs, les extensions et les fichiers), y compris is_admin() utilisé comme vérification de permission
• W12 : routes GET sans permission_callback, routes d'écriture dont le permission_callback est __return_true, renvoie toujours true ou est is_user_logged_in, et routes d'écriture qui n'en ont pas et dont le callback vérifie lui-même current_user_can()
• W13 : données de requête enregistrées avec update_option, update_post_meta, update_user_meta ou set_theme_mod sans fonction d'assainissement, et register_setting() sans sanitize_callback
• W14 : sortie non échappée de get_option, get_post_meta, get_user_meta, get_theme_mod, get_transient, add_query_arg(), remove_query_arg(), get_query_var(), des paramètres REST et des données de requête qui ont seulement été assainies
• W15 : requêtes $wpdb assemblées à partir de paramètres REST ou de données de requête échappées avec esc_sql()/esc_like() au lieu de prepare()
• W16 : appels de fichiers (unlink, readfile, file_get_contents, fopen, file_put_contents, copy, rename, $wp_filesystem) avec des chemins issus de la requête, move_uploaded_file() sans vérification du type de fichier, et wp_handle_upload() avec 'test_type' => false
• W17 : vérifications TLS désactivées : 'sslverify' => false, CURLOPT_SSL_VERIFYPEER ou CURLOPT_SSL_VERIFYHOST désactivé, 'verify_peer' => false, le filtre https_ssl_verify qui renvoie false (les requêtes en boucle locale vers le site lui-même ne sont pas signalées)
• W18 : fichiers PHP d'extension qui exécutent du code avant toute vérification d'ABSPATH, et uninstall.php sans vérification de WP_UNINSTALL_PLUGIN (des protections comme if ( ! defined( 'ABSPATH' ) ) { header( ... ); exit; } et la vérification ! function_exists( 'add_action' ) d'Akismet sont acceptées)
• W19 : problèmes d'en-tête de readme.txt : pas de ligne === Plugin Name ===, Contributors, Tested up to, Stable tag ou License manquant, Stable tag: trunk, un Stable tag différent de Version dans le fichier principal de l'extension, un Tested up to antérieur aux trois dernières versions majeures de WordPress, plus de 5 tags, une description courte de plus de 150 caractères, le texte par défaut du modèle

Contenu fourni

• Le scanner (Python 3.9+, bibliothèque standard uniquement)
• Un guide des règles avec la raison, l'approche plus sûre et la source officielle WordPress ou PHP pour chaque règle
• Un exemple d'extension risquée et un exemple sûr (fichier principal, gestionnaires AJAX et REST, readme.txt), ainsi que le vrai rapport produit par le scanner sur l'exemple risqué

Limites

Il lit chaque fichier tel qu'il est écrit. Les données de requête sont suivies à l'intérieur d'une seule fonction ; les valeurs transmises entre fonctions, stockées dans des propriétés de classe par une autre méthode ou passées par des filtres ne sont pas suivies, et la sortie des fonctions qu'il ne connaît pas est considérée comme sûre. Les hooks dont les noms ou les callbacks sont construits à l'exécution, ainsi que les vérifications de nonce ou de capacité situées à plus d'un appel du gestionnaire, ne sont pas vus. Les fichiers JavaScript, block.json et les dossiers vendor et tests ne sont pas lus. Les fichiers qui ne font que définir des classes ou des fonctions ne sont pas tenus d'avoir une protection ABSPATH (Plugin Check est plus strict sur ce point), et les fichiers de thème ne sont pas vérifiés à ce sujet. Tested up to est comparé à une date limite : 6.9, la plus ancienne des trois dernières versions majeures en novembre 2026. NOT FLAGGED n'est pas une garantie.

Contenu de l'archive

Un fichier ZIP de 17 fichiers : SKILL.md, le scanner dans scripts/ (8 fichiers Python), references/rules.md (chaque règle avec sa raison et son approche plus sûre) et examples/ (6 fichiers d'exemple plus report.md, la vraie sortie du scanner sur l'exemple risqué).

Utilisation : Il s'agit d'un skill d'agent : un dossier contenant un fichier SKILL.md et des scripts Python qu'un agent de programmation IA comme Claude Code, Cursor ou Codex CLI peut exécuter. Décompressez-le dans le dossier des skills de votre agent (pour Claude Code : ~/.claude/skills/), puis demandez à votre agent de vérifier votre projet. Les scripts fonctionnent aussi seuls avec Python 3.9 ou plus récent, sans rien à installer. Ils se contentent de lire vos fichiers : aucun accès réseau, et rien n'est envoyé nulle part.