Failles critiques dans PHP : vous êtes CEO, que devez-vous faire ?

Vous avez entendu parler d’une alerte de cybersécurité susceptible de concerner de nombreuses entreprises. Elle touche PHP, un composant qui fait fonctionner des sites web et des applications en ligne. Pour votre société, les premières vérifications portent sur le site internet, la boutique en ligne et les espaces clients. Il faudra aussi examiner certains équipements et leurs interfaces d’administration. Où se situe le danger, qui doit intervenir et quelles décisions prendre à la tête de l’entreprise ?

Le CERT-FR a publié une alerte le 21 octobre 2026. Deux failles critiques, CVE-2026-109618 et CVE-2026-109619, peuvent permettre à un attaquant d’exécuter ses propres instructions sur un serveur vulnérable, sans disposer d’un compte sur le service visé. Des correctifs ont été diffusés le même jour.

Pour un dirigeant, cette description devient plus claire lorsqu’on la rapproche de ce que contient le serveur : les pages du site, parfois des documents, des identifiants techniques et des accès à une base de données. Si une attaque réussit, ses conséquences dépendent de ce que le programme compromis est autorisé à lire ou à modifier. L’enjeu peut aller d’un site indisponible à un accès aux informations qu’il traite.

La réponse commence donc par une question très concrète : parmi les services que l’entreprise laisse accessibles sur Internet, lesquels utilisent un PHP vulnérable et qui peut les corriger ? Les autorités européennes demandent de donner la priorité à ces systèmes. La présence de PHP ne prouve ni une intrusion ni une vulnérabilité persistante si le correctif a déjà été appliqué.

Le premier périmètre à vérifier : les sites et les services en ligne

Le site institutionnel vient spontanément à l’esprit. Il faut lui ajouter la boutique en ligne, les espaces clients, les portails de commande des distributeurs et les applications accessibles aux partenaires. Les API, ces interfaces par lesquelles des logiciels échangent des informations sans afficher de page à un visiteur, doivent également être recherchées lorsqu’elles utilisent PHP.

Le risque prend alors des formes différentes selon l’activité. Pour un commerçant, suspendre une boutique en ligne signifie interrompre les commandes et répondre aux acheteurs qui attendent une confirmation. Pour une société de services, rendre indisponible un espace client peut bloquer la consultation de dossiers ou le dépôt de documents. Même un site de présentation peut contenir des demandes de devis et les coordonnées de prospects.

Une intrusion peut avoir des conséquences moins visibles qu’une panne. Selon les droits obtenus, un attaquant pourrait consulter des fichiers, modifier du contenu ou utiliser les accès dont dispose l’application pour joindre une base de données. Le site peut continuer à s’afficher pendant que ces accès sont détournés. Une page d’accueil qui fonctionne ne constitue donc pas une preuve de sécurité.

Ces scénarios ne signifient pas qu’une attaque donne automatiquement accès à toute l’entreprise. L’avis technique de PHP décrit une exécution de code avec les droits du processus qui traite les requêtes web. La séparation entre les applications, les permissions et les protections du réseau déterminent jusqu’où une intrusion pourrait aller.

Derrière un même site, plusieurs prestataires peuvent devoir agir

Une entreprise peut avoir confié son site à une agence, l’hébergement à une autre société et la maintenance à un indépendant. Lorsque l’alerte arrive, chacun connaît une partie de l’installation. L’agence peut mettre à jour les pages et les extensions sans administrer PHP ; l’hébergeur peut fournir le serveur sans prendre en charge les logiciels installés par le client. Le contrat et le type d’offre déterminent qui intervient.

Le CEO doit faire obtenir une réponse précise pour chaque service : qui administre PHP, quelle correction a été appliquée, à quelle date, et qui a vérifié que l’application utilise effectivement la version corrigée ? La formule « notre prestataire s’en occupe » laisse trop de place à une intervention supposée, mais jamais confirmée.

L’exemple de GLPI, un outil de gestion du parc et du support informatique, éclaire cette différence. L’éditeur indique avoir corrigé son offre cloud dès le 21 octobre. Pour les installations hébergées par leurs utilisateurs, il demande une mise à jour de PHP sur le serveur. Le nom du logiciel est identique ; la responsabilité de l’intervention change avec l’hébergement.

L’inventaire gagne aussi à sortir du seul service informatique. Le marketing peut connaître un site de campagne encore en ligne ; une filiale peut exploiter son propre portail ; les équipes commerciales peuvent utiliser un outil de commande créé par un prestataire. Les achats et la comptabilité peuvent aider à retrouver les contrats et les interlocuteurs. Ces services doivent rejoindre les vérifications, même s’ils ont peu de visiteurs ou ne figurent plus sur le site principal.

Une interruption préparée coûte autrement qu’une panne subie

Si une application vulnérable ne peut pas être corrigée immédiatement, limiter son accès ou la suspendre peut devenir nécessaire. Pour une boutique en ligne, cette décision engage davantage qu’un redémarrage de serveur : des campagnes publicitaires peuvent continuer à envoyer des acheteurs vers un service fermé, tandis que le support reçoit des appels et que la logistique attend des commandes.

