PHP2Shell désigne deux vulnérabilités critiques du moteur PHP, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 (CVSS v4.0) et rendues publiques le 21/10/2026. Combinées, elles permettent d’exécuter du code sur le serveur, à distance et sans compte, partout où tourne PHP 5.4 ou une version ultérieure. La faille est dans PHP lui-même : WordPress, Drupal, Symfony ou un code sur mesure sont exposés de la même façon.
§ 01 / Fiche
Les éléments ci-dessous viennent des avis de sécurité publiés par l’équipe PHP et des fiches CVE ; les précisions sur le vecteur d’attaque viennent de Sansec.
CVE-2026-109618
Quand une requête épuise la mémoire allouée à PHP, l’interruption laisse des données de la requête dans un état invalide, que la procédure de fin de requête relit ensuite. D’après l’avis PHP, plusieurs façons de provoquer ce manque de mémoire passent par l’analyse des corps de requête multipart. Sansec ajoute que cette faille peut aussi renvoyer au client des fragments de mémoire du serveur.
CVE-2026-109619
Certains états globaux de PHP gardent un pointeur vers la mémoire d’une requête déjà libérée. La requête suivante traitée par le même processus peut alors lire cet état périmé avant de l’avoir réinitialisé, ce qui ouvre l’exécution de code.
L’avis PHP décrit Apache avec mod_php comme le cas le plus exposé : l’exécution de code y a été démontrée par HTTP, avec la configuration par défaut, avant même que le code de l’application ne s’exécute. PHP-FPM est également concerné d’après l’analyse du code source, même si aucune attaque complète n’y a été démontrée. Dans tous les cas, la mise à jour de PHP est la seule protection complète.
§ 02 / Chronologie
Heures en UTC, comme dans les sources ; ajouter 2 h pour l’heure de Paris en octobre.
01/08/2026
Les chercheurs de Calif trouvent plusieurs chemins d’exécution de code à distance dans PHP.
11/08/2026
Calif signale le premier problème à l’équipe PHP : début de la divulgation coordonnée.
24/08/2026
Wiz Research signale à son tour les vulnérabilités à l’équipe PHP.
20/10/2026
PHP annonce un correctif pour le lendemain, 14:00 UTC. Les détails fuitent ; watchTowr confirme l’exécution de code à distance.
21/10/2026 · 07:43
Cloudflare signale les premières attaques, avant la publication du correctif.
21/10/2026 · 14:00
PHP publie 8.2.35, 8.3.36, 8.4.27 et 8.5.12 (16 h à Paris). Les branches en fin de vie ne reçoivent pas de version corrigée.
Ensuite
Les analyses et un outil d’attaque sont publics ; Sansec annonçait des attaques automatisées dans le quart d’heure suivant le correctif.
§ 03 / Versions
Toutes les versions de PHP depuis 5.4.0 (2012) contiennent le code vulnérable, d’après Sansec. Les avis officiels ne listent de version corrigée que pour les branches maintenues, 8.2 à 8.5.
| Branche | Version corrigée | Statut | À savoir |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | Corrigée | Sécurité jusqu’au 31/12/2029 |
| PHP 8.4 | 8.4.27 | Corrigée | Sécurité jusqu’au 31/12/2028 |
| PHP 8.3 | 8.3.36 | Corrigée | Sécurité jusqu’au 31/12/2027 |
| PHP 8.2 | 8.2.35 | Corrigée, fin proche | Sécurité jusqu’au 31/12/2026 seulement : migration à prévoir |
| PHP 8.1 et 8.0 | Aucune | Sans correctif | Fin de vie : aucune version corrigée |
| PHP 7.x | Aucune | Sans correctif | Fin de vie : aucune version corrigée |
| PHP 5.4 à 5.6 | Aucune | Sans correctif | Fin de vie : aucune version corrigée |
Certaines distributions Linux ou certains hébergeurs peuvent proposer un correctif rétroporté sur une ancienne branche ; Sansec conseille de le leur demander. Ce n’est pas une version maintenue par le projet PHP : la solution durable reste la migration.
§ 04 / Vérifier
Sur un même serveur cohabitent souvent plusieurs PHP : celui de la ligne de commande, un ou plusieurs PHP-FPM, parfois mod_php ou des conteneurs. La commande « php -v » ne donne que le premier. Ce qui compte, c’est la version qui traite les requêtes de chaque site.
« php -v » donne la version de la ligne de commande, utile pour les tâches planifiées, mais pas forcément celle du site. Sur Debian et Ubuntu, chaque version installée a son dossier dans /etc/php/.
php -v
ls /etc/php/Chaque version de PHP-FPM a son binaire et ses pools. Le nom exact dépend de la distribution. Repérez ensuite quel pool, ou quel socket, chaque site utilise dans la configuration du serveur web.
php-fpm8.3 -v
ls /etc/php/*/fpm/pool.d/
grep -Rn "proxy:unix\|fastcgi_pass" /etc/apache2/sites-enabled/ /etc/nginx/sites-enabled/ 2>/dev/nullSeule une page exécutée par le serveur web fait foi. Si la directive expose_php est active, l’en-tête X-Powered-By donne la version. Sinon, déposez un phpinfo() temporaire au nom imprévisible, à accès restreint, et supprimez-le aussitôt après lecture.
curl -sI https://votre-site.example/ | grep -i x-powered-byDans un conteneur, PHP est embarqué dans l’image : la mise à jour du serveur hôte ne le change pas. Interrogez chaque service, puis reconstruisez l’image sur une version corrigée.
docker compose exec <service> php -v§ 05 / Parade d’urgence
D’après Sansec, tous les déclencheurs connus passent par une requête « multipart/form-data », le format des envois de fichiers, que PHP analyse avant que l’application ne s’exécute. L’avis PHP recommande lui aussi de bloquer ces requêtes en amont quand l’application n’en a pas besoin.
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^POST$ [NC]
RewriteCond %{HTTP:Content-Type} ^[[:space:]]*multipart/form-data([;,[:space:]]|$) [NC]
RewriteRule ^ - [F,L]if ($http_content_type ~* "multipart/form-data") { return 403; }curl -s -o /dev/null -w '%{http_code}\n' -F 'test=1' https://votre-site.example/
curl -s -o /dev/null -w '%{http_code}\n' -d 'test=1' https://votre-site.example/Testez la configuration avant de recharger (« apachectl configtest » ou « nginx -t ») et gardez une copie de l’ancienne.
Sansec cite d’autres mesures temporaires : mettre le site hors ligne derrière une page statique, n’accepter que les requêtes GET et HEAD, ou modifier deux réglages de PHP (session.upload_progress.enabled et memory_limit). Ces réglages ne protègent que partiellement, et un développeur de PHP a averti que désactiver la progression d’envoi ne suffit pas seul.
§ 06 / Correctif
Pour PHP 8.2 à 8.5, la correction est une simple mise à jour de version, à condition qu’elle atteigne bien le PHP qui sert vos sites.
Par les paquets de votre distribution, l’image Docker officielle reconstruite, ou votre hébergeur. Vérifiez que votre source de paquets propose bien la version corrigée : selon Sansec, le dépôt Remi, courant sur les serveurs RHEL, ne la publiait pas le 21 octobre.
Un processus PHP-FPM ou Apache déjà lancé garde l’ancien binaire en mémoire tant qu’il n’est pas redémarré. Redémarrez chaque service PHP-FPM et le serveur web, version par version.
Refaites le contrôle de la version réellement servie pour chaque site : c’est lui qui confirme la correction, pas le gestionnaire de paquets.
Une fois la version corrigée confirmée, retirez le filtrage multipart et les réglages temporaires, puis testez de nouveau les envois de fichiers.
§ 07 / Migrer
Ces branches sont en fin de vie : le projet PHP ne publie plus de correctif pour elles, ni pour PHP2Shell ni pour les failles à venir. La parade d’urgence fait gagner du temps, sans plus. La sortie passe par une migration vers PHP 8.3 ou 8.4, et souvent par celle du framework qui va avec. PHP 8.2, corrigé cette fois, cesse à son tour d’être maintenu le 31/12/2026.
Migration au forfait, sur devis écrit avant de commencer.
§ 08 / Sooatek
Une intervention annoncée avant, vérifiée après, précédée d’une sauvegarde. En direct ou en marque blanche pour les agences.
Chaque serveur, pool FPM et conteneur ; la version servie site par site ; les sites exposés classés par priorité.
Filtrage multipart en amont de PHP, test d’un envoi refusé et d’un formulaire accepté, liste des fonctions coupées communiquée avant.
PHP 8.2 à 8.5 passé en version corrigée, processus redémarrés, contrôle sur une requête servie, parade retirée.
Inventaire, banc de test avant/après, mise en production validée par vous, retour arrière prévu.
Sur nos propres serveurs, nous avons appliqué cette parade dès le 21/10/2026.
Intervention d’urgence au forfait, par serveur, sur devis.
L’offre Sécurisation et préparation NIS2§ 09 / Questions
Non. PHP2Shell est une faille du moteur PHP, pas du code applicatif : un WordPress, un Drupal ou un Symfony à jour reste exposé si le PHP qui le sert n’est pas corrigé. La seule correction complète est la mise à jour de PHP sur le serveur, vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12.
L’avis de sécurité PHP décrit Apache avec mod_php comme le cas le plus exposé : l’exécution de code y a été démontrée avec la configuration par défaut. PHP-FPM est également concerné d’après l’analyse du code source, même si aucune attaque complète n’y a été démontrée. Dans les deux cas, il faut mettre PHP à jour.
La version de PHP réellement servie à votre site : par l’en-tête X-Powered-By s’il est présent, ou par un phpinfo() temporaire protégé, supprimé aussitôt. Si la version n’est pas 8.2.35, 8.3.36, 8.4.27, 8.5.12 ou plus récente, demandez la mise à jour à votre hébergeur, ou le passage à une branche maintenue si vous êtes en PHP 8.1 ou plus ancien.
Non. C’est une mesure partielle : d’après Sansec, un développeur de PHP a averti que désactiver la progression d’envoi ne suffit pas seul, et l’avis PHP rappelle que seule la mise à jour corrige complètement la faille. À combiner, en attendant, avec le filtrage des envois multipart en amont de PHP.
Il coupe les envois de fichiers (CV, documents, images, pièces jointes) et les formulaires envoyés en multipart, parfois ceux de commande. Le reste du site continue de fonctionner. Il faut tester les parcours critiques après l’avoir posé, prévenir les utilisateurs concernés et le retirer dès que PHP est à jour.
Pas de version officielle : les avis de sécurité PHP ne listent de version corrigée que pour les branches 8.2 à 8.5. Certaines distributions ou certains hébergeurs peuvent proposer un correctif rétroporté, à leur demander. La solution durable est la migration vers PHP 8.3 ou 8.4.
C’est prudent si le serveur est resté exposé. Sansec indique que CVE-2026-109618 peut renvoyer au client des fragments de mémoire du serveur, qui peuvent contenir mots de passe, jetons de session, clés d’API ou clés privées. Faites l’inventaire des secrets utilisés sur ce serveur et renouvelez les plus sensibles.
§ 10 / Sources
Sources primaires
Sources secondaires
Sources consultées le 22/10/2026. Cette page est mise à jour quand les avis officiels évoluent.
Dites-nous quelle application est concernée, sa version de PHP et où elle est hébergée. Nous revenons vers vous par écrit avec un premier avis et la suite possible. N’envoyez ni mot de passe ni détail exploitable.
Avec votre accord, nous mesurons l’audience du site avec Google Analytics, de façon anonymisée. Les données sont transmises à Google, y compris hors de l’Union européenne. En savoir plus
