La faille PHP du 21 octobre : cinq leçons, et pourquoi la sécurité commence au bureau

Que s'est-il passé le 21 octobre ?

Le mercredi 21 octobre 2026, l'organisation derrière PHP a signalé deux failles graves au cœur du logiciel. PHP est le langage de programmation sur lequel tourne une grande partie des sites web, des boutiques en ligne aux sites publics. Avec ces failles, quelqu'un pouvait exécuter son propre code sur un serveur, sans se connecter. PHP a donné aux deux failles un score de gravité de 9,2 sur 10. Toutes les versions depuis PHP 5 étaient vulnérables.

Un exemple de code était déjà public. Il montrait comment la faille fonctionnait. Le NCSC (Nationaal Cyber Security Centrum, le Centre national de cybersécurité néerlandais) n'avait pas encore vu d'abus. Mais il a demandé aux organisations d'installer la mise à jour dès qu'elle serait disponible.

Beaucoup d'organisations n'ont pas pris de risque. Par précaution, DigiD, MijnOverheid, le site de la Chambre des représentants néerlandaise et celui du NCSC lui-même, entre autres, ont été mis hors ligne. Des hôpitaux comme Haaglanden MC et St. Antonius ont aussi retiré leurs sites pour un temps. La mise à jour est arrivée à 16 h 00. Ensuite, les sites sont revenus en ligne petit à petit.

Le NCSC a souligné qu'il ne s'agissait pas d'une attaque, mais d'une erreur dans le logiciel : « un défaut de fabrication qui se trouve dans le logiciel, et cela peut arriver ». Le NCSC prévient toutefois que les suites seront longues. Lors de failles comparables, les attaquants ont continué longtemps à chercher des systèmes non mis à jour.

Chez nous aussi : voici comment nous avons agi

it-label.com tourne aussi sur PHP. Le 21 octobre, nous avons donc fait ce que nous conseillons aux autres. Nous avons d'abord regardé quels sites et systèmes étaient vulnérables. En attendant la mise à jour, nous avons surveillé les serveurs de plus près. Quand la mise à jour est sortie, nous l'avons installée le même après-midi. Ensuite, nous avons vérifié que tout fonctionnait bien et qu'il n'y avait aucune trace d'intrusion. Il n'y en avait pas.

Nous ne donnons volontairement pas plus de détails sur nos systèmes. C'est aussi une leçon : le fonctionnement exact de votre sécurité n'a pas à être public.

Cinq leçons de la faille PHP

1. Sachez ce que vous avez. Le 21 octobre, beaucoup d'organisations ne savaient pas tout de suite quels systèmes utilisaient PHP. Ne pensez pas seulement au site web, mais aussi au portail client, à l'intranet, à la boutique en ligne et aux écrans de gestion des appareils. Sans vue d'ensemble, vous ne savez pas ce qu'il faut mettre à jour.
2. Assurez-vous de pouvoir mettre à jour vite. Qui a le droit d'installer une mise à jour ? Qui a l'accès ? Combien de temps cela prend-il ? Notez-le avant d'en avoir besoin, même si votre site est chez un hébergeur ou une agence web.
3. Ayez un plan pour le jour de la faille. Qui décide de mettre un site hors ligne par précaution ? Qui informe les clients et le personnel ? DigiD et les hôpitaux ont montré qu'une mise hors ligne temporaire peut être un choix sage.
4. Construisez votre sécurité en couches. Une erreur dans une couche ne doit pas tout ouvrir. Par exemple, un serveur web ne doit pas avoir accès sans raison aux fichiers, à la comptabilité ou au réseau du bureau.
5. Après la mise à jour, ce n'est pas fini. Vérifiez que personne n'est entré avant la mise à jour. Et restez attentif : le NCSC s'attend à ce que les attaquants cherchent encore pendant des mois des systèmes non mis à jour.

Le logiciel n'est qu'une couche : la cybersécurité commence au bureau

Avec la faille PHP, toute l'attention est allée au logiciel. C'est logique, mais ce n'est qu'une partie de l'histoire. Un attaquant ne doit pas toujours passer par internet. Parfois, la porte du local serveur est le chemin le plus facile. Nous en avons déjà parlé dans La porte de votre local serveur et Pourquoi la sécurité physique de l'IT est indispensable pour la cybersécurité.

