Ce que fait réellement wp2shell
Quand Adam Kues, d'Assetnote, a envoyé une requête forgée à une installation WordPress ordinaire, le serveur a exécuté son code. Pas de compte, pas de mot de passe, pas d'extension, pas de réglage inhabituel. Les chercheurs ont nommé la chaîne wp2shell, WordPress lui a attribué CVE-2026-63030 et les deux parties l'ont jugée critique.
L'exploit enchaîne deux faiblesses de la route batch de l'API REST : une confusion de routage qui laisse un appelant non authentifié atteindre des chemins de code censés être protégés, et une injection SQL accessible par ce biais. Enchaînées, elles transforment une requête HTTP anonyme en exécution de code, le pire résultat qu'une faille web puisse avoir.
Pourquoi le correctif automatique n'est pas la ligne d'arrivée
WordPress a publié 6.9.5 et 7.0.2 le 17 juillet 2026 et, vu la gravité, a imposé les mises à jour aux sites touchés plutôt que d'attendre un clic du propriétaire. C'est le bon choix, et la plupart des sites sont désormais fermés. Cela masque aussi la question la plus difficile.
Une faille sans authentification signifie que n'importe qui sur internet a pu l'utiliser avant votre correctif, et installer la correction n'annule pas cela. Si votre site était accessible et non corrigé pendant la fenêtre d'exposition, la mise à jour a retiré la porte mais pas ce qui était déjà entré : un compte administrateur glissé, une tâche planifiée, une webshell dans le dossier des téléversements.
Pourquoi presque chaque propriétaire est concerné
Cela vivait dans le coeur, le logiciel que chaque site WordPress exécute, donc l'exposition ne dépendait pas d'une extension ou d'un thème de niche. WordPress fait tourner près de 40 pour cent du web, et c'est pourquoi une seule faille du coeur de cette classe est un événement de masse et non un cas isolé.
Les versions 6.9.0 à 6.9.4 et 7.0.0 à 7.0.1 étaient vulnérables à wp2shell. Le second bug, une injection SQL dans le paramètre author__not_in de WP_Query notée CVSS 9.1, remonte à la 6.8, si bien qu'un site sans mise à jour depuis quelques mois portait la plus large des deux fenêtres d'exposition.
Ce que les règles de l'UE en font
Pour une entreprise européenne, la faille n'est pas seulement technique. Si des données personnelles se trouvent derrière ce site, le RGPD vous accorde 72 heures pour notifier votre autorité de contrôle dès que vous avez connaissance d'une violation, et 'nous ne pouvons pas l'exclure' est plus proche de cette connaissance que d'un réconfort.
Pour les entités essentielles et importantes sous NIS2, un incident de cette gravité déclenche sa propre horloge d'alerte précoce et de notification, et les régulateurs attendent de plus en plus des preuves de détection, pas seulement un journal de correctifs. Une mise à jour automatique imposée est une défense que vous n'avez pas choisie ; que vous ayez ensuite vérifié une compromission, voilà ce que garde votre journal.
La vérification qui doit avoir lieu maintenant
Confirmez que le site est en 6.9.5 ou 7.0.2, puis traitez la fenêtre d'exposition comme le vrai travail. Passez en revue les comptes administrateurs et mots de passe d'application créés en juillet, inspectez les tâches planifiées et les fichiers PHP récemment modifiés, et extrayez les journaux du serveur web à la recherche de requêtes POST inhabituelles vers l'API REST autour de la date de divulgation.
Si vous utilisez du WordPress géré, demandez à votre hébergeur par écrit quand le correctif est arrivé et s'il a vu des tentatives d'exploitation contre votre site. La réponse honnête à 'avons-nous été touchés' arrive rarement tout de suite, mais les propriétaires qui posent la question cette semaine sont ceux qui n'auront pas à expliquer une violation silencieuse le trimestre prochain.
À lire ensuite: Un bâtiment inutilisable coûte plus qu'une rançon | Votre sandbox attaquée un mois avant l'alerte
