En bref : dans les PME, face à PHP2Shell, ce n'est que rarement l'application des correctifs qui pose problème, mais la vue d'ensemble. À côté du site web fonctionnent des portails de revendeurs, des configurateurs, des pages carrières et des wikis internes chez différents prestataires. Seule une liste complète rend le risque maîtrisable et justifiable auprès des clients et des autorités de contrôle.
Systèmes PHP typiques dans les entreprises de taille intermédiaire
Au fil des ans, les entreprises industrielles accumulent de nombreuses applications web : boutiques B2B pour pièces détachées, portails de revendeurs et de partenaires avec listes de prix, configurateurs de produits, espaces de téléchargement pour la documentation technique et les données CAO, portails de réclamations et de service, pages carrières avec gestion des candidatures. En interne s'y ajoutent des wikis comme MediaWiki, des outils de tickets et de l'analyse web.
Une grande partie fonctionne sur PHP. Ces systèmes ont souvent été commandés par des services métiers, construits par des agences et exploités chez des hébergeurs que l'informatique centrale ne connaît pas. C'est précisément là que se situe le vrai problème face à une faille comme PHP2Shell.
Quelles données et quelles connexions peuvent être concernées
Les portails contiennent des conditions clients, des interlocuteurs chez les revendeurs, des données d'offres et de commandes ainsi que des plans soumis à des accords de confidentialité. Les portails de candidatures contiennent des CV et des certificats. Pour les concurrents et les extorqueurs, les données de conception et les structures de prix ont souvent plus de valeur que les données personnelles.
Les connexions sont critiques : de nombreux portails échangent des données avec l'ERP, la gestion des stocks ou le PIM. Quiconque exécute du code sur un tel serveur web y trouve des identifiants d'interfaces, de bases de données ou de VPN. Un portail compromis peut ainsi devenir le point d'entrée dans le réseau de l'entreprise.
PME et cybersécurité : chaîne d'approvisionnement et NIS2
Avec NIS2, de nombreuses entreprises sont soumises à des obligations élargies de gestion des risques et de notification des incidents de sécurité importants. Savoir si votre entreprise est directement concernée dépend du secteur et de la taille. Beaucoup d'autres le sont indirectement, car les clients répercutent par contrat leurs exigences de sécurité sur leurs fournisseurs.
Pour la direction s'ajoute la question de sa propre responsabilité. Ce qui s'applique en général à ce sujet est expliqué sur la page consacrée à la responsabilité de la direction. L'évaluation au cas par cas relève de votre conseil juridique.
Palo Alto Networks (Unit 42) a dénombré plus de 22,6 millions d'instances exposées et potentiellement vulnérables. Un système de test oublié d'une agence est aussi visible pour les analyses automatisées que votre site principal.
Le vide de responsabilité typique dans les PME
| Domaine | Qui décide souvent | Ce qui manque |
|---|---|---|
| Site web de l'entreprise | Marketing avec agence | Justificatif de correctif pour PHP |
| Portail revendeurs, boutique B2B | Ventes avec prestataire | Intégration au concept de sécurité informatique |
| Page carrières | Personnel avec fournisseur | Clarté sur l'hébergement et les données |
| Outils internes | Services individuels | Inventaire et responsables |
L'informatique centrale est responsable du réseau, des postes de travail et de l'ERP, mais n'a souvent pas accès aux systèmes hébergés à l'extérieur. Ce schéma devient un goulot d'étranglement à chaque faille critique. Une règle simple y remédie : toute application web qui traite des données de l'entreprise est déclarée à l'informatique, avec son exploitant et son interlocuteur, avant de passer en ligne.
Séparer proprement serveur web et réseau de production
Dans l'industrie s'ajoutent des applications web qui dialoguent avec des machines et des installations : portails de service et de télémaintenance, tableaux de bord avec données de machines, portails pour les clients qui consultent l'état des installations livrées. Certaines sont construites sur PHP et se trouvent dans une zone réseau qui a plus de connexions que la tâche n'en exigerait.
Un serveur web compromis ne doit pas être un tremplin vers la production. Vérifiez quelles connexions existent depuis les zones réseau des serveurs web vers les réseaux de bureau et de production, et limitez-les au nécessaire. Les identifiants enregistrés sur les serveurs web ne devraient avoir que les droits dont l'application a réellement besoin. Pour les accès de télémaintenance, cela vaut tout particulièrement.
Premières heures pour la direction informatique et la direction générale
- Établir un inventaire de tous les systèmes PHP accessibles de l'extérieur : domaine, exploitant, version de PHP, mode d'exécution, interlocuteur.
- Traiter en premier les systèmes avec mod_php et ceux sous PHP 8.1 ou antérieur. Avec mod_php, l'équipe PHP évalue le risque comme le plus élevé.
- Pour chaque système, faire confirmer par écrit le correctif en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou le backport, et le redémarrage. Ce qui ne peut pas être confirmé est temporairement déconnecté du réseau.
- Sauvegarder les journaux à partir du 20 octobre 2026 et vérifier les connexions des serveurs web vers le réseau interne.
- Documenter brièvement l'état, afin de pouvoir répondre de façon étayée aux clients, à l'assureur et, le cas échéant, aux autorités.
Comment PHP SOS aide-t-il concrètement ?
- Nous établissons avec l'informatique et les services métiers l'inventaire des systèmes PHP et les hiérarchisons selon le risque.
- Nous coordonnons correctifs et redémarrages avec les agences et les hébergeurs et rassemblons les justificatifs en un seul endroit.
- En cas de soupçon, nous prenons en charge la réponse aux incidents structurée, avec préservation des traces et vérification des connexions vers le réseau de l'entreprise.
- Ensuite, nous proposons un audit de sécurité ou un test d'intrusion réalisé par des partenaires spécialisés, dont vous pouvez présenter le résultat à vos clients.
- Sur demande, nous surveillons les systèmes en continu afin que l'inventaire reste à jour.
Questions fréquentes
Notre entreprise relève-t-elle de NIS2 ?
Cela dépend du secteur, de la taille de l'entreprise et du chiffre d'affaires, et doit être examiné au cas par cas. Même celui qui ne relève pas directement de NIS2 en ressent souvent les exigences via ses clients dans la chaîne d'approvisionnement. Le classement contraignant, vous le clarifiez avec votre conseil juridique.
Un serveur web piraté peut-il mener au réseau de l'entreprise ?
C'est possible si le serveur web a des connexions vers le réseau interne, par exemple des interfaces vers l'ERP, des identifiants communs ou un tunnel VPN. Une vérification des connexions réseau et des identifiants enregistrés montre si c'est le cas chez vous.
Comment trouver toutes les applications PHP de l'entreprise ?
Le point de départ est constitué des entrées DNS, des certificats, des factures d'hébergement et des contrats avec les agences. Des enquêtes auprès du marketing, des ventes, du service et du personnel apportent un complément utile. En général, on y découvre des systèmes que le service informatique ne connaissait même pas.
Qu'attendent de nous les clients après PHP2Shell en tant que fournisseur ?
Certains clients demandent activement si leurs fournisseurs ont été concernés et comment ils ont réagi. Une présentation concise et documentée est utile : quels systèmes, quel état de correctifs, quand redémarrés, quelles vérifications de compromission. Promettre plus que ce qui est établi est préjudiciable.