Les attaques liées à PHP2Shell n’ont pas attendu la publication des correctifs PHP du 21 octobre 2026. Amazon Threat Intelligence affirme avoir relevé, sur son réseau de leurres MadPot, une tentative dès le 17 octobre. Depuis, plusieurs chercheurs observent des recherches de serveurs vulnérables et des tentatives d’exploitation. Deux failles critiques — CVE-2026-109618 et CVE-2026-109619 — exposent notamment des applications WordPress, Drupal ou Joomla qui reposent sur un interpréteur PHP non corrigé. Voici ce que ces révélations changent pour les administrateurs.
Publié le 23 octobre 2026. Ce nouvel article complète notre guide initial des versions PHP corrigées ; il porte sur l’activité malveillante observée et la réponse aux incidents.
PHP2Shell : une tentative observée quatre jours avant la publication des failles
Dans un compte rendu officiel daté du 21 octobre, Amazon Threat Intelligence indique que ses systèmes MadPot ont détecté une tentative d’exploitation le 17 octobre. Le trafic provenait d’une infrastructure d’anonymisation commerciale et visait un dispositif conçu pour observer les attaques, appelé honeypot ou pot de miel.
Amazon ne peut pas expliquer à ce stade comment l’auteur aurait obtenu des informations sur la vulnérabilité avant la divulgation publique. Cette observation n’est pas non plus la preuve qu’un site client précis a été compromis à cette date. Le constat est plus circonscrit : des requêtes apparentées à l’exploitation ont été détectées avant la disponibilité des correctifs.
Le 21 octobre, Amazon relève ensuite plusieurs preuves de concept et des requêtes d’attaque venant de différentes infrastructures. Le groupe estime que les tentatives se sont propagées rapidement après la divulgation, une situation d’autant plus préoccupante que des millions de sites reposent sur PHP.
Deux failles distinctes, avec un risque d’exécution de code
| Identifiant | Nature du problème | Risque |
|---|---|---|
| CVE-2026-109618 | Corruption de mémoire lors du traitement d’une requête si une allocation échoue | Potentielle exécution de code à distance |
| CVE-2026-109619 | État interne réutilisé de manière dangereuse d’une requête à l’autre | Potentielle exécution de code à distance |
Les deux vulnérabilités touchent le moteur PHP, particulièrement la gestion de certaines requêtes HTTP et des formulaires de téléversement. La cause ne se trouve pas nécessairement dans un thème ou une extension WordPress. D’après AWS, elles reçoivent chacune une évaluation CVSS v4.0 de 9,2/10.
Les preuves de concept montrent que certains environnements peuvent être exploités sans compte utilisateur. Le risque réel dépend de la version de PHP et des modalités de déploiement. Il faut éviter de confondre les recherches de vulnérabilités, les tentatives observées par les capteurs et une compromission effective de serveurs de production.
Quelles versions de PHP sont protégées ?
Le projet PHP et AWS indiquent les versions minimales contenant les correctifs :
| Branche | Version corrigée |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Les branches plus anciennes ne sont plus maintenues normalement par le projet PHP. Certains éditeurs de systèmes ou panels d’hébergement fournissent cependant des correctifs rétroportés : dans ce cas, le numéro de version seul ne suffit pas, il faut consulter l’avis de sécurité propre au fournisseur.
Un pare-feu applicatif (WAF) ne remplace pas le correctif. AWS précise que les règles de filtrage réduisent certaines possibilités d’attaque, mais ne protègent pas complètement contre les deux problèmes. Le patch de PHP reste la mesure définitive.
Comment vérifier si son serveur WordPress a été ciblé ?
Amazon recommande aux équipes techniques de rechercher des événements remontant au moins au 17 octobre 2026, plutôt que de limiter l’enquête au jour de publication des vulnérabilités.
- Inventorier les installations PHP : vérifier la version réellement utilisée par le serveur web et par les processus PHP-FPM ou Apache, et pas uniquement celle de la ligne de commande.
- Examiner les journaux : rechercher les requêtes inhabituelles de téléversement, les échecs récurrents et les requêtes POST suspectes autour des dates concernées.
- Contrôler le WAF : comparer les alertes bloquées avec les logs du serveur et ne pas conclure à une intrusion sur la seule présence d’une requête anormale.
- Repérer les signes de compromission : apparition de fichiers inconnus, processus inattendus, connexions sortantes inhabituelles ou changements non autorisés.
- Préserver les preuves : en cas de doute sérieux, conserver journaux et instantanés avant de nettoyer, et faire intervenir l’équipe de réponse aux incidents.
Amazon mentionne notamment les requêtes POST incluant le champ de suivi de progression des téléversements de session PHP. Ce signal est utile pour la détection, mais ne constitue pas une preuve automatique de piratage. Certains scans légitimes ou tentatives non fonctionnelles peuvent produire des traces similaires.
WordPress.com est-il concerné de la même manière que WordPress auto-hébergé ?
Non : WordPress.com annonce avoir appliqué les protections nécessaires sur sa plateforme, y compris pour les offres intégrant des extensions. Les administrateurs d’un site WordPress auto-hébergé, sur VPS ou hébergement mutualisé, doivent de leur côté vérifier l’application des correctifs par leur fournisseur.
La mise à jour du cœur WordPress n’est pas un substitut à la mise à jour de PHP. Si l’hébergeur applique des mises à jour de sécurité sans changer le numéro de version, demandez-lui une confirmation écrite faisant référence aux CVE concernés.
Les attaques confirmées ne veulent pas dire que tous les sites sont piratés
Le témoignage d’Amazon est important parce qu’il établit une chronologie antérieure à l’embargo. Mais il faut rester précis : une tentative observée dans un pot de miel n’est pas la preuve d’une compromission d’un site de production. Les chercheurs de Deutsche Telekom soulignent eux aussi que certaines requêtes étranges sont de simples scans génériques sans rapport démontré avec PHP2Shell.
Dans le même temps, l’absence d’alerte dans un tableau de bord ne dispense pas d’appliquer le correctif. La recommandation raisonnable est de sécuriser immédiatement le moteur PHP et de réserver les enquêtes approfondies aux environnements exposés, critiques ou présentant des indicateurs précis.
Notre conseil
Si votre site est auto-hébergé, commencez par vérifier la version PHP réellement exécutée, demandez la date du correctif à l’hébergeur et conservez les journaux depuis le 17 octobre. Pour retrouver le détail des versions et le chemin à suivre dans l’administration WordPress, consultez notre premier dossier PHP2Shell.
Questions fréquentes
Mon site WordPress est-il forcément piraté ?
Non. Amazon a observé des tentatives, mais cela ne prouve pas la compromission de chaque site exposé.
Quel est le premier jour à examiner dans les logs ?
Amazon recommande de remonter au moins au 17 octobre 2026, date de sa première observation.
Une règle Cloudflare ou AWS WAF suffit-elle ?
Non. Ces outils constituent une protection complémentaire pendant le déploiement des correctifs PHP.
