PHP2Shell : corrigez maintenant, puis réduisez votre fenêtre d'exposition

Ce qui s’est passé

Le 21 octobre 2026, le projet PHP a publié des correctifs d’urgence pour deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, baptisées PHP2Shell. Les deux permettent une exécution de code à distance sans authentification. Une seule requête malveillante suffit à déclencher la faille avant même que le code de l’application ne s’exécute : votre CMS, votre framework ou votre page de connexion n’y changent rien.

Des tentatives d’exploitation ont été signalées quelques heures avant la publication du correctif. Des analyses détaillées et un outil d’exploitation circulent déjà.

Pourquoi cette faille n’est pas comme les autres

La plupart des vulnérabilités web touchent une extension ou une application précise. PHP2Shell se trouve dans PHP lui-même, dans le code qui lit les requêtes entrantes. Concrètement :

• Toute installation PHP qui sert du trafic web est concernée, notamment PHP-FPM, Apache avec mod_php et php-cgi.

• Les configurations par défaut sont vulnérables.

• Les anciennes versions sont le cas le plus difficile. Pour PHP 7.4, 8.0 et 8.1, il n’existe que des rétroportages en code source, à compiler soi-même ou à obtenir de sa distribution. Pour PHP 7.3 et plus ancien, il n’existe aucun correctif. Or une bonne partie des sites PHP tournent encore sur PHP 7 ou plus ancien.

Pour les gestionnaires : trois actions cette semaine

1. Demandez un inventaire. Quels sites publics, outils internes et équipements de fournisseurs utilisent PHP ? Les équipements et les produits hébergés sont souvent oubliés.

2. Faites du correctif la priorité. Ce n’est pas un dossier pour la prochaine fenêtre de maintenance.

3. Prévoyez un plan pour ce qui ne peut pas être corrigé rapidement. Les applications patrimoniales sur de vieilles versions de PHP demandent une décision : mise à niveau, isolement ou mise hors ligne.

Pour les équipes techniques : corriger et atténuer

Versions corrigées

Redémarrez les workers PHP après la mise à jour pour qu’aucun processus ne garde l’ancien code en mémoire.

Si vous ne pouvez pas corriger aujourd’hui

• Désactivez session.upload_progress.enabled dans php.ini ou dans votre pool PHP-FPM.

• Révisez memory_limit et post_max_size.

• Sur les sites qui n’acceptent pas de téléversement de fichiers, envisagez de refuser les requêtes multipart/form-data au niveau du serveur web. Testez avant : cela peut briser des formulaires d’envoi ou de paiement.

• Pour un système critique qui reste non corrigé, une page de maintenance statique ou la mise hors ligne demeure l’option la plus sûre.

Le rôle de CYBERDEFENSE.AI

Soyons clairs : aucun WAF ne remplace le correctif. PHP2Shell se déclenche dans le traitement des requêtes par PHP lui-même, et c’est là que la correction doit se faire.

Une couche de défense préemptive réduit le risque entre la divulgation et la correction, justement la période où les attaquants vont le plus vite. CYBERDEFENSE.AI n’attend pas qu’une signature soit écrite. La plateforme analyse les comportements en temps réel et bloque ce qui ne ressemble pas à un visiteur légitime :

• les scanners automatisés qui balaient des milliers de sites à la recherche de serveurs PHP vulnérables,

• les requêtes anormales qui ne correspondent pas à l’usage normal de votre application,

• les adresses IP déjà repérées pour des activités malveillantes sur la plateforme.

Vos équipes gagnent ainsi le temps de corriger correctement, dans le bon ordre, sans improviser en pleine nuit.

À retenir

• PHP2Shell touche PHP lui-même, pas une application en particulier. Considérez que vous êtes concerné.

• Passez à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, puis redémarrez les workers.

• Les mesures temporaires font gagner du temps, elles ne bouchent pas la faille.

• Un WAF préemptif réduit le risque pendant que vous corrigez. C’est une couche de protection, pas un substitut.