Faille critique « php2shell » : nos mises à jour de PHP en cours de déploiement

Le projet PHP a publié ce mercredi 21 octobre 2026, à 16 h (heure de Paris), des versions de sécurité qui corrigent deux failles critiques d'exécution de code à distance : CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2 sur 10 (CVSS v4.0). Les chercheurs de watchTowr ont surnommé ce duo « php2shell ».

Nos équipes déploient en ce moment les versions corrigées sur les serveurs que nous administrons. Cet article explique ce que sont ces failles, pourquoi elles sont prises très au sérieux et ce que nous faisons de notre côté.

Deux failles au cœur de PHP

Les failles ne concernent ni WordPress, ni PrestaShop, ni une extension en particulier : elles se trouvent dans le moteur PHP lui-même, dans la façon dont il prépare puis nettoie chaque requête. Elles se déclenchent donc quel que soit le site ou le CMS installé.

CVE-2026-109618 : une corruption mémoire après un manque de mémoire

Lorsqu'une requête dépasse la mémoire autorisée, PHP l'interrompt. Si cette interruption tombe au mauvais moment, certaines données internes de la requête ne sont qu'à moitié initialisées. Le nettoyage de fin de requête les traite pourtant comme des données valides, ce qui corrompt la mémoire et peut aboutir à l'exécution de code choisi par l'attaquant.

Selon l'avis du projet PHP, le risque est maximal avec mod_php (PHP chargé directement dans Apache) : un exploit démontré permet à une requête non authentifiée de déclencher l'attaque avant même que le code du site ne s'exécute.

CVE-2026-109619 : un état global périmé réutilisé

La seconde faille touche un état interne propre à chaque requête, qui peut survivre à la libération de la mémoire qui le contenait. La requête suivante traitée par le même processus PHP (un « worker » PHP-FPM, par exemple) peut alors réutiliser cet état périmé avant qu'il ne soit réinitialisé. Les mesures provisoires publiées par PHP montrent qu'elle est liée au suivi de progression des envois de fichiers (session.upload_progress) et, en PHP 8.5, aux traces des erreurs fatales.

Pourquoi c'est sérieux

• Aucune authentification n'est nécessaire : une simple requête HTTP vers un site PHP suffit, sans compte ni formulaire particulier.
• Tous les sites PHP sont concernés : WordPress, PrestaShop, Joomla, Drupal, Laravel, Magento… Les estimations vont de 1,3 à plus de 1,9 million de serveurs exposés sur Internet.
• Les détails ont fuité avant la publication, ce qui a poussé le projet PHP à annoncer le correctif la veille. Du code d'exploitation circule déjà, non vérifié (et parfois piégé : ne l'exécutez pas).
• Des premières attaques sont évoquées par Cloudflare, sans confirmation à ce stade par le CERT-FR ni par le catalogue des failles exploitées de la CISA.
• Le précédent est parlant : en 2024, la faille CVE-2024-4577 avait été exploitée moins de 24 heures après sa publication.

Versions concernées et versions corrigées

Le CERT-EU estime que toutes les versions depuis PHP 5 pourraient être touchées. Certains éditeurs proposent des correctifs rétroportés pour les anciennes branches, mais la seule solution durable reste de passer à une version maintenue.

Ce que nous faisons chez HaiSoft

Nous suivions l'annonce depuis la veille et nous étions prêts : les mises à jour sont en cours de déploiement sur nos serveurs.

• Hébergement mutualisé : les versions corrigées sont installées sur l'ensemble des versions de PHP proposées. Vous n'avez rien à faire, l'opération est transparente pour vos sites.
• Serveurs dédiés et virtuels infogérés : nous mettons à jour PHP sur chaque serveur, cette intervention est incluse dans votre contrat d'infogérance. Les paquets corrigés du dépôt sury.org sont déjà disponibles et en cours d'installation.
• Serveurs sous Plesk ou avec les paquets officiels Debian : Plesk et Debian n'ont pas encore publié leurs paquets corrigés. Nous suivons leurs publications et appliquerons les mises à jour dès leur sortie.
• Sites encore en PHP 8.1 ou antérieur : ces versions ne recevront pas de correctif. Nous contacterons les clients concernés pour planifier une migration vers une version maintenue.

Vous administrez vous-même votre serveur ?

1. Faites l'inventaire des versions de PHP installées : php -v, les paquets php8.* de Debian, ou plesk bin php_handler --list sur Plesk.
2. Mettez à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou le paquet corrigé de votre distribution), puis redémarrez tous les services PHP-FPM et Apache si vous utilisez mod_php.
3. Si la mise à jour doit attendre, appliquez les mesures provisoires du projet PHP, qui réduisent le risque sans le supprimer.
4. Isolez les applications sur des versions non maintenues (VPN, filtrage, mise hors ligne), comme le recommande le CERT-EU, jusqu'à leur migration.
5. Surveillez tout shell, curl ou wget lancé par php-fpm, apache2 ou httpd : c'est le signe typique d'une exploitation réussie.

Les mesures provisoires recommandées par le projet PHP sont à placer dans le php.ini ou dans la configuration du pool PHP-FPM (pas dans un .user.ini ni via ini_set()), suivies d'un redémarrage de tous les workers :

; CVE-2026-109619
session.upload_progress.enabled = 0
; PHP 8.5 uniquement
fatal_error_backtraces = 0
; CVE-2026-109618 : limiter la taille des requêtes
; (8M sans envoi de fichiers, 32M avec)
post_max_size = 8M

Pour CVE-2026-109618, le projet PHP conseille aussi de fixer memory_limit = -1 sans que l'application puisse le modifier, et de limiter la taille des requêtes au niveau du serveur web ou du proxy. Ce réglage supprime toute limite de mémoire par script : à réserver aux cas où la mise à jour est vraiment impossible dans l'immédiat.