PHP2Shell : les failles PHP qui menacent votre site Web (et quoi faire)

Votre site Web, votre boutique en ligne ou votre portail client fonctionne probablement avec PHP. WordPress, WooCommerce et la plupart des CMS reposent sur ce langage. Le 21 octobre 2026, l’équipe PHP a publié des correctifs d’urgence pour deux failles critiques, surnommées PHP2Shell, qui permettent dans certaines conditions de prendre le contrôle d’un serveur Web sans aucun mot de passe. Voici ce qu’il faut savoir, en langage clair, et ce que vous devez vérifier dès maintenant.

PHP2Shell en bref

• Identifiants : CVE-2026-109618 et CVE-2026-109619
• Gravité : score CVSS v4.0 de 9,2 sur 10 pour chacune (Qualys)
• Impact : exécution de code à distance, sans authentification
• Qui est touché : toute installation PHP qui sert des pages Web — PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed (Datadog Security Labs)
• Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35

Pourquoi ces failles sont-elles si sérieuses ?

La plupart des failles Web visent une extension, un thème ou un formulaire précis. PHP2Shell est différente : elle se situe dans PHP lui-même, avant même que votre site ne s’exécute. Selon Datadog Security Labs, « PHP traite la requête malveillante avant qu’aucun code de l’application ne s’exécute ». Autrement dit, un mot de passe robuste, une extension de sécurité WordPress ou un site bien codé ne suffisent pas à bloquer l’attaque.

En termes simples :

• CVE-2026-109618 — lorsqu’une requête épuise la mémoire allouée à PHP, celui-ci peut abandonner une opération à moitié terminée, puis « faire le ménage » en traitant des données invalides comme si elles étaient valides.
• CVE-2026-109619 — un processus PHP peut conserver des informations d’une requête précédente qui pointent vers de la mémoire déjà libérée. Une requête suivante, envoyée au même processus, peut alors réutiliser ces données périmées.

Dans les deux cas, un attaquant habile peut transformer ce désordre en mémoire en exécution de ses propres commandes sur le serveur : vol de données clients, installation d’une porte dérobée, envoi de pourriels ou rançongiciel.

Est-ce que des attaques ont déjà lieu ?

Les détails techniques ont fuité le 20 octobre, avant la date de divulgation prévue. Plusieurs sources rapportent une activité malveillante :

• Amazon Threat Intelligence a observé une tentative d’exploitation dès le 17 octobre 2026, soit quatre jours avant la publication des correctifs (Help Net Security).
• Cloudflare a signalé du trafic d’attaque ciblant ces failles (Qualys).
• Datadog indique être au courant de balayages massifs et non ciblés d’Internet.

Les attaquants n’ont pas besoin de vous viser personnellement : des robots balayent Internet à la recherche de tout serveur non corrigé. La taille de votre entreprise ne vous protège pas.

Le vrai problème : les versions PHP en fin de vie

PHP2Shell met en lumière un risque plus large. Chaque branche de PHP reçoit des correctifs de sécurité pendant une période limitée. Selon php.net, en date d’octobre 2026 :

Version	Correctifs de sécurité jusqu’au	Statut
PHP 8.5	31 décembre 2029	✅ Supportée
PHP 8.4	31 décembre 2028	✅ Supportée
PHP 8.3	31 décembre 2027	✅ Sécurité seulement
PHP 8.2	31 décembre 2026	⚠️ Fin dans quelques semaines
PHP 8.1	31 décembre 2025	❌ Fin de vie
PHP 8.0	26 novembre 2023	❌ Fin de vie
PHP 7.4	28 novembre 2022	❌ Fin de vie

Pour PHP2Shell, l’équipe PHP a exceptionnellement publié des correctifs sous forme de code source pour les versions 7.4, 8.0 et 8.1 (Help Net Security). Mais ces versions ne reçoivent plus de mises à jour régulières : la prochaine faille, elle, risque de ne jamais être corrigée. WordPress recommande d’ailleurs PHP 8.3 ou plus récent et précise que les versions plus anciennes « peuvent exposer votre site à des vulnérabilités de sécurité ».

PHP2Shell n’est pas un cas isolé : le journal des modifications de PHP recense une dizaine de vulnérabilités corrigées dans la seule version 8.5.11 de septembre 2026 (FPM, OpenSSL, SOAP, Phar…). Un serveur qui n’est pas mis à jour régulièrement accumule ces failles.

Que faire maintenant : 5 actions concrètes

