Ce qu’il faut retenir
- Le 21 octobre 2026, deux failles critiques de PHP, découvertes avec l’aide de modèles d’IA, ont conduit de nombreux organismes à couper eux-mêmes leurs sites. Le même jour, le réseau mobile d’Orange a connu un incident majeur sans lien connu avec ces failles.
- Pour un assureur ou un courtier, la journée pose trois questions : de quels composants et opérateurs dépend réellement l’activité, comment les contrats cyber répondent à une coupure préventive sans attaque, et que vaut une accumulation de sinistres le même jour.
- Pour les entreprises d’assurance et les intermédiaires qui y sont soumis, DORA fournit déjà le cadre : registre des prestataires TIC, tests et notification des incidents majeurs. Les intermédiaires qui sont des PME en sont exclus, mais pas du risque.
- L’IA raccourcit le délai entre découverte et exploitation. La gouvernance des correctifs devient un sujet de direction, pas seulement d’exploitation informatique.
Une journée, deux défaillances sans lien
La vidéo « Orange et sites down : Il s’est passé quoi le 21 octobre 2026 ? », publiée par la chaîne CodingBiceps, reconstitue la journée heure par heure et démêle ce que les réseaux sociaux avaient confondu. Deux faits, établis par des sources officielles, suffisent pour l’analyse.
D’abord, PHP a publié le 21 octobre les correctifs de deux vulnérabilités notées 9,2 en CVSS v4.0, CVE-2026-109618 et CVE-2026-109619 (php.net). Elles permettent, dans certaines configurations, d’exécuter du code sur le serveur, avant même que l’application ne démarre lorsque PHP tourne avec Apache et mod_php, et aucune parade complète n’existe. Le CERT-FR a émis l’alerte CERTFR-2026-ALE-014. Le ministère de l’Intérieur a mis en maintenance ses sites exposés à la demande de l’ANSSI, et d’autres organismes publics l’ont imité, selon Actu17.
Ensuite, Orange a reconnu des perturbations dès le matin, puis a qualifié dans la soirée d’incident technique majeur la panne de son réseau mobile survenue depuis la fin de matinée, qui touchait particuliers et entreprises. Le service a été rétabli dans la soirée et la panne attribuée à un équipement du cœur de réseau, selon franceinfo. Aucune source officielle ne relie les deux événements.
Deux causes différentes donc, mais une même leçon : une organisation peut perdre une journée d’activité sans avoir été attaquée, simplement parce qu’une brique commune ou un opérateur unique fait défaut.
L’IA accélère la découverte, pas seulement l’attaque
La chronologie publiée par la PHP Foundation est un cas d’école. La société Calif signale la faille le 11 août dans le cadre du programme « Patch the Planet » d’OpenAI. Le même jour, OpenAI signale de façon indépendante la même cause, puis Wiz la signale à son tour le 24 août. Calif indique avoir travaillé sans outil ni modèle réservé. Wiz crédite explicitement des modèles d’IA dans sa découverte.
Ce point mérite l’attention des directions. Selon Wiz, un chercheur seul a accompli en une semaine ce qui aurait pris des mois à une équipe de premier plan. Ce gain de temps profite aux défenseurs comme aux attaquants. La PHP Foundation reconnaît elle-même un échec structurel : son équipe de sécurité, qui décide au consensus, a tardé à choisir une correction, en raison de son processus de décision et du manque de moyens. Le correctif est finalement sorti un jour plus tôt que prévu, après la diffusion prématurée des numéros de failles.
Pour l’assurance, la conséquence est double. Le délai entre la publication d’une faille et son exploitation se réduit, ce qui rend décisive la capacité à déployer un correctif en heures plutôt qu’en semaines. Et les composants libres massivement utilisés, entretenus par de petites équipes, deviennent des points de concentration du risque que les questionnaires de souscription capturent mal.
Cartographier la dépendance réelle
La plupart des cartographies de prestataires s’arrêtent au contrat : l’éditeur du logiciel de gestion, l’hébergeur, l’opérateur. Le 21 octobre montre qu’il faut descendre d’un niveau, vers les composants partagés et les canaux de secours.
| Dépendance | Question de direction | Indicateur à suivre |
|---|---|---|
| Socle logiciel des sites et extranets (PHP, CMS, bibliothèques) | Savons-nous quelles versions tournent, y compris chez nos prestataires ? | Inventaire à jour, délai de déploiement d’un correctif critique |
| Portails de souscription et de gestion exposés à internet | Pouvons-nous couper un portail sans interrompre la relation client ? | Procédure de maintenance, canal de contact de secours |
| Opérateur mobile unique | Nos astreintes, alertes et authentifications passent-elles toutes par le SMS d’un seul opérateur ? | Part des accès protégés par SMS, numéros critiques chez un second opérateur |
| Prestataires de gestion déléguée et courtiers grossistes | Leur indisponibilité bloque-t-elle nos émissions ou nos encaissements ? | Engagements de service, plans de continuité testés |
Pour un courtier, l’enjeu est concret : il suffirait d’un extranet assureur fermé par précaution, d’une plateforme de tarification indisponible ou d’un téléphone muet pour arrêter la production, sans qu’aucun sinistre ne soit déclaré.
La coupure préventive, angle mort des contrats cyber
Le 21 octobre, beaucoup d’organisations ont subi une interruption sans avoir été attaquées : elles ont coupé leurs services pour ne pas l’être. Or la plupart des garanties de pertes d’exploitation cyber sont déclenchées par un événement défini (intrusion, logiciel malveillant, parfois défaillance non malveillante du système). Une mise hors ligne décidée par l’assuré, sur recommandation d’une autorité, n’entre pas toujours dans ces définitions.
Trois points méritent d’être relus dans les contrats en portefeuille, sans présumer de leur réponse :
- Les mesures conservatoires : le contrat prévoit-il la prise en charge de frais ou de pertes liés à une action raisonnable pour prévenir une atteinte imminente ?
- La défaillance du système et la carence des prestataires : l’option est-elle souscrite, et couvre-t-elle un hébergeur ou un opérateur de télécommunications ?
- Les franchises en heures : une interruption d’un après-midi dépasse-t-elle le seuil de déclenchement ?
Côté souscription, l’épisode plaide pour des questions plus précises : délai effectif de déploiement des correctifs critiques, existence d’une page de maintenance servie hors de la pile applicative, diversité des canaux d’alerte. Ces éléments disent davantage sur la résilience qu’une case cochée « mises à jour régulières ».
Un événement d’accumulation pour les portefeuilles
Une faille dans un composant présent sur une grande partie du web peut toucher, le même jour, un grand nombre d’assurés d’un même portefeuille cyber. C’est la définition d’un risque d’accumulation. À la date de rédaction, aucune intrusion massive n’avait été rendue publique, alors que Cloudflare signalait de premières attaques. Mais le scénario mérite d’être joué dans les modèles internes : combien de polices seraient déclenchées si une telle faille était exploitée à grande échelle, quelle part relèverait de la perte d’exploitation, et quelles exclusions d’événement systémique s’appliqueraient.
La panne d’Orange rappelle un second type d’accumulation, non malveillant : la défaillance d’une infrastructure partagée. Pour les contrats qui couvrent la carence de fournisseurs, un opérateur national indisponible quelques heures concerne potentiellement tout un portefeuille de petites entreprises.
Ce que DORA demande déjà
Pour les entreprises d’assurance et de réassurance, ainsi que pour les intermédiaires qui n’entrent pas dans la catégorie des PME, le règlement (UE) 2022/2554, dit DORA, s’applique depuis le 17 janvier 2025. Il impose notamment un registre des accords avec les prestataires de services TIC, une gestion du risque lié à ces prestataires, des tests de résilience et la notification des incidents majeurs liés aux TIC à l’autorité compétente. Les intermédiaires d’assurance qui sont des micro, petites ou moyennes entreprises sont exclus de son champ, comme le confirme une réponse de la Commission européenne publiée par l’EIOPA (Q&R DORA237).
Le 21 octobre offre un test grandeur nature pour vérifier que ce registre descend jusqu’aux composants critiques et que la qualification d’un incident est prête : une coupure volontaire de plusieurs heures d’un portail client est-elle un incident majeur au sens de vos critères ? Pour articuler ces obligations avec le RGPD et l’AI Act, voir l’analyse qualifier un incident sous l’AI Act, DORA et le RGPD.
Un courtier exclu de DORA n’est pas pour autant à l’abri. Ses clients, ses assureurs partenaires et ses propres obligations de conseil attendent de lui une continuité minimale. Les mêmes réflexes, proportionnés, valent pour une structure de quelques personnes.
Grille de décision pour un comité de direction
- Inventorier les composants logiciels exposés à internet et leurs versions, y compris chez les prestataires, et fixer un délai cible de correction pour les failles critiques.
- Décider à l’avance qui peut ordonner la mise hors ligne d’un service, sur quels critères, et comment les clients sont prévenus.
- Diversifier les canaux : alertes, astreintes et authentification forte ne doivent pas dépendre du SMS d’un seul opérateur.
- Relire les contrats d’assurance cyber et de pertes d’exploitation de l’entreprise au regard d’une coupure préventive et d’une carence d’opérateur.
- Pour les assureurs, intégrer ce type d’événement dans les scénarios d’accumulation et dans les questionnaires de souscription.
- Mesurer après chaque alerte majeure le délai réel entre publication et déploiement, et en rendre compte au comité des risques.
Questions fréquentes
Une entreprise qui a coupé son site par précaution peut-elle être indemnisée ?
Cela dépend des définitions de son contrat. Une garantie limitée aux attaques avérées ne répondra probablement pas. Une garantie qui couvre les mesures conservatoires ou la défaillance du système peut répondre, sous réserve des franchises et des plafonds.
Le 21 octobre est-il un incident majeur au sens de DORA pour un assureur ?
Il n’y a pas de réponse générale. La qualification dépend des critères de classification de l’entité : services touchés, durée, clients concernés, impact. L’important est d’avoir documenté la décision le jour même.
Faut-il abandonner PHP ?
Non. La question n’est pas le langage, mais la capacité à connaître ses versions et à corriger vite. Tout composant largement partagé présente le même profil de risque.
Sources
- CodingBiceps, « Orange et sites down : Il s’est passé quoi le 21 octobre 2026 ? », vidéo YouTube, 22 octobre 2026
- php.net, versions correctives du 21 octobre 2026
- PHP Foundation, billet du 21 octobre 2026
- CERT-FR, CERTFR-2026-ALE-014
- Calif et Wiz, 21 octobre 2026
- Communiqué d’Orange et franceinfo, 21 octobre 2026
- Règlement (UE) 2022/2554 (DORA) et EIOPA, Q&R DORA 237
Analyse rédigée le 22 octobre 2026 à partir des informations publiques disponibles à cette date.
