PHP2Shell : sécuriser les sites et applications de votre PME

Si votre entreprise utilise PHP pour un site ou une application, faites vérifier aujourd’hui que le moteur PHP a été corrigé contre PHP2Shell. Le 21 octobre 2026, le projet PHP a publié des mises à jour corrigeant deux vulnérabilités critiques pouvant permettre l’exécution de code à distance sans authentification. L’avis officiel de PHP recommande une mise à jour immédiate des installations concernées. Mettre uniquement à jour le site ou ses extensions ne suffit pas. (php.net)

Pour un dirigeant de PME, la priorité n’est pas de comprendre chaque détail technique : il faut identifier les services exposés, obtenir une preuve de correction et vérifier que les fonctions commerciales restent opérationnelles. Voici comment organiser cette intervention sans confondre correctif urgent, recherche de compromission et refonte de votre application.

PHP2Shell : que s’est-il passé le 21 octobre ?

PHP2Shell désigne deux vulnérabilités du moteur PHP, identifiées par les références CVE-2026-109618 et CVE-2026-109619. Les chercheurs ont notamment démontré une exécution de code sans authentification sur des environnements WordPress, Drupal et Joomla. Leur publication technique chez Wiz précise que le problème se situe dans PHP lui-même, et non uniquement dans ces applications. (wiz.io)

La première vulnérabilité concerne une corruption mémoire lors de la gestion d’un manque de mémoire. La seconde concerne un état interne conservé entre des requêtes alors que la mémoire correspondante a été libérée. Les deux mécanismes sont détaillés dans les avis du dépôt officiel : corruption lors d’un manque de mémoire et état global périmé entre requêtes. (github.com)

L’urgence ne repose pas seulement sur des démonstrations de laboratoire. Dans son compte rendu du 21 octobre, Cloudflare indique avoir observé du trafic d’attaque visant ses clients et déployé des protections. Cela ne signifie pas que votre entreprise a été compromise, mais justifie de traiter le correctif hors du calendrier habituel de maintenance. (blog.cloudflare.com)

Votre entreprise est-elle concernée par PHP2Shell ?

Votre entreprise doit vérifier son exposition dès qu’un service traite des requêtes web avec PHP. L’avis PHP inclut notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet considère le risque particulièrement élevé avec mod_php, où une attaque a été démontrée avant même l’exécution du code applicatif. Le périmètre officiel ne se limite donc pas aux sites anciens ou mal entretenus. (php.net)

Pour organiser l’inventaire, ne partez pas seulement du site principal. Nous recommandons de faire examiner :

• Le site vitrine et les formulaires de contact.
• La boutique en ligne et les espaces clients.
• Les applications internes, extranets et backoffices.
• Les sous-domaines de démonstration, de recette ou de préproduction.
• Les anciens services encore accessibles, même s’ils ne figurent plus dans les menus.
• Les outils fournis par un éditeur ou administrés par un prestataire.

Si personne ne sait quelle technologie utilise un service, classez-le « à vérifier », plutôt que « non concerné ». Pour chaque adresse, demandez un responsable identifié, le mode d’hébergement et le statut de correction. L’objectif est d’obtenir une liste exploitable, pas un inventaire parfait avant de commencer à agir.

Un site WordPress à jour n’est pas une preuve suffisante

La correction de PHP2Shell porte sur le moteur qui exécute l’application. Les chercheurs rappellent explicitement qu’une mise à jour applicative ne met pas à jour le moteur PHP sous-jacent. Une réponse comme « toutes les extensions sont à jour » ne clôt donc pas le sujet. (php2shell.com)

Si votre prestataire assure la maintenance de votre site WordPress, demandez-lui de distinguer les deux opérations dans son compte rendu : maintenance du CMS d’une part, correction de l’environnement PHP d’autre part.

Quelles versions de PHP corrigent les vulnérabilités ?

Les avis officiels indiquent que les corrections sont disponibles dans PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Pour un paquet fourni par une distribution Linux ou un fournisseur de support, la preuve peut aussi être un avis confirmant le rétroportage des correctifs : le numéro de version amont ne suffit pas toujours à conclure.

Ces versions figurent dans les informations de correction du projet PHP. Red Hat explique également que ses paquets peuvent recevoir des correctifs rétroportés sans reprendre le numéro d’une nouvelle version amont. Consultez alors l’avis de sécurité correspondant au produit réellement installé. (github.com)

