Le 21 octobre 2026, l’équipe PHP a corrigé deux failles critiques (CVE-2026-109618 et CVE-2026-109619). Elles pouvaient permettre à un attaquant d’exécuter du code sur un serveur, sans compte ni mot de passe. Des tentatives d’exploitation ont été signalées dans le monde dès le matin, avant même la publication du correctif.
Ces failles se trouvaient dans PHP lui-même, le langage qui fait fonctionner WordPress. Une mise à jour de WordPress, d’un thème ou d’une extension ne pouvait donc pas les corriger : seule une mise à jour de PHP le pouvait. Chez Faaaster, c’est nous qui gérons PHP.
Vous n’avez rien à faire.
Le 21 octobre, heure par heure (heure de Paris)
Dès le matin : surveillance et préparation. Nous avons suivi les annonces de l’équipe PHP, les alertes des chercheurs en sécurité et notre fournisseur de paquets PHP. Nous avons préparé la mise à jour de toutes les versions de PHP utilisées sur nos serveurs, y compris les plus anciennes.
Vers 14 h 30 : première protection. Avant même que le correctif soit disponible, nous avons appliqué sur tous les sites en fonctionnement des réglages qui ferment l’un des chemins d’attaque identifiés. Nous avons ensuite vérifié chaque site pour nous assurer que tout continuait de fonctionner normalement.
Vers 15 h : protection renforcée. Nous avons ajouté un second réglage, puis contrôlé à nouveau l’ensemble des sites. Nous avons aussi ajouté à notre pare-feu applicatif une règle dédiée à ces failles, pour filtrer les requêtes d’attaque connues avant qu’elles n’atteignent PHP.
16 h : publication du correctif officiel. Nous avons aussitôt construit et testé des versions de PHP corrigées. Nous avons aussi ajouté à notre chaîne de construction un contrôle automatique : il est désormais impossible de produire une image de serveur avec une version de PHP antérieure à ce correctif.
Vers 17 h : blocage des principaux attaquants. Nous avons bloqué au niveau de notre infrastructure, pour tous les sites à la fois, les adresses IP à l’origine des principales vagues d’attaques.
Vers 18 h : protections verrouillées. Nous avons renforcé les protections temporaires. Aucune extension ni aucun réglage de site ne peut plus les désactiver.
Entre 18 h et minuit : mise à jour de PHP. Les sites ont été mis à jour vers les versions corrigées, progressivement et sans arrêt général de la plateforme. Chaque site a gardé sa version de PHP.
Analyse des attaques et vérification des sites
Tout au long de l’incident, nous avons analysé les journaux consolidés de l’ensemble de notre plateforme pour repérer les requêtes suspectes. C’est cette analyse qui nous a permis d’identifier et de bloquer les principaux attaquants.
Nous avons ensuite isolé les sites sur lesquels des requêtes suspectes avaient atteint PHP, et nous avons vérifié chacun de ces sites.
Aucune compromission n’a été détectée.
Pourquoi plusieurs protections à la fois ?
Une règle de pare-feu bloque les attaques qu’elle sait reconnaître, mais un attaquant peut changer de méthode. Les réglages temporaires ferment les chemins d’attaque connus, mais l’équipe PHP rappelle qu’ils ne remplacent pas le correctif. La mise à jour de PHP reste la seule protection définitive. Nous avons donc combiné les trois : réglages immédiats, filtrage des attaques et mise à jour de PHP.
Quel impact pour votre site ?
Votre contenu, vos extensions, vos thèmes et votre base de données n’ont pas été modifiés.
Nous n’avons pas bloqué les formulaires ni les envois de fichiers : vos visiteurs auraient perdu la possibilité de vous contacter ou de commander. Nous avons préféré des protections ciblées, puis la mise à jour de PHP.
Faut-il faire quelque chose ?
Non. Pour ces failles, inutile de mettre à jour WordPress, de changer votre configuration ou vos mots de passe.
Si vous remarquez un comportement inhabituel sur votre site depuis le 21 octobre (formulaire, connexion, panier, envoi de fichier), contactez notre support : nous regarderons avec vous.
Les sources suivies
Nos décisions se sont appuyées sur plusieurs sources complémentaires :
- avis officiel de l’équipe PHP ;
- advisory CVE-2026-109618 ;
- advisory CVE-2026-109619 ;
- branches officielles de rétroportage PHP 7.4, 8.0 et 8.1 ;
- changelogs des paquets fournis par packages.sury.org ;
- règle de virtual patching publiée dans le Hub CrowdSec ;
- informations de terrain publiées par Cloudflare et Sansec ;
- journaux de construction, métriques PHP-FPM, contrôles HTTP sans cache et réconciliations de notre propre parc.