1. Identifiez votre version de PHP

Dans WordPress, allez dans Outils → Santé du site → Infos → Serveur. Vous pouvez aussi la trouver dans le panneau de contrôle de votre hébergeur (cPanel, Plesk, etc.).

2. Exigez la mise à jour de votre hébergeur

Si vous êtes en hébergement mutualisé ou géré, la mise à jour de PHP relève généralement de votre fournisseur. Demandez-lui par écrit s’il a appliqué les versions 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou le correctif équivalent de sa distribution Linux) et à quelle date.

3. Si vous gérez votre propre serveur : corrigez, puis redémarrez

Installez la version corrigée, reconstruisez vos images Docker le cas échéant et redémarrez tous les processus PHP. Selon Datadog, « seule l’application du correctif règle ces vulnérabilités ». Si vous ne pouvez pas corriger immédiatement, des mesures temporaires existent, dont la désactivation de session.upload_progress.enabled — mais elles ne remplacent pas la mise à jour. Le NCSC britannique recommande même d’envisager de mettre hors ligne tout système qui ne peut être corrigé rapidement.

4. Ajoutez une couche de protection devant votre site

Un pare-feu applicatif Web (WAF) peut filtrer les tentatives connues. Cloudflare a déployé des règles pour PHP2Shell, y compris pour ses clients gratuits — une protection partielle, qui ne remplace pas le correctif. Voir notre article DNS, WAF et Zero Trust : protéger votre site et vos accès.

5. Vérifiez qu’il n’y a pas eu d’intrusion

Une attaque réussie ne fait pas forcément planter le site. Surveillez notamment : des fichiers PHP inconnus dans votre site, de nouveaux comptes administrateurs, des erreurs « Allowed memory size exhausted » inhabituelles dans les journaux, ou un serveur Web qui lance des commandes système. En cas de doute, faites appel à un professionnel avant de simplement « nettoyer ».

Comment ServiTIQ protège les sites de ses clients

Le 22 octobre 2026, dans les heures suivant la publication des correctifs, ServiTIQ a mis à jour vers PHP 8.3.36 l’ensemble des environnements PHP qu’elle héberge, et appliqué les mesures de durcissement recommandées. C’est ce que permet un hébergement géré : vous n’avez pas à suivre les alertes de sécurité vous-même.

• Veille de sécurité sur PHP, WordPress et vos extensions
• Mises à jour planifiées avec image de retour arrière en cas de problème
• Migration encadrée des sites encore en PHP 7.x ou 8.0/8.1 vers une version supportée
• Sauvegardes et pare-feu applicatif devant vos sites

Vous ne savez pas quelle version de PHP fait tourner votre site, ni si votre hébergeur a appliqué le correctif ? Contactez-nous : nous vérifions votre site et vous indiquons clairement les risques et les options.

FAQ

Mon site WordPress est-il touché par PHP2Shell ?

Si votre site fonctionne avec une version de PHP antérieure à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (sans correctif de votre distribution), il faut présumer que oui. La faille se trouve dans PHP, pas dans WordPress : mettre WordPress à jour ne suffit pas.

Une extension de sécurité comme Wordfence me protège-t-elle ?

Pas contre ce type de faille. Une extension WordPress s’exécute à l’intérieur de PHP, alors que PHP2Shell est déclenchée avant que le code de votre site ne s’exécute. Seule la mise à jour de PHP corrige le problème; un WAF placé devant le serveur peut réduire le risque en attendant.

Mon site est en PHP 7.4 et fonctionne bien. Pourquoi changer ?

PHP 7.4 ne reçoit plus de correctifs officiels depuis le 28 novembre 2022. Pour PHP2Shell, un correctif source a exceptionnellement été publié, mais rien ne garantit qu’il en sera de même pour les prochaines failles. Une migration vers PHP 8.3 ou 8.4 demande souvent des ajustements au thème ou aux extensions : mieux vaut la planifier que la subir.

Mon hébergeur dit qu’il s’en occupe. Comment le vérifier ?

Demandez la version exacte de PHP installée et la date de mise à jour. Dans WordPress, la page Santé du site affiche la version utilisée par votre site. Un hébergeur sérieux doit pouvoir vous répondre clairement.

Sources : php.net – versions supportées, php.net – versions en fin de vie, Datadog Security Labs, Help Net Security, Qualys, WordPress.org. Informations à jour au 22 octobre 2026; la situation peut évoluer.