Les failles PHP concernent une couche technique souvent invisible pour le dirigeant d’une entreprise. Ce langage exécute, sur les serveurs, le code de nombreux sites et applications web. Son équipe de sécurité a publié quatre versions corrigées le 21 octobre : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elle recommande une mise à jour immédiate des installations concernées.
Les deux vulnérabilités portent les références CVE-2026-109618 et CVE-2026-109619. Leur gravité atteint 9,2 sur 10 selon le barème CVSS v4.0. Ce score évalue une vulnérabilité ; il ne mesure ni le nombre de victimes ni la probabilité qu’une entreprise donnée ait déjà subi une intrusion.
Ce que permettent les deux failles PHP
Les défauts touchent la gestion de la mémoire et des erreurs dans PHP. Dans certaines conditions, un attaquant peut obtenir l’exécution de son propre code sur un serveur, sans disposer au préalable d’un compte sur le site. Cela ouvre notamment un risque d’accès aux données ou d’altération du service, selon les droits et l’environnement du processus compromis.
L’équipe PHP considère particulièrement exposée la configuration Apache avec le module mod_php. Elle indique qu’une exploitation y a été démontrée avant même l’exécution du code de l’application. Les autres modes d’hébergement, notamment PHP-FPM, restent concernés : changer simplement de configuration ne garantit donc pas la protection.
À lire aussi
Un site peut par ailleurs continuer à fonctionner normalement tout en utilisant une version vulnérable. L’absence de panne ne prouve pas qu’il est corrigé. À l’inverse, une page de maintenance peut correspondre à une décision préventive, prise pour limiter l’exposition durant l’intervention.
Pourquoi interrompre un service avant de le corriger ?
Dans son avis de sécurité actualisé le 21 octobre, le CERT-EU recommande de corriger immédiatement les ressources affectées. Lorsque cela n’est pas possible, il conseille d’envisager leur isolement des réseaux publics jusqu’à l’application et à la vérification du correctif.
Cette recommandation explique pourquoi un exploitant peut préférer une interruption temporaire à une exposition prolongée. Pour une boutique en ligne, la décision peut suspendre des ventes. Pour un portail client, elle peut retarder des échanges de documents. Le coût dépend du service réellement arrêté et de l’existence d’un autre moyen de traiter les demandes.
Une fermeture préventive ne démontre toutefois pas une cyberattaque réussie. De même, la circulation de démonstrations d’exploitation ne permet pas de dresser un bilan mondial des compromissions. Le CERT-EU souligne un risque accru d’exploitation avec la publication des détails techniques ; son avis ne constitue pas un décompte de sites piratés.
Cette distinction entre indisponibilité, exposition et intrusion compte pour informer les clients. Elle évite d’annoncer une fuite de données sans preuve ou, à l’inverse, de considérer qu’un service rétabli est nécessairement exempt de toute trace d’attaque.
Les versions corrigées à faire confirmer par l’hébergeur
Les mises à jour portent sur le moteur PHP. Mettre à jour WordPress, un thème ou une extension ne démontre donc pas que cette couche du serveur a également reçu son correctif. L’entreprise doit identifier qui administre l’environnement : son équipe informatique, son hébergeur ou son prestataire de maintenance.
| Branche utilisée | Version corrective publiée le 21 octobre |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Source : équipe PHP. Certains fournisseurs intègrent les correctifs dans leurs propres paquets : leur bulletin doit alors confirmer la protection effective.
Les versions 8.1 et antérieures ne bénéficient plus du support normal du projet PHP. Des fournisseurs proposent toutefois des correctifs adaptés aux anciennes branches. Vu la gravité des failles, l’équipe PHP a aussi fourni des adaptations minimales du correctif pour PHP 7.4, 8.0 et 8.1. Cela ne rétablit pas leur maintenance générale.
Pour le responsable du site, une confirmation utile précise l’environnement corrigé, le paquet effectivement installé et la vérification du service après intervention. Un message annonçant seulement une « mise à jour du site » reste trop vague pour savoir quelle couche a été traitée.
Le chiffre de 70 % ne désigne pas des sites piratés
La diffusion de PHP explique l’ampleur de l’alerte. Au 22 octobre, W3Techs estime que le langage équipe 69,3 % des sites dont il connaît le langage utilisé côté serveur. Ce périmètre de mesure est important : il ne s’agit ni de tous les sites sans distinction ni d’un inventaire des installations encore vulnérables.
Le risque réel dépend de la version, des correctifs appliqués et des conditions d’exploitation. Les failles PHP ne permettent donc pas d’affirmer que près de 70 % du web a été compromis.
L’inventaire constitue pourtant une difficulté concrète. Une entreprise peut suivre son site principal et oublier un ancien espace client, un sous-domaine ou un environnement de test. Notre entretien consacré aux vulnérabilités des applications web explique pourquoi ces ressources doivent aussi entrer dans le suivi de sécurité.
L’IA a aidé les chercheurs, les développeurs ont corrigé
Le rôle de l’intelligence artificielle mérite également d’être précisé. OpenAI indique que Calif a identifié une faille critique avec l’aide de son modèle GPT-5.6 Sol, dans le programme Patch the Planet. Wiz a aussi découvert et signalé indépendamment les vulnérabilités. Ces travaux relèvent de la recherche défensive.
La chronologie publiée par la PHP Foundation apporte un autre élément : les premiers signes du problème de mémoire étaient connus depuis 2024. La fondation reconnaît que les difficultés techniques, son processus de décision et le manque de ressources ont retardé la correction. Les signalements de 2026 ont permis d’en établir pleinement la gravité.
Selon cette même chronologie, la circulation prématurée d’informations le 20 octobre a conduit à avancer la publication prévue du 22 au 21 octobre. La fondation souligne que des humains prennent les décisions et travaillent sur chaque correctif. L’intervention de l’IA ne signifie donc ni qu’elle a créé ces défauts ni qu’elle a assuré seule leur résolution.
La reprise doit aussi se vérifier côté métier
L’équipe PHP prévient que les réglages provisoires proposés réduisent certains risques sans fournir une protection complète. Le correctif reste nécessaire. S’il existe des indices d’intrusion, sa seule installation ne suffit pas non plus à établir ce qui s’est produit auparavant.
Enfin, une remise en ligne mérite un contrôle des usages essentiels : une commande peut-elle aboutir, un formulaire transmettre sa demande, un client retrouver ses documents ? Notre article sur les flux suspendus après l’incident VosFactures montre l’importance de ce suivi opérationnel. Pour sortir de l’alerte, l’entreprise doit pouvoir confirmer à la fois la correction technique et le fonctionnement du service dont ses clients dépendent.
À lire également sur Business Times