Notre recommandation : séparez la fermeture de la faille et la modernisation technique. Si une correction maintenue existe pour votre environnement, commencez par cette intervention ciblée. Une montée de version plus importante pourra ensuite être préparée avec une recette adaptée.

Que demander à votre hébergeur ou à votre prestataire ?

Demandez une confirmation écrite couvrant les deux CVE, les environnements concernés et la remise en service des processus corrigés. Une affirmation générale comme « nos infrastructures sont sécurisées » n’est pas assez précise pour piloter l’intervention.

Vous pouvez envoyer ce message :

Merci de confirmer le statut de nos services face à PHP2Shell, CVE-2026-109618 et CVE-2026-109619. Pour chaque environnement, pouvez-vous préciser le paquet ou la version corrigée, la date d’application, la relance des processus PHP concernés et les éventuelles actions restant à notre charge ? Merci d’inclure la production, la préproduction et les sous-domaines hébergés.

Demandez aussi qui prend la décision si le correctif n’est pas immédiatement disponible. L’hébergeur, l’agence et l’éditeur ne doivent pas chacun supposer qu’un autre acteur pilote l’incident.

Pour une application web développée sur mesure, nous conseillons de répartir explicitement les responsabilités : l’exploitant corrige l’environnement, l’équipe applicative vérifie les parcours et le responsable métier valide la reprise. Une seule personne doit consolider les preuves et les points ouverts.

Le plan d’action à lancer aujourd’hui

1. Prioriser les services exposés et critiques

Commencez par les services accessibles depuis Internet, puis croisez cette exposition avec leur importance métier. Utilisez le tableau suivant comme grille de décision interne, et non comme une évaluation technique universelle.

2. Préparer une intervention contrôlée

Avant le déploiement, faites préciser la procédure de sauvegarde, les possibilités de restauration, les dépendances concernées et la personne habilitée à interrompre l’opération. Pour une boutique, choisissez aussi comment informer les clients si une maintenance devient nécessaire.

Ne transformez pas cette préparation en prétexte pour différer indéfiniment la correction. L’équipe doit proposer un chemin court : intervention, contrôle technique, tests métier, décision de réouverture. Une répétition en préproduction est utile lorsqu’elle peut être réalisée rapidement sur un environnement représentatif.

3. Tester les parcours qui produisent du revenu

Pour la recette après correction, nous recommandons une liste brève, exécutée par une personne connaissant le métier :

• Connexion et récupération de mot de passe.
• Envoi d’un formulaire et réception du message associé.
• Panier, commande et confirmation, avec le dispositif de paiement de test approprié.
• Dépôt et téléchargement de documents.
• Création ou modification d’un dossier dans l’application.
• Échange avec les outils connectés, notamment l’ERP ou le CRM.

Pour une entreprise qui dépend de son site e-commerce, définissez à l’avance les critères bloquants : commande impossible, montant incohérent, confirmation absente ou synchronisation interrompue. Le bon indicateur n’est pas seulement « la page d’accueil s’affiche ».

4. Clôturer avec une preuve

Conservez un ticket indiquant les services traités, la référence du correctif, la date du déploiement, les contrôles effectués et les exceptions. Toute exception doit avoir un responsable et une prochaine action. Cette discipline permet au dirigeant de distinguer une intervention terminée d’une promesse de traitement.

Pour les CTO : vérifier le moteur réellement en service

Les chercheurs recommandent d’installer une version corrigée sur chaque environnement d’exécution, puis de redémarrer Apache, PHP-FPM et les processus PHP persistants concernés. Cette étape figure dans leurs consignes de déploiement. Notre recommandation est de contrôler l’environnement qui sert effectivement les requêtes, et pas uniquement la présence d’un paquet sur le serveur. (php2shell.com)

Lors de la validation technique, faites documenter :

• Le moteur PHP associé à chaque site ou pool.
• La référence complète du paquet installé et son fournisseur.
• La relance des processus concernés après installation.
• Le statut de chaque instance derrière le répartiteur de charge.
• La correction des images utilisées pour les prochains déploiements.