Posez-vous donc aussi ces questions :

• Le local serveur ou l'armoire de brassage est-il fermé à clé ? Et qui a la clé ou le badge d'accès ? Souvent, il s'avère que le personnel de nettoyage, les installateurs ou d'autres locataires y ont aussi accès.
• Les points d'accès Wi-Fi sont-ils protégés ? Sont-ils placés de façon qu'un visiteur puisse retirer un câble et brancher son propre ordinateur portable ? Y a-t-il un bouton de réinitialisation que tout le monde peut presser ?
• Le réseau invités est-il séparé ? Les invités, le réseau du bureau et les autres locataires doivent chacun avoir leur propre réseau.
• Où arrive la connexion internet ? Et qui a accès à cet endroit ? Dans les immeubles multi-locataires, les locataires partagent souvent un local technique.
• Les systèmes du bâtiment sont-ils séparés ? Les portiques d'accès, les caméras et la climatisation ne doivent pas être sur le même réseau que les ordinateurs portables.
• Y a-t-il une politique de cybersécurité ? Qui en est responsable ? Indique-t-elle qui fait les mises à jour, qui a accès à quels systèmes, quels accords existent avec les fournisseurs et ce que vous faites en cas de faille comme celle du 21 octobre ?

La réponse à ces questions ne se voit pas depuis votre bureau. Il faut que quelqu'un vienne regarder sur place.

Comment l'IT-Label vous aide

Avec l'IT-Label Security Audit, un spécialiste examine sur place la sécurité de votre Wi-Fi, de vos équipements réseau, du local serveur, de l'endroit où arrive la connexion internet et de la séparation entre les réseaux. Vous recevez un rapport avec ce qui va bien et ce qui peut être amélioré. Pour en savoir plus, lisez Votre informatique de bureau est-elle sûre ?

L'IT-Label montre en plus comment un bâtiment a été livré sur le plan numérique : de la connexion et du câblage jusqu'aux locaux techniques. Ainsi, propriétaires et locataires savent où ils en sont, et qui est responsable de quoi.

Questions fréquentes

Mon site web était-il aussi vulnérable ?

Si votre site web ou l'un de vos systèmes utilise PHP, il y a de fortes chances qu'il ait été vulnérable. Toutes les versions depuis PHP 5 étaient touchées. Demandez à votre agence web ou à votre hébergeur si la mise à jour est installée, et s'ils ont vérifié que personne n'est entré.

Mon site est chez un hébergeur. Dois-je faire quelque chose ?

Souvent, l'hébergeur installe la mise à jour. Mais ce n'est pas toujours le cas, par exemple avec un serveur à vous ou une ancienne formule. Renseignez-vous donc, et notez qui sera responsable des mises à jour à l'avenir.

Qu'est-ce qu'une politique de cybersécurité, et en ai-je besoin ?

Une politique de cybersécurité est un document qui décrit comment votre organisation gère la sécurité numérique : qui est responsable de quoi, qui a accès, comment les mises à jour sont faites et ce qui se passe en cas d'incident. Même pour une petite entreprise, une version courte est utile. Le jour d'une faille, chacun sait alors ce qu'il faut faire.

Le Security Audit examine-t-il aussi mon site web ?

Non. Le Security Audit examine l'IT sur place : Wi-Fi, équipements réseau, local serveur, raccordement et réseaux séparés. Pour votre site web ou vos logiciels, adressez-vous plutôt à votre agence web ou à votre fournisseur IT.

Comment savoir si mes équipements réseau sont à jour ?

Demandez à votre partenaire IT une liste de votre routeur, de votre pare-feu, de vos switchs et de vos points d'accès, avec la version du logiciel et la date de la dernière mise à jour. Pendant un Security Audit, nous vérifions aussi si les mots de passe par défaut ont été changés et qui gère les équipements.

Sachez où vous en êtes

La faille PHP a montré à quelle vitesse les choses peuvent aller. Celui qui sait ce qu'il a et qui fait quoi peut agir vite. Commencez par la base : votre bureau. Demandez un Security Audit ou inscrivez-vous à la newsletter et restez informé sur la sécurité numérique des bâtiments.

Sources : NCSC via Rijksoverheid, Failles graves dans PHP (en néerlandais) ; NOS, direct du 21 octobre 2026 (en néerlandais) ; php.net.