L'après-midi du 21 octobre, les usagers qui voulaient consulter le site de leur préfecture sont tombés sur une page de maintenance, et les sites de la CNIL et d'impots.gouv.fr affichaient des messages similaires. Aucun de ces sites n'a été signalé comme piraté. Le ministère de l'Intérieur avait mis ses sites exposés hors ligne par précaution: deux failles dans PHP, le langage utilisé par près de sept sites web sur dix dont la technologie côté serveur est connue, permettaient de prendre le contrôle d'un serveur sans s'authentifier. Leur gravité suffisait à rendre la semaine difficile pour les équipes informatiques. Ce qui l'a rendue inhabituelle, c'est la manière dont elles ont été découvertes, la vitesse de la fuite et la rapidité des attaquants.

Que s'est-il passé?

Le 20 octobre, le projet PHP a annoncé une version de sécurité pour le lendemain à 16 h, heure de Paris. Des détails ont fuité le jour même, dont une vidéo de preuve de concept publiée par erreur. Les bulletins de sécurité sont sortis le 21 octobre, peu avant l'heure prévue, avec les versions corrigées 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les branches 8.1 et antérieures n'étant plus maintenues, elles ne reçoivent aucun correctif officiel.

Le CERT-FR, le centre opérationnel de l'ANSSI, a publié le jour même l'alerte CERTFR-2026-ALE-014, mise à jour plusieurs fois depuis. Le message est clair: seule la mise à jour protège complètement. Les contournements provisoires réduisent l'exposition, et les systèmes en version non maintenue doivent être isolés, puis migrés. La mise hors ligne des sites du ministère de l'Intérieur a été faite à la demande de l'ANSSI. Universités, collectivités et plusieurs établissements publics ont pris des mesures similaires, et Cybermalveillance.gouv.fr a publié une alerte pour toutes les organisations qui exploitent un site en PHP.

Les attaquants n'ont pas attendu longtemps. Le CERT-FR constate désormais des tentatives d'exploitation, et le 26 octobre, l'agence américaine de cybersécurité (CISA) a confirmé une exploitation active et donné trois jours aux agences fédérales pour corriger.

Comment l'IA a changé la donne

Le défaut de fond n'était pas nouveau. Repéré lors d'un audit en 2024, il était resté sans correctif, faute de démonstration d'une exploitation possible. La PHP Foundation reconnaît aujourd'hui que «le retard était un échec structurel».

En 2026, la recherche assistée par l'IA a comblé cet écart. Un chercheur de Calif a trouvé un moyen d'exploiter la faille avec GPT-5.6 Sol, dans le cadre de l'initiative Patch the Planet d'OpenAI, et Wiz a découvert les deux failles de son côté, avec plusieurs modèles d'IA et ses propres outils. OpenAI affirme qu'à sa connaissance, l'IA de pointe a trouvé ces vulnérabilités avant les attaquants. La réalité est plus nuancée: Amazon a signalé une tentative d'exploitation quatre jours avant la divulgation.

Trois changements ressortent de cet épisode:

• Les vieux bogues deviennent exploitables. Des défauts jugés sans danger pendant des années peuvent devenir critiques dès que des outils d'IA les testent à grande échelle. OpenAI s'attend à ce que ce type de découvertes augmente fortement dans les prochains mois.

• La divulgation devient plus difficile à maîtriser. La fuite, la preuve de concept publiée par erreur et les premières attaques ont réduit à quelques heures la fenêtre entre l'annonce et l'exploitation.

• Les attaquants utilisent les mêmes outils. Une campagne décrite par la société de recherche Dream a combiné PHP2Shell et une faille Linux pour compromettre 25 pare-feu exposés sur Internet aux États-Unis et en Asie, avec un exploit sur mesure et des outils assistés par l'IA, selon The Hacker News.

Trouver les failles va plus vite. Les corriger dépend toujours des équipes. Biswajeet Mahapatra, analyste principal chez Forrester, l'expliquait à CSO Online: l'expertise rare devient nécessaire ailleurs, pour trier les failles, juger de leur exploitabilité, sécuriser les correctifs, choisir le moment de la divulgation et déployer en production.

