Les 20 et 21 octobre 2026, deux failles critiques dans PHP ont poussé de nombreux sites, dont des services publics, à se mettre hors ligne par précaution. Elles permettent à un attaquant d’exécuter du code à distance, sans authentification. Ozérim revient sur ces évènements, dont les effets se faisaient encore sentir le 22 octobre.
2026 est décidément une rude année pour l’informatique mondiale !
Entre des hausses de prix qui n’en finissent plus, une pénurie de mémoire vive, des attaques cyber qui s’enchaînent et maintenant PHP victime de deux vulnérabilités critiques, la liste n’en finit plus de s’allonger…
PHP est un langage informatique utilisé par environ 70 % des sites web dont le langage serveur est connu. Il alimente des CMS comme WordPress, Drupal et Magento, ainsi que les plateformes d’hébergement mutualisées.
Le mardi 20 octobre au soir, l’équipe de sécurité de PHP annonçait la sortie d’un correctif pour deux failles critiques, prévue le 21 octobre à 16 h (heure de Paris). Les identifiants des deux failles circulaient déjà en ligne depuis l’après-midi, après une fuite.
Ces failles, référencées CVE-2026-109618 et CVE-2026-109619, sont notées 9,2/10 dans le référentiel CVSS 4.0. Elles permettent à un attaquant d’effectuer une exécution de code arbitraire à distance, sans authentification.
La première vient d’une corruption de la mémoire quand une requête épuise la mémoire allouée à PHP.
La seconde vient d’un état interne qui survit à une requête et pointe vers de la mémoire déjà libérée.
Les deux failles, connues sous le sobriquet PHP2Shell, se situent dans le moteur PHP. Mettre à jour un plugin ou le code d’un site ne les corrige pas.
Les correctifs ont été publiés le 21 octobre 2026, avec une légère avance sur l’horaire annoncé. Ils concernent PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet. PHP 8.2 atteint de son côté sa fin de vie le 31 décembre 2026.
Pour les anciennes branches, certaines distributions et certains éditeurs LTS fournissent des correctifs rétroportés. L’équipe de sécurité de PHP a aussi publié des rétroportages minimaux du code source pour PHP 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP eux-mêmes.
Des réglages temporaires réduisent l’exposition à certaines attaques, sans protéger complètement. Seule la mise à jour corrige les failles.
Pour éviter des intrusions, de nombreux administrateurs ont mis leur site hors ligne le temps d’appliquer la mise à jour. Parmi eux figurent impots.gouv.fr, Météo-France, la CNIL et les sites des préfectures, ces derniers à la demande de l’ANSSI.
L’ANSSI recense plus de 600 000 serveurs PHP sur l’internet français. Au matin du 22 octobre, la CNIL, impots.gouv.fr et la préfecture de Seine-Saint-Denis affichaient encore une page de maintenance.
Le mode maintenance d’un CMS n’apporte aucune protection, car PHP analyse la requête avant l’application, selon l’alerte de l’ANSSI. La coupure doit se faire au niveau du serveur web ou du pare-feu applicatif (WAF).
Pour les serveurs impossibles à mettre à jour, IT for Business, qui relaie l’alerte, conseille de bloquer les requêtes multipart/form-data à ce niveau.
Les attaques n’ont pas attendu les correctifs. Cloudflare a observé les premières attaques le 21 octobre à 9 h 43 (heure de Paris), six heures avant la publication, et dit avoir enregistré depuis des millions de tentatives.
Amazon a détecté une tentative d’exploitation dès le 17 octobre sur l’un de ses pièges à pirates. Ces chiffres comptent des tentatives d’exploitation. Ils ne disent rien du nombre d’intrusions réussies.
Sansec estime même, le 22 octobre, qu’une exploitation de masse est moins probable que prévu, car une attaque exige une connaissance précise du serveur visé.
De son côté, Ozérim a déjà agi pour protéger son infrastructure d’hébergement.
Les premiers signes de la faille CVE-2026-109618 remontent à 2024.
Un développeur du cœur de PHP les a repérés en corrigeant un bug issu du premier audit de sécurité externe du langage depuis des années, réalisé par Quarkslab. À l’époque, aucune voie d’exploitation concrète n’était connue.
Plusieurs solutions de correction existaient, chacune avec ses inconvénients : rupture de compatibilité, risque de déni de service ou modifications à coordonner dans de nombreuses extensions tierces. L’équipe de sécurité de PHP décide par consensus et dispose de peu de ressources. Le chantier a calé et repris pendant des mois. La PHP Foundation parle elle-même d’un échec structurel.
Le 11 août 2026, un chercheur de la société Calif signale une exécution de code à distance de même cause racine. OpenAI fait le même signalement le jour même, de façon indépendante. Wiz suit le 24 août, puis OpenAI ajoute d’autres vecteurs d’attaque le 18 septembre.
Plusieurs de ces chercheurs ont utilisé des modèles d’IA pour trouver les failles et démontrer leur exploitation, selon Wiz et IT for Business. À partir du 11 août, la correction devient la priorité de toute l’équipe sécurité de la Fondation. Le correctif sort le 21 octobre 2026, plus de dix semaines plus tard.
La Fondation indique avoir renforcé ses méthodes. Elle a créé une équipe dédiée à la sécurité de l’écosystème en mai 2026 et fait analyser le code par des outils d’IA, dont Claude Mythos et Daybreak Red d’OpenAI. Ces outils aident à valider et à regrouper les rapports. Des personnes prennent chaque décision et écrivent chaque correctif. L’équipe de sécurité change ses processus pour décider à la majorité.
Ozérim est intervenu dès l’annonce de l’équipe de sécurité de PHP.
Nous avons appliqué une mesure temporaire consistant à désactiver la directive « session.upload_progress.enabled », afin de limiter la surface d’attaque.
Nous avons fait le choix de ne pas activer la directive « memory_limit=-1 » car elle ne concernait qu’une seule vulnérabilité et aurait fait peser un risque de saturation sur notre infrastructure d’hébergement mutualisée.
Enfin, nos équipes ont immédiatement déployé le correctif officiel dès sa parution, sans interruption de service pour nos clients.
L’ensemble de nos serveurs est ainsi protégé contre ces deux failles, sur toutes les versions de PHP que nous hébergeons, et pas uniquement sur la 8.4.x ou la 8.5.x.
Les sites de nos clients sont donc protégés contre ces deux failles, sans autre action nécessaire de leur part.
Pour nos clients dont les sites internet ne sont pas à jour sur les dernières versions PHP, nous recommandons une migration vers une version maintenue. Pour rappel, PHP 8.2 atteint sa fin de vie le 31 décembre 2026.
Nous pouvons vous accompagner dans ce process, contactez-nous pour protéger vos actifs immatériels !
EXPERT IT DU CLOUD MAÎTRISÉ
Nous prônons la haute technicité, l’indépendance et la souveraineté des données, au service de votre sécurité.
Quelle alternative à Microsoft 365 pour votre PME ? Prix, fonctionnalités, souveraineté : Ozérim compare Nextcloud[...]
Fonctionnalités, limites, installation et FAQ : les équipes Ozérim font le point complet sur PegaProx, le dashboard[...]
Le cloud souverain, on en parle tous. Mais c'est quoi concrètement ? Où en est votre entreprise face aux services[...]
Le monde informatique est-il en roue libre ? C’est la question que se pose Ozérim face aux rachats et aux[...]
Malgré une levée de boucliers de la part de nombreux acteurs, la CNIL a fait son choix pour l’hébergement de[...]
