Mercredi 21 octobre 2026, en début d'après-midi, l'équipe de sécurité de PHP publie des versions correctives en urgence. La veille, le sujet avait déjà fuité sur les réseaux : un message annonçait deux failles critiques, avec une vidéo d'attaque à l'appui, avant d'être retiré. La publication prévue le 22 a été avancée d'un jour. Pour une agence qui héberge et maintient des sites et des logiciels écrits en PHP, ce genre de matinée ne se planifie pas.
En bref
Deux failles critiques du cœur de PHP (CVE-2026-109618 et CVE-2026-109619, score 9,2 sur 10) permettent de prendre le contrôle d'un serveur sans identifiant. Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Des attaques réelles sont désormais documentées : seule la mise à jour protège complètement.
Ce qui s'est passé
Les deux failles se trouvent dans le cœur de PHP, pas dans WordPress, ni dans un plugin, ni dans un framework précis. Elles concernent la façon dont PHP gère la mémoire entre deux visites sur un site. D'après la FAQ publiée par Tenable, la première (CVE-2026-109618) survient quand le serveur manque de mémoire en pleine préparation d'une requête : des données restent à moitié initialisées, puis sont traitées comme valides au nettoyage. La seconde (CVE-2026-109619) laisse des données d'une visite en mémoire, qu'une visite suivante peut réutiliser.
Dans les deux cas, le résultat est le même : un attaquant à distance, sans compte ni mot de passe, peut faire exécuter son propre code sur le serveur, avec les droits du serveur web. Le projet PHP leur attribue un score CVSS v4.0 de 9,2. Les identifiants qui avaient circulé avant la publication indiquaient 10, ce que la PHP Foundation juge incorrect, toujours selon Tenable.
Un point mérite d'être dit clairement : une faille dans PHP n'est pas une faille dans votre site. Votre site n'a rien fait de travers. Mais comme PHP fait tourner la grande majorité des sites que nous construisons et maintenons, un correctif de PHP est un sujet pour tout le monde.
Qui est concerné
Toute installation PHP qui sert des pages web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Le risque est le plus élevé avec mod_php, où une requête non authentifiée peut déclencher la faille avant même l'exécution du code de votre site, selon Help Net Security.
| Votre version de PHP | Situation | Ce qu'il faut faire |
|---|---|---|
| 8.5, 8.4, 8.3, 8.2 | Versions corrigées : 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Mettre à jour, puis redémarrer PHP |
| 7.4, 8.0, 8.1 | Plus de support officiel, mais des correctifs minimaux ont été publiés pour les compilations depuis les sources | Demander un correctif à l'hébergeur ou passer à une version supportée |
| 7.3 et plus ancien | Fin de vie, aucun correctif de PHP | Migrer vers une version supportée |
Les distributions Linux et les éditeurs de support étendu ont reçu les correctifs en avance, d'après Tenable : le plus simple est donc de regarder les paquets de votre hébergeur ou de votre distribution, pas de chercher le numéro de version exact à la main. Sous Windows, Tenable signale des versions corrigées publiées le 26 octobre.
Mutualisé, VPS, serveur dédié : qui doit agir
C'est la question que nos clients posent en premier, et la réponse dépend de l'hébergement. OVHcloud a détaillé sa position : sur les hébergements mutualisés, le composant PHP est mis à jour automatiquement par l'hébergeur, le client n'a rien à faire. Sur un VPS ou un serveur dédié, c'est au client d'agir, car l'hébergeur ne modifie pas les instances sans accord.
Concrètement, sur un serveur que vous administrez, la séquence est la suivante : vérifier la version utilisée par le site (la version en ligne de commande peut différer de celle du serveur web), faire une sauvegarde, installer la mise à jour, puis redémarrer les services PHP. Cette dernière étape est la plus souvent oubliée : sans redémarrage, l'ancienne version reste en mémoire et la faille reste ouverte.
Où en est l'exploitation, une semaine après
Au moment de la publication, les sources divergeaient. Huntress indiquait le 21 octobre ne rien observer chez ses partenaires, et l'équipe PHP n'avait pas identifié d'exploit fonctionnel. Depuis, le tableau a changé.
D'après le suivi tenu à jour par Tenable, Amazon Threat Intelligence a enregistré une première tentative dès le 17 octobre, quatre jours avant la publication, puis d'autres le 21, et qualifie désormais l'activité de tentatives d'exploitation à grande échelle. Le 24 octobre, un chercheur a rapporté des exploitations réussies sur trois honeypots tournant sous PHP 8.4.26, et le 26 octobre, Trail of Bits a confirmé que des exploits fonctionnent contre les versions 8.2 à 8.5 non corrigées. Toujours le 26 octobre, la CISA américaine a ajouté les deux failles à son catalogue des vulnérabilités activement exploitées. Tenable cite par ailleurs des estimations d'exposition de l'ordre de 1,3 à 1,9 million de serveurs accessibles depuis Internet (le second chiffre compte les serveurs qui font tourner PHP, pas forcément vulnérables).
Un point de prudence : Tenable rapporte aussi une campagne enchaînant ces failles avec une autre faille Linux pour obtenir un accès administrateur sur des pare-feux, mais l'information n'a pas été confirmée de façon indépendante. Je la signale sans la tenir pour acquise. Du code d'exploit non vérifié circule en outre publiquement, et il peut lui-même contenir des logiciels malveillants.
Mon avis : le débat sur la date exacte du premier exploit n'a plus d'importance. Le correctif est public, les détails ont fuité, des attaques réussies sont documentées et une agence gouvernementale a classé la faille comme exploitée. Le délai raisonnable pour agir se compte en heures.
Si vous ne pouvez pas mettre à jour tout de suite
Il existe des réglages d'attente, mais ils réduisent le risque sans le supprimer. D'après OVHcloud et Tenable : désactiver le suivi de progression des envois de fichiers (session.upload_progress.enabled à 0) et, sur PHP 8.5, désactiver fatal_error_backtraces. OVHcloud déconseille en revanche de supprimer la limite de mémoire, puisqu'une seule requête pourrait alors consommer tout le serveur. Si votre site n'utilise aucun formulaire d'envoi de fichiers, bloquer ce type de requête au niveau du serveur est une autre option.
Ces mesures ne remplacent pas la mise à jour. Le projet PHP est clair là-dessus, comme le rappelle OVHcloud : seule la mise à jour protège complètement. Autre précision utile, rapportée par Tenable : une régression connue touche PHP 8.4.27 et 8.5.12 avec certaines applications utilisant SimpleXML. Elle ne justifie pas de rester sur une version vulnérable, mais elle explique qu'il faut tester le site après la mise à jour.
Ce que nous avons fait chez Pictogramaweb
Dès la publication des correctifs, nous avons appliqué la mise à jour sur les sites et les applications que nous gérons, dans l'heure. Je le précise sans en faire un exploit : c'est le minimum attendu d'une agence qui édite et héberge des logiciels. Nous éditons nos propres produits, dont Simply Spa, Postwa et Geko, et nous savons ce que représente une journée d'indisponibilité pour la personne qui s'en sert.
Cet épisode confirme aussi un point que je répète en rendez-vous : le premier chantier d'une alerte comme celle-ci n'est pas le correctif, c'est l'inventaire. Un expert de Sophos, cité par Solutions Numériques, le dit en substance : le défi ne consiste pas à installer un correctif, mais à retrouver où PHP tourne. Le vieux site oublié d'une ancienne activité, l'espace de test jamais supprimé, le petit outil installé par un ancien prestataire : ce sont eux qui restent ouverts. C'est la raison pour laquelle nous tenons une liste des installations que nous suivons, et pourquoi la maintenance d'un site ou d'une application métier ne se résume pas à "ça tourne".
Les vérifications à faire cette semaine
Si vous gérez vous-même votre site ou votre serveur, voici dans l'ordre ce que je ferais :
- identifier la version de PHP utilisée par chaque site et chaque outil, y compris ceux dont vous ne vous servez plus ;
- mettre à jour ou demander la mise à jour à votre hébergeur, puis vérifier que les services ont été redémarrés ;
- surveiller les signes d'une compromission déjà survenue : fichiers inconnus dans la racine du site, nouvelles tâches planifiées, comptes créés sans votre accord, shells ou outils de téléchargement lancés par PHP, comme le recommande Huntress ;
- en cas de doute, isoler le serveur et conserver les journaux avant toute chose.
Pour un logiciel hébergé sur un serveur dédié, notre article sur l'hébergement d'un logiciel métier détaille qui est responsable de quoi. Et si vous voulez comprendre comment nous traitons ces sujets sur les logiciels que nous développons, la page développement de SaaS sur mesure présente notre approche.
Mon verdict
Cette alerte n'est pas une raison de paniquer, mais c'est une raison de ne pas remettre à demain. Une faille du cœur de PHP, exploitable sans identifiant, avec des détails publics et des attaques documentées, se traite le jour même. Si votre site est sur un hébergement mutualisé, vérifiez simplement auprès de votre hébergeur que la mise à jour a eu lieu. S'il est sur un VPS ou un serveur dédié, c'est à vous (ou à votre prestataire) d'agir. Et si personne ne sait dire sur quoi tourne votre site, voilà le vrai sujet à régler.
Questions fréquentes
Mon site WordPress est-il concerné par la faille PHP ?
Oui, indirectement. La faille se trouve dans PHP, qui fait tourner WordPress. Il ne s'agit pas d'une faille de WordPress ni d'un plugin : la mise à jour se fait au niveau du serveur, pas dans l'administration de votre site.
Dois-je faire quelque chose si je suis sur un hébergement mutualisé ?
Normalement non, car l'hébergeur met PHP à jour lui-même. OVHcloud le confirme pour ses hébergements mutualisés. Le plus prudent est de demander à votre hébergeur la confirmation écrite que le correctif est appliqué.
Comment savoir si mon site a déjà été attaqué ?
Cherchez des fichiers inconnus, des tâches planifiées ou des comptes que vous n'avez pas créés, et des processus anormaux lancés par PHP. En cas de doute, isolez le serveur, conservez les journaux et faites-vous accompagner.
Quelle version de PHP faut-il installer ?
La version corrigée de votre branche : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Pour les versions plus anciennes, il faut migrer vers une version supportée ou obtenir un correctif auprès de votre fournisseur.
Pour conclure
Une faille PHP critique rappelle que la sécurité d'un site se joue aussi à des endroits que l'on ne voit pas. Si vous ne savez pas quelle version de PHP fait tourner votre site, ou si vous voulez qu'on regarde l'ensemble de vos installations, écrivez-nous via la page contact.
Photo : Adi Goldstein sur Unsplash