Ce que cela change pour votre organisation

Savoir où tourne PHP

PHP ne tourne pas seulement sur vos propres serveurs web. Il est intégré à des panneaux d'administration, à des équipements de fournisseurs et à des produits que vos équipes n'associent pas forcément à PHP, ainsi qu'aux serveurs gérés par votre hébergeur. Le CERT-FR renvoie à une liste de produits potentiellement concernés, tenue par le NCSC néerlandais. Un inventaire qui recense les composants, et pas seulement les systèmes, permet de répondre rapidement à la question «sommes-nous concernés?».

Prévoir des correctifs en quelques heures

Une procédure de changement d'urgence fonctionne mieux si elle est décidée avant l'urgence. Définissez qui peut appliquer un correctif hors cycle, qui peut mettre un service hors ligne, comme l'a recommandé l'ANSSI, et quelles mesures compensatoires vous acceptez en attendant. Les règles de pare-feu applicatif (WAF) et les changements de configuration font gagner du temps, sans remplacer le correctif.

Se préparer aux questionnaires fournisseurs, dans les deux sens

En moins d'une journée, des clients, y compris les nôtres, envoyaient des questionnaires à leurs fournisseurs: êtes-vous concerné, quand avez-vous corrigé, pouvez-vous démontrer l'absence d'exploitation? Préparez une réponse factuelle réutilisable, avec une chronologie et les vérifications effectuées. Posez les mêmes questions à vos fournisseurs critiques et conservez leurs réponses. La directive NIS2 inclut la sécurité de la chaîne d'approvisionnement dans les mesures de gestion des risques en matière de cybersécurité, et le règlement DORA attend la même vigilance envers les prestataires tiers de services TIC.

Vérifier vos obligations de déclaration

Une vulnérabilité corrigée n'est pas en soi un incident à déclarer. Une exploitation avec des conséquences peut l'être. En cas de violation de données, le RGPD vous laisse en principe 72 heures pour la notifier à la CNIL. Les entités financières évaluent l'événement au regard des critères DORA des incidents majeurs liés aux TIC. Les entités soumises à NIS2 doivent adresser une alerte précoce dans les 24 heures en cas d'incident important, mais en France, le projet de loi Résilience qui transpose la directive n'est toujours pas adopté. Enfin, depuis le 11 septembre 2026, le règlement européen sur la cyberrésilience (Cyber Resilience Act, CRA) impose aux fabricants de signaler sous 24 heures les vulnérabilités activement exploitées dans leurs produits.

Documenter les décisions

Mettre un site hors ligne, accepter un contournement ou repousser la migration depuis PHP 8.1 sont des décisions de risque. Notez qui a décidé, quand et sur quelle base. C'est ce dont la direction aura besoin pour montrer qu'elle a supervisé la réponse, et ce qu'une autorité ou un client vous demandera plus tard.

Comment nous avons géré l'incident chez Formalize

La plateforme Formalize fonctionne avec PHP: ces failles nous concernaient donc aussi, jusqu'à ce que nous appliquions le correctif, le 21 octobre à 15 h 45, heure de Paris. Nous étions entièrement protégés 11 minutes après la publication des vulnérabilités. Auparavant, des règles de pare-feu mises en place quelques heures plus tôt bloquaient le principal vecteur d'attaque. Nous n'avons trouvé aucun signe d'intrusion ni d'accès aux données de nos clients. Ceux-ci ont reçu notre déclaration écrite dès le lendemain, et ils n'avaient rien à faire.

Centraliser incidents, fournisseurs et décisions

Formalize attribue à chaque incident une fiche avec ses responsables, ses décisions et ses preuves, et transforme l'alerte précoce, la notification d'incident et le rapport final en tâches avec échéances. Les questionnaires fournisseurs et leur suivi se trouvent à côté de vos risques et de vos contrôles: votre réponse à la prochaine question «êtes-vous concerné?» part de données que vous tenez déjà à jour.

Cet article est fourni à titre informatif et ne constitue pas un avis juridique.