Failles critiques dans PHP (CVE-2026-109618 et CVE-2026-109619) : ce qui s’est passé et ce que vous devez faire

Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux failles critiques, et le CERT-EU a diffusé le même jour l’avis 2026-018. Les deux failles sont notées 9,2 et décrites comme une exécution de code à distance sans authentification. Si vous exploitez un site WordPress, une boutique en ligne ou toute autre application PHP, vous êtes concerné, et le remède est une mise à jour, pas un réglage. Cet article explique ce que l’on sait, comment l’attaque s’introduit et ce que vous devez faire. Situation au 22 octobre 2026, d’après la version 1.1 de l’avis du CERT-EU.

Ce qui s’est passé

PHP a annoncé une version de sécurité le 20 octobre et a publié les correctifs le 21 octobre à 13 h 30 UTC. Le CERT-EU a intitulé son avis « Critical Vulnerabilities in PHP » et recense deux CVE : CVE-2026-109618 et CVE-2026-109619, chacune notée 9,2. Le CERT-EU écrit aussi que les détails techniques sont désormais discutés publiquement et que les premiers codes de démonstration (preuve de concept) circulent. L’avis ne confirme pas d’attaques dans la nature, mais il précise qu’il devient ainsi plus probable que des attaquants exploitent déjà les failles. Considérez la situation comme urgente.

Qui est concerné

Sont concernées toutes les versions de PHP antérieures à la version corrigée dans une branche prise en charge, ainsi que toutes les branches arrivées en fin de vie.

Le CERT-EU cite PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Selon l’équipe PHP, mod_php présente le risque le plus élevé. Les produits qui intègrent PHP peuvent eux aussi être touchés ; le CERT-EU renvoie à ce sujet à une liste du NCSC néerlandais, indiquée à la fin de cet article. Toute installation qui traite des requêtes web est concernée, qu’elle dispose ou non d’un formulaire de téléversement.

Comment un attaquant atteint la première faille

Personne n’a besoin de se connecter. D’après le CERT-EU, une attaque démontrée prouve qu’une seule requête sans authentification suffit à déclencher l’attaque avant l’exécution du moindre code applicatif. C’est ce que la plupart des gens ne voient pas : peu importe que votre WordPress soit à jour, que vos extensions soient corrigées ou que votre formulaire de contact soit protégé. La requête atteint d’abord le moteur PHP.

La première faille, CVE-2026-109618, fonctionne ainsi :

1. Une requête arrive à une adresse que PHP dessert. Pas de connexion, pas de compte.
2. PHP commence à lire le corps de la requête. Le CERT-EU cite à titre d’exemple le traitement des téléversements de fichiers par formulaire.
3. PHP applique son memory_limit avec longjmp(). Lorsque la limite est dépassée, il sort brutalement de ce qu’il était en train de faire et met fin à la requête.
4. Si cela se produit en pleine construction des données internes de la requête, ces données ne sont construites qu’à moitié.
5. Le nettoyage qui suit traite ces données invalides comme valides et libère de la mémoire qui n’a jamais été initialisée. Cette mémoire peut encore contenir des données d’allocations antérieures que l’attaquant contrôlait.
6. À partir de là, l’avis décrit une exécution de code sur le serveur.

Nous ne décrivons volontairement pas comment un attaquant dirige la dernière étape. Il suffit de savoir que le point d’entrée n’est pas votre application, et c’est pourquoi rien à l’intérieur de votre application ne peut l’arrêter.

La seconde faille : un état qui survit à sa mémoire

CVE-2026-109619 est un mécanisme différent, au même résultat. PHP conserve un état interne pour chaque requête. Après certaines défaillances, par exemple une erreur fatale, cet état peut subsister alors que la mémoire qui le sous-tend a été libérée. La requête suivante traitée par le même processus de travail peut alors utiliser cet état périmé avant qu’il ne soit réinitialisé de la manière habituelle. L’attaquant a besoin de deux requêtes qui aboutissent sur le même processus de travail ; le CERT-EU évalue le résultat comme pour la première faille : exécution de code à distance.

Ce qu’il faut faire aujourd’hui

