PHP2Shell : corrigez PHP avant les attaquants

PHP2Shell est un probleme du runtime PHP. Ce n’est pas seulement un probleme de WordPress, Drupal ou Joomla. Si votre organisation utilise PHP directement, chez un hebergeur, dans un conteneur ou via une plateforme d’affaires geree, il faut savoir ou PHP tourne et confirmer le correctif.

Faites ces quatre choses d’abord

1. Inventoriez chaque runtime PHP. Verifiez la production, le staging, les conteneurs, les fonctions serverless, les panneaux de controle, les microsites oublies et les plateformes d’affaires gerees par un tiers. Demandez aux fournisseurs une confirmation ecrite de la version PHP, du correctif, du plan de redemarrage et de la retention des journaux.
2. Corrigez le runtime PHP et redemarrez les services. Mettre a jour un CMS ou une extension ne met pas PHP a jour. Corrigez Apache, PHP-FPM et les workers PHP de longue duree, puis verifiez la version en execution. Ne vous fiez pas seulement a php -v : la version CLI peut differer de PHP-FPM ou de l’image de conteneur qui sert le trafic de production.
3. Examinez les journaux pour des indicateurs d’attaque. Regardez les journaux du perimetre, du WAF, du serveur web, de PHP-FPM et de l’application pendant la periode d’exposition.
4. Escaladez les signaux credibles. Si vous trouvez des indicateurs, conservez les journaux et declenchez une investigation. Ne supprimez pas des fichiers et ne redemarrez pas d’abord. Sans partenaire de chasse aux menaces ou de reponse aux incidents, appelez Logiciels SB au +1 (438) 842-1370.

Qu’est-ce que PHP2Shell?

PHP2Shell est le nom donne a deux vulnerabilites liees dans le coeur de PHP : CVE-2026-109618 et CVE-2026-109619. Elles concernent le traitement des requetes PHP et peuvent exposer de la memoire sensible du processus ou, dans certains chemins affectes, permettre l’execution de code sans authentification. Le composant vulnerable est PHP lui-meme : du code applicatif securitaire ne suffit donc pas.

La recherche a demontre des impacts contre des applications PHP courantes, notamment WordPress, Drupal et Joomla. Le correctif complet est un runtime PHP corrige, pas seulement une mise a jour applicative ni une regle WAF temporaire.

Versions a verifier

Ce tableau est un portrait du 22 octobre 2026. Validez toujours l’avis de securite actuel de votre distribution avant un changement en production.

Les versions PHP en amont viennent du guide PHP2Shell et des telechargements PHP. Les versions Ubuntu sont dans USN-8948-1, et Debian publie les versions corrigees dans son suivi de CVE. Pour RHEL, utilisez la fiche CVE Red Hat et vos depots actives plutot que de forcer une version PHP en amont.

Quoi chercher dans les journaux reseau et applicatifs

Aucune regle de detection ne confirme ou n’exclut a elle seule une exploitation. Le guide PHP2Shell souligne notamment :

• Des cookies de reponse PHPSESSID anormalement gros ou malformes.
• Des requetes multipart inhabituelles, suivies d’erreurs de limite de memoire PHP ou de reponses HTTP 500 repetees.
• Des plantages ou redemarrages inexpliques de PHP-FPM ou de workers PHP.

Cherchez aussi les effets possibles : fichiers PHP nouveaux ou modifies dans les repertoires web ou de televersement, changements de comptes privilegies, connexions sortantes inconnues et acces web provenant de sources inhabituelles. Conservez les journaux, les horodatages et les fichiers pertinents avant le nettoyage. L’absence de ces signaux ne prouve pas qu’un runtime expose n’a pas ete vise.

Pourquoi il n’est pas toujours necessaire de mettre les sites hors ligne

Un service PHP expose doit etre corrige rapidement, mais arreter tous les sites n’est pas la seule reponse responsable. La securite repose sur des couches :

• Des pare-feux, un WAF et des limites de debit peuvent reduire l’exposition pendant la preparation du correctif.
• La gestion des correctifs identifie le runtime exact et deploye le bon paquet.
• Le cloisonnement des comptes limite ce qu’un compte web compromis peut atteindre.
• Les politiques et le controle des changements evitent des modifications de production improvisees.
• Un plan de communication clair garde les proprietaires, fournisseurs et equipes techniques alignes.

Ces controles ne remplacent pas la mise a jour PHP. Ils reduisent la probabilite qu’un service expose devienne un incident a l’echelle de l’organisation et rendent possible une reponse mesuree : corriger, redemarrer et valider.

Si vous trouvez un signal suspect

Traitez-le comme une investigation, pas comme une simple tache de nettoyage. Conservez la preuve, determinez la portee, examinez les changements d’authentification et d’administration, cherchez de la persistance et changez les secrets ou jetons lorsque la preuve le justifie. En cas de compromission active, isolez le service de maniere controlee et suivez votre plan de reponse aux incidents.

Vous ne savez pas si tous vos runtimes PHP sont a jour? Ecrivez a info@sbsoftware.ca. Si vous croyez qu’un incident est actif, appelez le +1 (438) 842-1370. Nous serions heureux d’aider avec la revue d’exposition, la chasse aux menaces ou la reponse aux incidents.