Failles PHP CVE-2026-109618 et 109619 : que faire, une semaine après

Le 21 octobre 2026, l’équipe PHP a publié des correctifs d’urgence pour deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, qui permettent d’exécuter du code à distance sur un serveur vulnérable. La presse les a surnommées « PHP2Shell ». Une semaine plus tard, le tableau est plus clair qu’au premier jour : voici ce qui est établi, ce qui ne l’est pas, et quoi faire.

Pourquoi cet article arrive plusieurs jours après

Écrire dans l’heure, c’est recopier ce que tout le monde publie, avec le risque de se tromper. Les premières 48 heures d’une faille de ce genre sont celles où l’information bouge le plus. Ici, par exemple :

• On a appris après coup, via Amazon Threat Intelligence, que les premières tentatives d’exploitation dataient du 17 octobre, soit quatre jours avant les correctifs.
• Une troisième faille, CVE-2026-115560, s’est ajoutée le 23 octobre côté PHP, puis le 26 côté CERT-FR.
• Les premiers titres annonçaient des prises de contrôle en masse ; les mesures publiées ensuite montrent surtout du scan, avec peu d’exploitation réussie confirmée.

Et surtout, la priorité des jours qui suivent est de corriger, pas de lire un article de blog. Celui-ci s’adresse à ceux qui veulent une synthèse recoupée avec les sources officielles, une fois l’urgence passée.

Ce qui est établi

• Deux failles dans le moteur PHP lui-même, exploitables sans authentification. Un site WordPress sans aucune extension est donc concerné s’il tourne sur une version vulnérable.
• Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre à 16 h (heure de Paris).
• Versions concernées selon le CERT-FR : toutes les 5.x, 7.x, 8.0.x et 8.1.x (qui ne sont plus supportées), ainsi que les 8.2, 8.3, 8.4 et 8.5 antérieures aux versions ci-dessus.
• Chronologie : première tentative d’exploitation observée le 17 octobre (Amazon), publication avancée le 20 octobre après une fuite de détails, correctifs le 21, preuves de concept connues du CERT-FR le 22.

Ce qui est nuancé

• Cloudflare a compté des millions de tentatives le 22 octobre. Mais les pots de miel montrent surtout du scan et de la prise d’empreinte, et aucune exécution de code réussie sur de vrais systèmes n’était confirmée dans les sources consultées.
• Des éditeurs de sécurité estiment que les attaquants eux-mêmes peinent à produire un exploit fiable. VulnCheck, de son côté, a publié un exploit qui combine les deux failles pour contourner l’ASLR. Autrement dit : la fenêtre est ouverte, pas fermée, et ce n’est pas une raison d’attendre.
• La troisième faille, CVE-2026-115560, demande selon l’éditeur « une combinaison peu probable » d’options de configuration et de code applicatif. Son correctif est prévu au prochain cycle de mises à jour.
• Je ne détaille pas ici les conditions d’exploitation précises : ni le CERT-FR ni les sources que j’ai consultées ne les donnent, et mieux vaut ne pas les deviner.

Que faire

1. Connaître sa version. En ligne de commande : php -v. Sur un hébergement mutualisé, la version se choisit en général dans l’espace client de l’hébergeur ; une page phpinfo() la montre aussi, à supprimer aussitôt après.

2. Mettre à jour vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou plus récent). Sur un serveur Linux, passer par les paquets de la distribution, qui ont été publiés (Ubuntu, par exemple). Mettre à jour WordPress ou ses extensions ne suffit pas : la faille est dans PHP.

3. Sortir des versions 8.1 et antérieures. Il n’y a pas de correctif officiel. Soit le fournisseur de la distribution rétroporte le correctif, soit on migre.

4. En attendant, appliquer les contournements du CERT-FR :

   • CVE-2026-109618 : mettre memory_limit=-1 et une valeur basse pour post_max_size.
   • CVE-2026-109619 : mettre session.upload_progress.enabled=0 et redémarrer chaque processus d’arrière-plan ; sur PHP 8.5, fatal_error_backtraces=0.

   Le CERT-FR le dit sans détour : seule la mise à jour protège complètement.

5. Protéger en amont. Un pare-feu applicatif (WAF) comme celui de Cloudflare a reçu des règles dès le 21 octobre. C’est un filet, pas un correctif.

6. Chercher des traces. Si le site était exposé avant le correctif, vérifier la présence de fichiers PHP récents ou inattendus (web shells), les connexions sortantes inhabituelles et les journaux d’accès autour du 17 au 22 octobre.

Et si on est sur un hébergement mutualisé ?

La mise à jour de PHP est alors la responsabilité de l’hébergeur, pas la vôtre. Deux vérifications utiles : la version affichée dans votre espace client, et l’annonce de l’hébergeur sur ce sujet. Si la version proposée est une 8.1 ou plus ancienne, c’est le moment de passer sur une branche supportée.

À retenir

• Le jour de la divulgation n’est pas le premier jour d’exploitation : Amazon le rappelle explicitement.
• Une faille dans le moteur touche tous les sites qui reposent dessus, pas seulement ceux qui ont des extensions douteuses.
• La mise à jour des versions supportées prend quelques minutes ; la sortie d’une branche en fin de vie demande un vrai projet. Mieux vaut le planifier avant la prochaine alerte.

Sources

• CERT-FR : alerte CERTFR-2026-ALE-014, multiples vulnérabilités dans PHP
• BleepingComputer : Amazon, l’exploitation de PHP2Shell a commencé 4 jours avant les correctifs
• Krebs on Security : faille PHP répandue, risque de pannes de sites
• Security Affairs : PHP2Shell, des millions d’attaques, aucune exploitation réussie confirmée