Le 21 octobre 2026 à 14 h UTC, le projet PHP a publié des correctifs pour deux failles qui permettent d’exécuter du code à distance, sans mot de passe, sur un serveur qui fait tourner le langage. PHP fait tourner environ 69 % des sites dont on connaît le langage côté serveur (W3Techs), dont WordPress, Drupal, Joomla et MediaWiki. TechCrunch a résumé l’épisode par une formule, « PHP-ocalypse », selon laquelle deux bugs auraient failli « casser Internet » (article du 24 octobre).
Nous avons voulu savoir ce que les documents disent vraiment. Nous avons lu l’annonce du projet et les avis GitHub, la fiche NVD, le récit des chercheurs qui ont trouvé les failles, celui de la PHP Foundation, les alertes de la CISA, du CERT-FR et de CERT-EU, et les rapports d’Amazon, de Cloudflare, de Palo Alto Networks, de Wiz, de Sophos, d’Arctic Wolf, de Censys et de Datadog. Trois constats en ressortent : les failles sont réelles et graves, la divulgation a dérapé, et la preuve d’une exploitation à grande échelle n’existe pas à ce jour, malgré des signaux inquiétants. Les sources se contredisent sur plusieurs points, que nous signalons au fil du texte.
Nous avons déjà couvert l’annonce du jour (deux failles critiques et leurs correctifs) et le contexte d’une journée noire pour la sécurité. Cette enquête reprend les faits depuis la source.
Deux CVE, ce que disent les avis officiels
L’avis du projet PHP (php.net) et les deux avis GitHub (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp) décrivent deux failles. La CVE-2026-109618 tient à la gestion d’un manque de mémoire : PHP abandonne une requête avec longjmp() alors que sa mémoire n’est qu’à moitié initialisée, et le nettoyage de fin de requête lit ensuite cet état invalide. La CVE-2026-109619 concerne un état global qui survit à la libération de la mémoire de sa requête : une opération exécutée avant l’initialisation de la requête suivante peut le réutiliser (utilisation après libération). Le correctif de la première supprime longjmp() pour ces erreurs et le remplace par une gestion différée jusqu’à un point sûr.
Le score est de 9,2 sur l’échelle CVSS 4.0 pour les deux. Son vecteur précise toutefois que l’attaque est à complexité élevée et que des conditions d’attaque doivent être réunies (AC:H, AT:P), sans privilège ni interaction de l’utilisateur. Autrement dit, la note maximale de l’annonce ne dit pas que l’exploitation est triviale. La base NVD (fiche de la CVE-2026-109618), publiée le 21 octobre à 14 h 17 UTC, y ajoute ses propres scores CVSS 3.1 : 9,8 pour la première, 8,1 pour la seconde.
Les impacts confirmés sont précis. Pour la CVE-2026-109618, une exécution de code non authentifiée, sous le compte du processus web, validée sur Apache avec mod_php et les limites par défaut. Pour la CVE-2026-109619, le chemin confirmé passe par le suivi des erreurs fatales sous PHP 8.5, contre mod_php, avec aussi un chemin par la progression des envois de session. Datadog précise que, sous PHP-FPM, l’attaque exige en plus que l’application effectue une opération adaptée après le démarrage de la requête (Datadog Security Labs). Wiz, de son côté, parle de quatre bugs regroupés en deux CVE et affirme qu’un attaquant peut lire la mémoire du processus à distance, sans exécuter de code (Wiz Research). La faille est dans PHP lui-même : une application « Hello World » sur une version vulnérable peut être touchée, quel que soit le CMS.
Les chercheurs de Calif, auteurs du récit technique de référence (calif.io), expliquent le déclencheur : une erreur fatale provoquée par la pression sur la limite de mémoire memory_limit, par exemple avec des envois de fichiers multipart aux noms imbriqués.
Une troisième faille, déjà. Le 23 octobre, PHP a signalé la CVE-2026-115560, liée à la progression des envois de session. D’après CERT-EU, c’est une troisième exécution de code à distance, qui ne touche que des applications configurées de façon inhabituelle ; PHP ne publiera pas de version hors cycle (avis CERT-EU 2026-018). D’après Cloudflare, elle affecte même les versions entièrement corrigées, dont la 8.5.12, et son correctif attendra la prochaine version régulière (Cloudflare). Datadog juge en outre que d’autres variantes du même type de bug sont probables, car l’insertion dans la table de hachage met encore à jour ses compteurs avant d’allouer la clé dans PHP 8.5.12.
Dernier détail : le 20 octobre, vers 15 h UTC, les deux identifiants CVE circulaient en ligne avec une mauvaise date et un score de 10,0, rapporte la PHP Foundation. Le score réel est de 9,2.
« Il n'existe aucune atténuation complète, mettre à jour est le seul choix sûr. »
Les versions : un correctif qui ne couvre pas tout le monde
Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. La PHP 8.6.0 RC4 les contient aussi. Pour les branches 7.4, 8.0 et 8.1, qui ne sont plus supportées, le projet ne fournit que des correctifs minimaux à compiler soi-même, et certaines distributions proposent leurs propres rétroportages. La branche 8.2 atteint sa fin de vie le 31 décembre 2026. Le CERT-FR liste comme affectées toutes les versions 5.x, 7.x, 8.0.x et 8.1.x, et recommande, pour ces versions non maintenues, d’isoler les équipements puis de migrer (alerte CERTFR-2026-ALE-014).
Cela compte parce que le parc est vieux. D’après W3Techs, 26,8 % des sites en PHP tournent sous une version 7.x et 7,7 % sous une 5.x, soit plus d’un tiers du parc sur des branches dont le support est terminé. Le chiffre de 69,3 % d’usage global ne s’applique qu’aux sites dont le langage serveur est connu. L’immense majorité des sites sous PHP 8 dispose d’un correctif, mais dépend de son hébergeur pour l’appliquer, et des millions d’autres n’ont qu’un correctif minimal ou rien. Les éditeurs de CMS ne changeront pas la donne : WordPress indique qu’aucune mise à jour du CMS n’est requise ni prévue (WordPress), et Drupal que seul un PHP corrigé est une atténuation complète, la responsabilité de l’équipe de sécurité de Drupal s’arrêtant au code hébergé sur Drupal.org (PSA-2026-10-20).
Une faille ancienne : vingt ans de signaux
TechCrunch écrit que les deux bugs avaient été découverts en 2024 mais jugés inexploitables, donc non corrigés. La réalité documentée est plus nuancée. Selon la chronologie de Calif, un premier bug de limite de mémoire date de 2004 (Stefan Esser), un bug signalé en 2020 porte le numéro 78876, et un audit de 2024, mené par Quarkslab pour l’OSTIF, a repéré un problème lié sans en prouver l’exploitation. La PHP Foundation précise qu’un développeur du cœur en avait retrouvé les premiers signes en 2024 en corrigeant un autre bug.
Une réserve : la page de l’OSTIF consacrée à cet audit (ostif.org) ne mentionne ni la mémoire ni ces erreurs de type « out of memory ». Elle liste 27 constats, dont 17 ayant un impact sur la sécurité et quatre CVE, tous corrigés. Le lien avec PHP2Shell vient donc du récit de Calif et de la PHP Foundation, pas du rapport d’audit lui-même. À confirmer auprès de l’OSTIF ou de Quarkslab.
Six semaines de coordination, des dates qui divergent
| Date (2026) | Événement | Source |
|---|---|---|
| 30 juillet / 1er août | Calif commence l’audit de PHP (la PHP Foundation dit le 30 juillet, Calif le 1er août pour la découverte) | PHP Foundation ; Calif |
| 11 août | Premier bug signalé à PHP ; une exécution de code est démontrée le 14, confirmée par PHP le 15 | Calif ; PHP Foundation |
| 19-21 août | Wiz trouve une première faille (19), la confirme sur Drupal (20) puis WordPress (21). Calif signale un second bug (21) | Wiz ; Calif |
| 24 août | Wiz signale à PHP. OpenAI signale la même cause racine, puis d’autres vecteurs le 18 septembre | Wiz ; PHP Foundation |
| 21 septembre | PHP accuse réception à Wiz et commence un correctif coordonné | Wiz |
| 17 octobre | Première tentative d’exploitation relevée par Amazon, sur un honeypot | Amazon |
| 20 octobre | Les CVE circulent (15 h UTC) ; pré-annonce de PHP (19 h 30) ; Calif publie par erreur une vidéo de sa preuve de concept (vers 20 h) ; conseils d’atténuation aux fournisseurs d’infrastructures critiques (23 h) | PHP Foundation |
| 21 octobre | Preuves de concept observées par Amazon dès 2 h UTC ; règles de pare-feu de Cloudflare actives à 3 h 02 UTC ; Chainguard publie des images corrigées à 7 h 41 UTC ; correctifs officiels à 14 h UTC, avancés d’un jour ; fiche NVD publiée à 14 h 17 UTC | Amazon ; Cloudflare ; PHP Foundation ; NVD |
| 22-23 octobre | Preuves de concept signalées par le CERT-FR (22) ; troisième faille signalée par PHP (23) | CERT-FR ; PHP |
Cinq écarts méritent d’être notés. TechCrunch situe les premiers signes d’exploitation vers le 17 octobre « environ une semaine avant les correctifs » ; Amazon, source primaire, parle de quatre jours avant la divulgation. TechCrunch nomme l’initiative qui a mené à la découverte « Hack the Planet », quand la PHP Foundation écrit « Patch the Planet ». TechCrunch crédite Calif, avec Wiz et OpenAI pour vérifier les preuves de concept ; les avis GitHub, eux, nomment quatre rapporteurs, dont des comptes liés à Wiz et à OpenAI, et Cloudflare cite Calif, Wiz, OpenAI et Quarkslab : Wiz et OpenAI ont donc aussi découvert, de leur côté, la même cause racine. TechCrunch écrit aussi que Trail of Bits a confirmé des compromissions ; NBC classe Trail of Bits parmi les neuf éditeurs qui n’avaient vu aucune attaque réussie jusqu’au jeudi soir, et ce que nous avons trouvé de sa part est la démonstration d’un exploit, pas le constat d’une intrusion chez un tiers. Enfin, Cloudflare dit avoir activé ses règles environ neuf heures avant la divulgation, ce qui fait onze heures si l’on retient l’heure de publication de 14 h UTC.
La divulgation qui a dérapé
Le principe de la divulgation coordonnée : prévenir les mainteneurs et les grands acteurs, laisser le temps de préparer un correctif, publier tout le monde en même temps. Ici, l’ordre a été rompu sur plusieurs fronts. Selon la PHP Foundation, les identifiants CVE ont fuité avec de mauvaises informations, Calif a publié par accident une vidéo de preuve de concept, et des conseils d’atténuation confiés à des fournisseurs d’infrastructures critiques ont circulé.
Le point le plus contesté est le geste de Chainguard, fournisseur d’images de conteneurs. La PHP Foundation l’accuse d’avoir rompu l’embargo en publiant, à 7 h 41 UTC le 21 octobre, des images contenant le correctif plus de six heures avant l’heure convenue, ce qui permettait à n’importe quel attaquant d’étudier le correctif sous forme binaire. Elle écrit que cela « a ignoré des semaines de travail de nombreux acteurs ». Le directeur général de Chainguard, Dan Lorenc, ne conteste pas la chronologie mais nie toute fuite : selon lui, les gens étaient déjà attaqués, et la règle de l’entreprise est la divulgation coordonnée « sauf preuve d’exploitation active dans la nature » (The Register). Il dit avoir appris, le vendredi, que quelque chose arrivait sur PHP, puis retrouvé les bugs avec son propre outil d’IA. L’avis de Chainguard à ses clients (page de support) ne revient pas sur l’embargo, mais il confirme l’avance : la console peut afficher une image mise à jour « plusieurs heures avant la divulgation », ce que l’entreprise juge normal, car elle a construit les images corrigées « dans la nuit, avant la divulgation publique ». Ses avis de sécurité, eux, sont datés de 15 h 40 UTC le 21 octobre, soit après l’heure officielle.
Un rapprochement d’horaires, que nous donnons sans en tirer de conclusion : les identifiants CVE circulaient dès le 20 octobre à 15 h UTC, la vidéo de Calif a été publiée vers 20 h, Amazon observait des preuves de concept dès 2 h UTC le 21, et les images de Chainguard datent de 7 h 41 UTC. Le désaccord porte sur le critère : à partir de quel niveau de preuve d’exploitation un acteur peut-il s’affranchir d’un embargo ? Amazon a bien observé une tentative le 17 octobre, mais sur un honeypot, et sans savoir comment l’attaquant avait obtenu l’information. L’épisode pose une question de fond, que nous posons sans y répondre : un embargo qui fuit plus vite qu’il ne protège vaut-il encore d’être maintenu ? OpenAI pose elle-même la question dans son billet : quels éléments devraient déclencher une divulgation anticipée, « surtout lorsque certains utilisateurs peuvent être protégés avant les autres » ? Son cadre prévoit de revoir le calendrier en cas d’exploitation active, de fuite ou de correctif public révélateur. Amazon écrit, de son côté, que la divulgation coordonnée reste le bon modèle, mais qu’un embargo ne protège que jusqu’à ce que quelqu’un d’autre trouve le même bug.
Exploité ou pas ? Ce que disent les sources
C’est le point où le titre de TechCrunch dépasse le plus ce que les documents établissent. Voici ce que chacun affirme.
| Source | Ce qu’elle affirme |
|---|---|
| Amazon (honeypot MadPot) | Tentative le 17 octobre depuis un réseau d’anonymisation ; plusieurs preuves de concept dès 2 h UTC le 21, puis d’autres tentatives jusqu’à 8 h, probablement de plusieurs acteurs ; « PHP2Shell connaît désormais des tentatives d’exploitation à grande échelle dans la nature », mais on ignore si elles auraient réussi sur des systèmes réels, et « la compromission peut précéder l’avis » (billet de CJ Moses, directeur de la sécurité d’Amazon) |
| Palo Alto Networks (Unit 42) | A vu des preuves de concept ; au moins un gouvernement européen a coupé son site par précaution. Dans un cas, des attaquants ont obtenu en deux heures, après l’exploitation initiale, des empreintes de mots de passe et des secrets MFA, ouvert un tunnel NTLM vers Active Directory et tenté une élévation. La note ne précise ni la victime ni la méthode d’accès initial, et ne dit pas expressément qu’elle passait par ces deux CVE |
| Cloudflare | A vu du trafic d’attaque contre ses clients et des charges modifiées pour contourner ses règles, sans publier de chiffre |
| Sophos | Billet du 22 octobre (16 h 18 UTC) faisant état d’une exploitation réussie, rectifié à 21 h 21 UTC : aucune compromission réussie, quelques tentatives échouées, charge bloquée. Sophos juge l’exploitation difficile |
| Arctic Wolf | Scans et tentatives massifs, dont des charges de type botnet Potassium (dérivé de Mirai) ; l’exploitation précoce est « plus limitée que l’attention initiale ne le laissait penser » ; ses données n’établissent pas que les binaires ont été téléchargés ni exécutés |
| Censys (synthèse) | VulnCheck : une tentative échouée, un exploit privé fonctionnel pour la CVE-2026-109618 ; watchTowr : tentatives sur ses honeypots ; Dataminr : surtout des scans, des tentatives non fonctionnelles ; Centre canadien : aucune exploitation active (21 octobre) |
| CISA | « N’a pas observé d’exploitation réussie dans la nature » (alerte du 21 octobre, révisée le 23). Les deux CVE n’apparaissent pas dans son catalogue d’exploitations connues, dans la version du 23 octobre à 19 h 30 UTC que nous avons consultée |
| Datadog | Son exploit de laboratoire s’exécute en 3,1 secondes ; selon lui, calibrer l’allocation et contourner l’ASLR n’empêchent pas l’exploitation |
| Trail of Bits (Dan Guido, X) | Le 22 octobre : un exploit fonctionnel qui obtient un shell sur une installation non modifiée de MediaWiki. Dans un message ultérieur : exploit « de niveau production », avec la configuration php.ini-production standard, display_errors désactivé, memory_limit normal, plusieurs workers, ASLR et charge, sur ARM64 et x86-64, contre MediaWiki, WordPress, phpBB et Laravel, sous Apache/mod_php et nginx/PHP-FPM (message sur X). Affirmations de l’entreprise, non vérifiées de façon indépendante ; une vidéo de 25 secondes les accompagne |
| Neuf éditeurs, selon NBC | CrowdStrike, ESET, Google Threat Intelligence, Huntress, Palo Alto Networks, Recorded Future, SecureWorks, Sophos et Trail of Bits disent n’avoir vu aucune attaque réussie jusqu’au jeudi 22 octobre au soir. Palo Alto (Sherrod DeGrippo) recense plus de 200 exploits de démonstration, sans exploitation active confirmée ; Cloudflare (Matthew Prince) affirme qu’aucun de ses clients n’a été touché (NBC News) |
| Elias Taylor (blog, 21 octobre) | Les preuves de concept publiques « ne fonctionnent pas » sur un PHP standard ; aucun botnet repéré dix heures après la publication. Le billet recommande quand même de corriger (billet) |
| Google (J. Hultquist), Expel (M. Hutchins) | Aucune exploitation dans la nature validée ni exploitation de masse vue, mais une exploitation à petite échelle est possible |
Sources : Amazon, Unit 42, Cloudflare, Sophos, Arctic Wolf, Censys, CISA, catalogue KEV, Datadog et The Record.
Que conclure ? Une compromission réelle est décrite par Unit 42 chez un gouvernement européen, mais par une seule source, qui ne précise pas comment l’accès initial a été obtenu, et le 22 octobre, la responsable de Palo Alto citée par NBC disait elle-même ne connaître aucune exploitation active confirmée : soit les constats d’Unit 42 sont postérieurs, soit les deux positions divergent, ce qu’il faut demander à l’entreprise. En face, aucune exploitation de masse n’est établie, et Sophos a corrigé son propre billet en cinq heures.
Entre « difficile » et « de niveau production », la discussion porte surtout sur la différence entre une preuve de concept et un exploit fiable : Dan Guido rappelle à NBC que beaucoup de gens les confondent, et que son équipe a mis une journée, avec un modèle d’IA et un chercheur de dix ans d’expérience, à exploiter la faille. Un détail de vocabulaire compte aussi : le billet d’Amazon, lu en entier, parle de tentatives d’exploitation « à grande échelle » et précise qu’on ignore si elles auraient réussi, alors que Censys le résume en « exploitation large » de la CVE-2026-109618. Entre tentatives et succès, le fossé est considérable. La difficulté de l’exploit est elle-même contestée : Sophos, VulnCheck et le blog d’Elias Taylor la jugent réelle pour les preuves de concept publiques, Datadog affirme qu’elle n’empêche rien, et Trail of Bits dit disposer d’un exploit fiable sur plusieurs applications. Les deux positions peuvent être vraies : un exploit privé et abouti n’invalide pas le constat que les codes publics ne marchent pas.
Le responsable de la sécurité de Cobalt, Andrew Obadiaru, prévient que l’absence de compromissions confirmées ne durera pas, car les attaquants affinent leurs outils « à découvert » ; c’est une appréciation, pas un fait. Ce qui est sûr : les tentatives ont commencé avant la publication, et la suite dépendra d’un exploit fiable, dont VulnCheck détient une version privée.
Combien de serveurs ? Des chiffres qui ne se comparent pas
Le nombre de serveurs exposés varie selon qui compte. Cortex Xpanse (Palo Alto) a identifié plus de 22,6 millions d’instances potentiellement vulnérables. Censys, cité par The Record, comptait plus de 41 millions de services PHP exposés tournant sous des versions affectées au 22 octobre, contre environ un million sous une version corrigée. Dans sa propre synthèse du 23 octobre, Censys donne un autre type de chiffre : 4 184 559 hôtes et 67 597 101 propriétés web qui exécutent PHP, des totaux supérieurs à ses premiers relevés parce qu’il a amélioré sa détection, pas parce que l’exposition a grandi. Il précise que les hôtes sont classés « corrigés » ou « affectés » d’après la version déclarée, et que ce classement peut tromper sur les branches 7.4, 8.0 et 8.1, qui reçoivent des correctifs sans changer de numéro de version. Le plus honnête est de retenir un ordre de grandeur, des dizaines de millions de services exposés, et la tendance, à la baisse.
Le rôle de l’IA : plus nuancé que le slogan
L’épisode est aussi présenté comme une victoire de l’IA dans la recherche de failles. Les documents racontent autre chose. Calif écrit avoir utilisé un assistant pour chercher des moyens de dépasser la limite de mémoire, un agent pour relire le code d’allocation, et une fiche de consignes pour généraliser le motif trouvé. Ses auteurs concluent que connaître la cible reste décisif, et qu’aucun modèle ne déniche « tous les bugs » avec de simples consignes. Wiz affirme avoir trouvé les failles avec ses outils et deux modèles d’IA, qui ont surtout servi à adapter l’exploit aux versions et aux configurations. Chainguard dit avoir retrouvé les mêmes bugs avec un outil maison. OpenAI confirme que Calif a identifié une faille avec son modèle GPT-5.6 Sol, que Wiz a découvert les deux de façon indépendante, et affirme : « À notre connaissance, l’IA de pointe a trouvé ces vulnérabilités avant les attaquants » (billet « Patch the Planet »). Ce jugement est à rapprocher de la tentative relevée par Amazon le 17 octobre, quatre jours avant la publication, dont l’origine reste inexpliquée. OpenAI y annonce aussi un milliard de dollars d’accès subventionné à son outil Daybreak pour les défenseurs, ce qui règle l’écart entre les articles qui parlent d’un milliard et d’un seul qui évoque dix milliards.
Amazon tire de l’épisode une leçon sur la vitesse : l’analyse assistée par IA rend moins coûteux de transformer un correctif ou un avis en exploit, de sorte que davantage d’acteurs peuvent agir en quelques heures, voire minutes, après la divulgation. Pour Amazon, un délai de correction de sept ou trente jours suppose un répit qui n’existe plus.
Côté défense, la PHP Foundation indique avoir créé en mai 2026 une équipe de sécurité de l’écosystème, utilisé des outils d’IA pour le tri et la validation des rapports et embauché des ingénieurs sécurité. Le sujet rejoint notre dossier sur les scanners de failles d’open source et l’alerte lancée par OpenAI, Anthropic et Google sur les cyberattaques assistées par IA. Unit 42 note d’ailleurs que les attaquants qu’elle a observés utilisaient des plateformes d’attaque agentiques, reconnaissables à leur sortie lisible par une machine.
Que faire si vous avez un site
Mettre à jour WordPress, Drupal ou Joomla ne règle rien : la faille est dans PHP, donc dans le serveur. WordPress le dit lui-même, et recommande, si vous gérez votre propre hébergement sur une version trop ancienne, d’envisager de mettre le serveur hors ligne le temps de la mise à jour. Voici la marche à suivre, d’après l’annonce de PHP, le CERT-FR, CERT-EU et Amazon.
- Vérifier la version de PHP du serveur et la comparer aux versions corrigées (8.2.35, 8.3.36, 8.4.27, 8.5.12). Sur un hébergement mutualisé, c’est à l’hébergeur de corriger ; demandez-lui une confirmation écrite. Sur un VPS ou un serveur dédié, c’est à vous. Attention aux dépôts communautaires : CERT-EU avertit que remirepo n’aurait pas de correctifs le jour de la publication ;
- Redémarrer les processus PHP après la mise à jour ;
- Si vous êtes sur PHP 8.1 ou plus ancien : isoler le serveur et migrer, comme le recommande le CERT-FR ;
- Atténuations provisoires, non équivalentes à un correctif : désactiver
session.upload_progress.enabled; fixermemory_limit=-1de façon non modifiable et limiterpost_max_size; éviterRLIMIT_ASetRLIMIT_DATA, qui peuvent eux-mêmes déclencher l’échec d’allocation ; bloquer ou surveiller les requêtes multipart avec un pare-feu applicatif. PHP écrit qu’il n’existe aucune atténuation complète, et Datadog que la désactivation de la progression d’envoi ne protège pas entièrement. Notez aussi quememory_limit=-1supprime le plafond mémoire et augmente le risque d’épuisement du serveur ; - Chercher des traces d’intrusion depuis le 17 octobre, pas depuis le 21 : processus PHP qui lancent un shell, fichiers modifiés, requêtes contenant PHP_SESSION_UPLOAD_PROGRESS. Ne bloquez pas les adresses IP d’indicateurs d’Amazon, qui relèvent d’une infrastructure partagée.
Côté hébergeurs, nous n’avons pas pu vérifier directement les pages de statut. Des blogs français rapportent que PHP 7.4 à 8.5 était corrigé sur les mutualisés d’OVHcloud le 21 octobre à 19 h 53 ; ces informations sont à confirmer auprès de chaque hébergeur.
Ce que l’épisode dit de la sécurité du web
TechCrunch rattache l’affaire à un problème plus large : les failles de mémoire restent la première source de vulnérabilités, d’où le plaidoyer pour des langages dits sûrs. L’article cite une estimation de la NSA selon laquelle environ 75 % des failles activement exploitées sont des failles mémoire ; la page de la CISA consacrée à son guide du 24 juin 2025 sur les langages à sécurité mémoire ne donne pas ce chiffre, et nous n’avons pas pu consulter le PDF. L’épisode rappelle aussi des précédents de grandes pannes ou crises, comme celle de CrowdStrike en 2024. Ce qui frappe ici, c’est moins la faille que son ancienneté : des signaux d’alerte depuis 2004, un audit en 2024, et un parc mondial qui continue de tourner sur des versions non supportées.
Pour BlogNT, une précision de transparence : notre propre serveur exécutait déjà PHP 8.4.27, compilé le 21 octobre, depuis le matin du 22 octobre.
