Deux failles de PHP font craindre un sinistre cyber en série

Le 21 octobre, les mainteneurs de PHP ont publié en urgence les correctifs de deux failles critiques, désignées ensemble sous le nom de PHP2Shell. Selon CyberCube, PHP fait tourner le code d'environ 70 % des sites web. Les deux failles permettent de prendre la main sur un serveur web, ou d'y lire des mots de passe en mémoire, sans avoir à s'identifier. Les tentatives d'attaque ont bondi dans les heures qui ont suivi, et elles se comptent désormais par millions. Au 23 octobre, aucune intrusion n'était confirmée. Insurance Journal a rapporté le 27 octobre les analyses d'AM Best, de CyberCube et de Moody's sur l'affaire. Les trois notent que l'intelligence artificielle accélère la découverte de ce type de faille.

Les deux premières lectures divergent. AM Best parle d'un possible événement systémique pour les assureurs cyber, avec une traîne plus longue que prévu, parce que les pirates peuvent attendre avant d'agir et que les procès allongeront encore les délais. CyberCube voit plutôt un risque à développement long, qui rétrécira à mesure que les correctifs s'installent, et non une catastrophe unique. Elle attend quelques sinistres assurables chez des entreprises moyennes et grandes dont les serveurs n'auront pas été mis à jour.

Pour un assureur cyber, cet écart décide de qui paie. Un traité en excédent de sinistre par événement ne répond que si les sinistres s'additionnent au titre d'un même événement. Les définitions du marché combinent une cause commune, ici l'exploitation d'une même faille, et une fenêtre de temps, souvent de quelques jours à quelques semaines. Une vague d'intrusions dans les jours qui suivent le 21 octobre remonterait au réassureur. Des intrusions étalées sur six mois tomberaient une par une sous la priorité du traité, et l'assureur direct les garderait toutes. Le scénario de CyberCube, le plus rassurant pour le marché, est donc le plus lourd pour le compte de l'assureur direct.

Le deuxième point tient aux clauses de correctif. Une partie des contrats cyber réduisent la garantie quand une faille connue reste sans correctif au-delà d'un délai de grâce. CyberCube relève que PHP est souvent intégré à des produits que les clients ne peuvent pas corriger eux-mêmes, et dont ils ignorent parfois qu'ils le contiennent. Un assuré ne peut pas installer un correctif que son fournisseur ne lui a pas livré. La clause a été écrite pour le serveur que l'équipe informatique oublie de mettre à jour. Elle s'applique mal au boîtier d'un fabricant. Le Fil du 16 octobre traitait des automates de supermarchés que leur fabricant ne suivait plus. Ici le correctif existe, mais il n'atteint pas l'utilisateur, et le recours se tournera vers le fabricant du produit.

Le troisième point est politique. Les gouvernements et les agences de sécurité ont demandé de mettre à jour sans délai ou de couper les systèmes exposés. Cette consigne publique fixe une date à partir de laquelle l'assuré ne pourra plus dire qu'il ignorait la faille. Et si une campagne d'exploitation est un jour attribuée à un État, la clause de guerre cyber reviendra dans la discussion, comme pour chaque faille massive depuis NotPetya.

Le même jour, Reinsurance News publie l'enquête de WTW sur les marchés de spécialité de Londres, des Bermudes et du marché américain E&S. Au premier semestre 2026, les quinze grandes branches d'assurance et de réassurance ont toutes baissé, une fois corrigées de l'évolution des sinistres. La réassurance s'assouplit trois à quatre fois plus vite qu'en 2025. En juillet 2026, environ 65 % des hausses accumulées entre 2017 et 2023 étaient effacées. Les traités cyber du 1er janvier se négocieront dans ce climat, deux mois après un événement que personne ne sait encore chiffrer.

Notre lecture, datée du 28 octobre. Nous pensons que PHP2Shell ne fera pas de sinistre de marché pour les réassureurs. Il produira une suite de sinistres moyens, étalés sur plusieurs mois, que les assureurs directs garderont sous leurs priorités. Au 1er janvier, la discussion portera donc moins sur le prix que sur la longueur de la fenêtre d'événement et sur le sort des failles logées dans les produits de tiers. Nous relirons cette lecture aux renouvellements du 1er janvier et au premier sinistre public rattaché à PHP2Shell.

Ce qu'on ne sait pas encore. On ignore combien de serveurs restent exposés, et combien de produits embarquent PHP sans que leurs utilisateurs le sachent. On ne sait pas si des tentatives ont abouti depuis le 23 octobre, ni qui les mène. Aucun réassureur n'a encore dit si ses traités compteront PHP2Shell comme un seul événement.