Pour une plateforme conteneurisée, incluez la reconstruction et le redéploiement des images dans le périmètre de l’intervention. Vérifiez également le scénario de restauration : nous recommandons qu’un redéploiement ou une reprise ne réintroduise pas un environnement vulnérable.

Évitez de publier une page de diagnostic détaillée sur Internet pour prouver la version. Privilégiez une vérification administrative ou un contrôle temporaire à accès restreint. La preuve doit être accessible à l’équipe responsable, pas devenir une nouvelle information publique sur l’infrastructure.

Un pare-feu applicatif suffit-il en attendant ?

Non : un pare-feu applicatif constitue une protection complémentaire, pas une preuve de correction de PHP. Cloudflare recommande de mettre à jour PHP même lorsque ses protections WAF sont actives. Dans son avis de protection PHP2Shell, l’éditeur rappelle aussi que limiter les téléversements ne remplace pas le correctif. (blog.cloudflare.com)

Si le déploiement est bloqué, demandez au responsable technique une mesure temporaire adaptée : restriction d’accès, fermeture d’un environnement inutile ou interruption contrôlée d’un service exposé. Nous recommandons d’associer chaque mesure à une durée, un responsable et un plan de correction.

N’appliquez pas une configuration copiée isolément d’un forum. Les contournements peuvent modifier le fonctionnement du service et ne couvrir qu’un chemin d’attaque. Pour le dirigeant, la bonne question reste : « Quelle exposition subsiste, et quand la correction complète sera-t-elle déployée ? »

Corriger et rechercher une compromission sont deux tâches distinctes

Une installation vulnérable n’est pas automatiquement une installation compromise. Inversement, installer le correctif ne permet pas de conclure que rien ne s’est passé auparavant. La recherche de PHP2Shell décrit notamment des possibilités de lecture de mémoire sensible, sans qu’une exécution de code soit nécessaire dans tous les scénarios. Le rapport des chercheurs justifie donc de ne pas limiter l’examen à la recherche d’un fichier malveillant. (wiz.io)

Nous recommandons d’ouvrir une investigation distincte si vous constatez des modifications inexpliquées, des comptes inconnus, des comportements inhabituels ou des alertes de sécurité. Préservez les journaux disponibles avant les opérations susceptibles de les effacer et faites intervenir un spécialiste de réponse à incident si les éléments le justifient.

La rotation des secrets doit alors être organisée depuis un environnement considéré comme sain. Changer tous les mots de passe sans traiter une éventuelle persistance ne constitue pas une stratégie suffisante. Le périmètre de l’investigation doit guider les décisions, plutôt qu’une réaction uniforme pour tous les services.

Quel budget autoriser sans financer une refonte précipitée ?

Il n’existe pas de montant sérieux sans connaître l’hébergement, le nombre d’environnements et les contraintes applicatives. Demandez un chiffrage séparant trois postes : correction de sécurité, validation métier et éventuelle investigation.

Le devis d’intervention doit expliciter :

• Les environnements inclus et ceux qui restent à traiter.
• Les opérations techniques et la fenêtre de maintenance.
• Les tests réalisés et la personne chargée de les valider.
• La procédure de repli et ses limites.
• Les prestations facturées séparément en cas de suspicion de compromission.

Pour décider du niveau d’effort, estimez votre propre coût d’interruption : commandes perdues ou différées, temps des équipes bloquées et travail de reprise. Présentez ces éléments comme des hypothèses internes, pas comme des pertes certaines.

Si un prestataire propose immédiatement de réécrire toute l’application, demandez pourquoi un correctif ciblé ne suffit pas et quelles preuves étayent cette conclusion. Une modernisation peut être pertinente, mais elle doit faire l’objet d’une décision séparée, avec son périmètre et ses bénéfices attendus.

La décision à prendre : corriger, vérifier, puis améliorer

Face à PHP2Shell, demandez une preuve de correction du moteur PHP, une validation des parcours critiques et un statut clair des environnements restants. Vous pourrez ensuite traiter les faiblesses révélées par l’intervention : responsabilités floues, déploiements manuels ou absence de recette.

Vous ne savez pas si votre site ou votre application nécessite une simple correction, une remise à niveau ou une évolution plus profonde ? La séance de consulting IT offerte de Novane permet de cadrer les questions techniques et les prochaines décisions, sans confondre urgence de sécurité et projet de développement.