Les deux identifiants PHP2Shell (CVE‑2026‑109618, CVE‑2026‑109619) doivent être traités comme un incident urgent : un attaquant n'a besoin d'aucun identifiant ni mot de passe, il lui suffit d'atteindre un service exposé sur Internet pour potentiellement exécuter des commandes directement sur votre serveur. L'ordre de traitement recommandé est le suivant : confirmer d'abord si vous êtes dans le périmètre affecté, puis décider s'il faut appliquer le correctif ou d'abord mettre en place une atténuation temporaire, et enfin vérifier impérativement et réexaminer les journaux. Voici le détail dans un ordre exécutable.
Étape 1 : Déterminer en 30 minutes si vous êtes réellement affecté
Ne coupez pas tout le site dès le départ ; commencez par trois actions pour localiser la surface d'exposition.
1. Confirmer la version. Connectez-vous au serveur et exécutez `php -v`, puis vérifiez le tag de l'image de conteneur, le `composer.lock` et la version de PHP sélectionnée dans le panneau. De nombreux sites d'entreprise fonctionnent sur d'anciennes versions 7.x ; l'équipe d'exploitation pense avoir mis à jour, alors qu'en réalité c'est un autre environnement qui tourne.
2. Confirmer la surface d'exposition. Effectuez un balayage depuis l'extérieur : quels domaines/IP ont les ports 80, 443, 8080 directement ouverts sur Internet, s'il existe des environnements de test, d'anciens back-offices ou des interfaces mises en ligne temporairement et oubliées. Un accès intranet ne signifie pas être en sécurité ; les mouvements latéraux commencent souvent ici.
3. Confirmer le chemin de déclenchement. En vous référant aux composants et points d'entrée affectés indiqués dans l'avis officiel, vérifiez si vos routes, interfaces de téléversement, points d'entrée de désérialisation et points de rendu de templates sont couverts. Si vous ne pouvez pas trancher, traitez le cas comme « affecté » : le coût est plus faible.
Consignez les résultats dans un tableau : domaine, version de PHP, exposition publique ou non, présence ou non de composants affectés, responsable. Ce tableau servira ensuite pour la vérification et le retour d'expérience.
Étape 2 : Appliquez le correctif si possible, ne remplacez pas la mise à jour par un « changement de configuration »
Le correctif est le seul moyen de traiter la cause profonde ; l'atténuation temporaire ne fait que gagner du temps.
- Validez d'abord en préproduction. Une mise à jour directe en production est très risquée, surtout pour des sites d'entreprise exploités depuis des années, où extensions et versions de frameworks sont interdépendantes. Faites passer en préproduction les parcours critiques : connexion, commande/soumission de formulaire, callback de paiement, téléversement de fichiers.
- Mettez à jour dans l'ordre des dépendances. Mettez d'abord à jour le runtime, puis le framework et les bibliothèques tierces, et enfin traitez les appels obsolètes dans le code métier. Après `composer update`, régénérez le fichier de verrouillage et commitez-le.
- Conservez un chemin de retour arrière. Avant la mise à jour, faites un snapshot ou conservez l'ancien tag d'image, et documentez clairement les commandes de rollback. Une mise à jour sans plan de retour arrière est essentiellement un pari.
- Piège à éviter : ne déclarez pas la mise à jour terminée après n'avoir mis à jour qu'une seule machine. Derrière l'équilibreur de charge, plusieurs machines restent souvent inchangées ; c'est précisément celle qui a été oubliée que l'attaquant cible.
Si le site a été réalisé en sous-traitance et que vous n'avez pas le code source, contactez d'abord le développeur d'origine pour obtenir les informations de version et le plan de correctif ; si vous ne les obtenez pas, tenez bon avec la solution temporaire de la section suivante.
Étape 3 : Atténuation temporaire lorsque le correctif ne peut pas être appliqué, par ordre de priorité
Les mesures d'atténuation visent à « réduire la probabilité d'exploitation », et non à « réparer » ; elles doivent être inscrites dans un calendrier avec une échéance de mise à jour.
1. Réduire la surface d'exposition : retirez le back-office d'administration, les interfaces de débogage et les environnements de test d'Internet, passez-les en accès intranet ou ajoutez une liste blanche d'IP. C'est la mesure au meilleur rapport bénéfice/coût.
2. Filtrer en amont : mettez en place des règles de blocage au niveau du WAF ou de Nginx selon les signatures indiquées dans l'avis, et limitez en même temps les droits d'exécution du répertoire de téléversement (`php_flag engine off` ou configuration équivalente).
3. Exécuter avec des privilèges réduits : le processus Web ne doit pas tourner en root ; retirez les droits d'écriture inutiles sur les répertoires de fichiers et désactivez les fonctions dangereuses pouvant l'être dans `disable_functions`.
4. Ajouter de la surveillance : alertez sur les sous-processus anormaux, les connexions sortantes et l'apparition de nouveaux fichiers exécutables dans le répertoire de téléversement.
Piège à éviter : ajouter uniquement des règles WAF sans modifier le code revient à confier sa sécurité à la base de règles. Un attaquant peut contourner avec un simple changement d'encodage ; il faut donc consulter les journaux de blocage chaque jour pendant la période d'atténuation.
Étape 4 : Vérifiez impérativement après la correction, sinon c'est comme si rien n'était fait
De nombreuses équipes s'arrêtent une fois le correctif appliqué, alors que d'anciens processus tournent encore.
- Redémarrez PHP-FPM et le service Web, et confirmez que `php -v` affiche la nouvelle version sur tous les nœuds.
- Retestez le chemin de déclenchement d'origine avec un outil de scan externe, et confirmez que le retour n'est plus dans un état exploitable.
- Réexaminez les journaux : pendant la fenêtre entre la publication de la vulnérabilité et la correction, y a-t-il eu des POST anormaux, des téléversements suspects ou des connexions sortantes anormales ? Si oui, traitez-le comme un incident de compromission, et pas seulement comme un correctif à appliquer.
- Vérifiez les tâches planifiées, les clés publiques SSH et les comptes nouvellement créés, pour confirmer qu'aucune porte dérobée n'a été laissée.
Prenons un scénario concret (exemple) : lors de la refonte du site d'une entreprise, une interface de téléversement de fichiers avait été ouverte temporairement pour les designers, puis oubliée, et se trouvait justement sur une version affectée. Ces « interfaces temporaires » sont un point critique ; à la clôture d'une refonte, il devrait exister une « liste de nettoyage des points d'entrée temporaires ».
Dans quels cas faire appel à MIC Studio
Si vous êtes dans l'une des situations suivantes, il n'est pas rentable de tout gérer seul :
- Le code source est chez le sous-traitant, les informations de version sont floues et le plan de correctif ne peut pas être établi ;
- Vous avez de nombreux sites et des environnements hétérogènes, et vous ne distinguez pas lesquels sont publics ni lesquels sont dans le périmètre affecté ;
- Après avoir appliqué le correctif, vous souhaitez mener une nouvelle campagne de tests de sécurité et de tests inversés pour confirmer l'absence de points d'entrée résiduels et de portes dérobées ;
- Vous souhaitez profiter de l'occasion pour refondre l'ancien système et unifier les stacks techniques de développement de sites web, de mini-programmes ou d'App vers des versions maintenables.
MIC Studio réalise des sites d'entreprise, des mini-programmes, des App et du développement de scripts, ainsi que des tests de sécurité de sites web et des tests inversés, et peut intervenir dans l'ordre « arrêter l'hémorragie d'abord, vérifier ensuite, refondre enfin ». Tous les problèmes ne nécessitent pas d'externalisation ; lorsqu'on peut appliquer le correctif soi-même, il est plus important de le faire d'abord.
Conclusion : trois choses à faire dès aujourd'hui
1. Établissez la liste aujourd'hui : listez tous les environnements PHP accessibles depuis Internet, avec version et responsable, sans vous fier à la mémoire.
2. Terminez la mise à jour ou l'atténuation sous 48 heures : mettez à jour si possible ; sinon, retirez la surface d'exposition et ajoutez du filtrage, en fixant une échéance.
3. Conservez les preuves : sauvegardez les journaux avant et après la mise à jour, et réexaminez après correction les requêtes anormales dans la fenêtre temporelle pour confirmer qu'aucune intrusion n'a eu lieu.
Questions fréquentes
Une utilisation uniquement en intranet nécessite-t-elle quand même une correction ?
Oui. L'intranet n'est pas une zone d'isolement ; les postes des employés, les machines de test et les accès tiers peuvent tous servir de rebond. Corrigez en priorité ce qui est exposé sur Internet, et traitez l'intranet dans la même fenêtre de maintenance.
Peut-on se contenter de règles WAF sans mettre à jour ?
Uniquement à titre transitoire. Les règles reposent sur la correspondance de signatures, le coût de contournement est faible, et leur maintenance nécessite une surveillance humaine. Considérez le WAF comme un garrot et la mise à jour comme l'opération chirurgicale ; les deux ne se substituent pas l'un à l'autre.