1. Déterminez quelle version de PHP dessert réellement votre site. php -v en ligne de commande affiche la version de la ligne de commande, qui peut différer de celle de votre serveur web. Vérifiez php-fpm -v, votre panneau d’hébergement ou une page qui appelle phpinfo(). Sur un hébergement mutualisé, interrogez votre hébergeur.
2. Mettez à jour vers une version corrigée : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Les distributions reportent souvent les correctifs sans changer le numéro de version ; cherchez donc les numéros CVE dans l’avis de sécurité de votre fournisseur. Dans les conteneurs, reconstruisez à partir d’une image de base mise à jour. L’équipe PHP signale que rpms.remirepo.net n’avait pas encore de mises à jour le jour de la publication et recommande les paquets de la distribution ou une compilation à partir des sources.
3. Redémarrez tous les processus de travail PHP. Une mise à jour sur le disque ne modifie pas les processus déjà en cours d’exécution. Redémarrez PHP-FPM ou le serveur web, puis vérifiez à nouveau la version en cours d’exécution.
4. Si vous ne pouvez pas mettre à jour aujourd’hui, isolez le serveur des réseaux publics jusqu’à ce que le correctif soit installé et vérifié. Le CERT-EU est clair : seule une mise à jour corrige entièrement ces failles.
5. Si vous utilisez PHP 8.1 ou une version antérieure, demandez le rétroportage à votre fournisseur ou passez à une branche prise en charge. Ces versions ne reçoivent plus de mises à jour régulières.

Contournements qui réduisent le risque sans le corriger

Le CERT-EU énumère des mesures qui compliquent une attaque. L’avis indique expressément qu’elles ne rendent pas une installation sûre. Utilisez-les pendant que vous préparez la mise à jour, pas à sa place.

• Contre CVE-2026-109618 : définissez memory_limit=-1 de façon que les applications ne puissent pas le remplacer, par exemple avec php_admin_value dans le pool FPM, et vérifiez qu’aucune entrée de pool, de répertoire ou d’application ne fixe de nouveau une limite finie. Définissez un post_max_size bas (8M sans téléversements, 32M avec) et maintenez upload_max_filesize en dessous. Limitez la taille des requêtes, le nombre de champs, de parties multipart, d’en-têtes et la profondeur d’imbrication au niveau du serveur web ou du proxy. Utilisez une limite de mémoire du conteneur ou du cgroup comme borne de disponibilité, mais pas RLIMIT_AS ni RLIMIT_DATA, qui peuvent provoquer l’échec d’allocation vulnérable.
• Contre CVE-2026-109619 : définissez session.upload_progress.enabled=0 dans php.ini, dans le pool FPM ou dans une configuration de serveur qui s’applique avant l’analyse de la requête (pas avec ini_set() ni .user.ini), et redémarrez tous les processus de travail. Avec PHP 8.5, définissez en plus fatal_error_backtraces=0. Supprimez les réglages par requête invalides ou obsolètes qui affichent des diagnostics avant l’initialisation, et corrigez les erreurs fatales et les dépassements de délai d’exécution qu’un attaquant peut atteindre.

Ce que SilentShield peut faire ici, et ce qu’il ne peut pas

Ce n’est pas un problème de bots, et nous préférons le dire plutôt que de laisser une page produit suggérer le contraire. L’attaque frappe le moteur PHP avant que quoi que ce soit de notre part, un CAPTCHA, une extension ou une règle de pare-feu à l’intérieur de votre application ne voie la requête. Une protection contre les bots sur un formulaire ne l’arrête pas, et personne ne devrait vous dire le contraire. Le seul remède complet est la mise à jour de PHP.

L’API et le tableau de bord de SilentShield ne sont pas écrits en PHP. L’extension WordPress et le SDK PHP s’exécutent dans votre propre PHP ; pour eux, la mise à jour doit donc avoir lieu sur votre serveur. Une fois la mise à jour faite, la protection habituelle contre les bots et le spam de formulaires est aussi utile qu’avant ; elle n’a simplement jamais été la réponse à ce problème.

Sources

• CERT-EU Security Advisory 2026-018 : Critical Vulnerabilities in PHP
• Annonce de PHP du 20 octobre 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell : produits qui intègrent PHP