Le responsable commercial doit donc préciser comment traiter les demandes pendant l’intervention. Le marketing doit adapter les campagnes et les messages affichés. Le service client doit disposer d’une consigne fiable, et les opérations doivent savoir quelles commandes ont été enregistrées avant la coupure. La direction financière peut rapprocher le coût de l’interruption des moyens nécessaires pour accélérer la correction.

C’est à cet endroit que le CEO devient indispensable : autoriser une intervention urgente, débloquer le coût d’un prestataire, accepter une fermeture temporaire et donner aux équipes une décision commune. Une heure de maintenance préparée et expliquée ne produit pas les mêmes difficultés qu’un service qui disparaît sans consigne ni heure de prochain point.

La remise en service doit être vérifiée jusqu’au bout du parcours utilisé par les clients : connexion, formulaire, commande, confirmation et transmission aux équipes concernées. Pour les équipes techniques, le contrôle doit aussi établir que PHP corrigé est bien actif. Un redémarrage ou une mise à jour de l’application seule ne constitue pas cette preuve.

Élargir les vérifications aux équipements et aux applications internes

Les sites et les services en ligne occupent le premier plan, mais PHP peut aussi faire fonctionner les interfaces d’administration de certains équipements. Il faut donc prolonger l’inventaire vers les outils de vidéosurveillance, les applications de gestion technique des bâtiments ou d’une usine, les équipements réseau et les portails de maintenance. Tous ces produits n’utilisent pas PHP : le fabricant ou l’intégrateur doit confirmer le cas de chaque installation.

Dans une boutique, le logiciel qui permet de consulter les caméras et de retrouver des enregistrements peut s’appuyer sur une interface web en PHP. La vérification doit alors porter sur ce logiciel de gestion, qu’il fonctionne sur un serveur ou dans un enregistreur. Le responsable de la sûreté et l’installateur doivent faire confirmer la version utilisée et l’application des correctifs.

La même vérification s’impose pour une console de gestion du chauffage, de la ventilation ou de l’éclairage lorsqu’elle utilise PHP. Une mise à jour du service en ligne du fournisseur ne corrige pas nécessairement le logiciel installé dans les locaux de l’entreprise. Il faut obtenir une réponse pour cette installation précise et distinguer une mesure temporaire de protection de la correction complète de PHP.

La priorité dépend ici de l’accès réel et des fonctions concernées. Une console d’équipement vulnérable ouverte sur Internet rejoint les urgences immédiates. Une interface accessible uniquement depuis un réseau privé reste à corriger, en examinant les connexions des salariés et des mainteneurs. Dans une boutique ou une usine, le responsable de site, la sûreté, la maintenance et l’installateur doivent expliquer ce qui continue de fonctionner si la console est isolée : perdre une consultation à distance et interrompre un enregistrement ou un réglage local sont des situations différentes.

Corriger ferme la faille ; il faut aussi rechercher une éventuelle intrusion

La disponibilité des correctifs apporte une réponse technique, mais elle ne dit pas ce qui s’est passé avant leur installation. Si un attaquant a déjà obtenu un accès, la mise à jour de PHP ne supprime pas à elle seule un programme malveillant qu’il aurait laissé sur le serveur. Le NCSC britannique recommande de rechercher des signes de compromission et des accès persistants, avec l’aide d’un prestataire spécialisé lorsque les compétences manquent.

Cette recherche doit être organisée avec les corrections, en préservant les traces utiles. En cas de suspicion, les spécialistes doivent déterminer ce qui a été accessible, isoler les systèmes concernés et vérifier les conditions d’une reprise sûre. Le CEO doit connaître les faits établis et les incertitudes ; l’absence d’anomalie visible ne permet pas de promettre qu’aucune donnée n’a été consultée.

Si des données personnelles sont concernées par une violation, le juridique et le délégué à la protection des données doivent évaluer les obligations de notification. Le RGPD prévoit une notification à l’autorité compétente dans les meilleurs délais et, si possible, sous 72 heures après en avoir pris connaissance, sauf si la violation n’est pas susceptible d’engendrer un risque pour les droits et libertés des personnes. La CNIL détaille cette procédure. La seule découverte d’un PHP vulnérable ne déclenche pas automatiquement une notification.

La feuille de route du CEO

Les vérifications, la réduction des accès, les corrections et la recherche d’intrusion doivent avancer en parallèle. Pour piloter la réponse, le dirigeant peut s’appuyer sur les neuf actions suivantes.

Le prochain point de direction doit permettre de répondre à quelques questions simples : nos clients peuvent-ils utiliser les services en sécurité, lesquels restent suspendus, que savons-nous d’une éventuelle intrusion et qui prend en charge chaque problème encore ouvert ? Derrière l’alerte PHP, il y a des commandes à honorer, des informations confiées par les clients et des équipes qui ont besoin de savoir comment travailler.