PHP2Shell : corriger CVE-2026-109618 et CVE-2026-109619

Le 26 octobre 2026, la CISA, l'agence américaine de cybersécurité, a ajouté les deux failles (CVE-2026-109618 et CVE-2026-109619) à son catalogue des vulnérabilités connues comme exploitées, le KEV (Known Exploited Vulnerabilities). Une entrée n'y figure que lorsqu'une exploitation réelle est établie : jusqu'ici, ce constat reposait sur les pièges réseau de watchTowr ; il vient désormais d'une autorité publique.

La CISA a fixé l'échéance au 29 octobre 2026, soit trois jours après l'ajout. Cette date ne s'impose qu'aux agences fédérales américaines, mais elle donne l'ordre de grandeur de l'urgence qu'un organisme public attribue à ces failles : quelques jours, pas la prochaine fenêtre de maintenance mensuelle.

PHP2Shell n'est pas une faille de WordPress, de Laravel ou d'un plugin : c'est le moteur PHP qui est en cause. Toute application PHP qui répond à des requêtes web est donc concernée, quel que soit son code. L'avis de sécurité cite PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed.

Les deux failles partagent un même mécanisme. Quand PHP interrompt brutalement une requête (mémoire épuisée, erreur fatale), il peut laisser derrière lui un état interne à moitié initialisé ou déjà libéré. Une requête suivante, traitée par le même processus PHP, réutilise alors cet état : c'est ce qui ouvre la voie à une exécution de code à distance.

La plupart des failles web exigent un formulaire précis, un compte ou un plugin vulnérable. PHP2Shell n'a besoin de rien de tout cela : le déclencheur le plus courant est le traitement d'un envoi multipart/form-data avec le suivi de progression des sessions (session.upload_progress), un mécanisme que PHP active par défaut et qui s'exécute avant le premier octet de votre application. Un pare-feu applicatif placé dans votre code, un plugin de sécurité WordPress ou un middleware Laravel arrivent donc trop tard.

Le second facteur est le modèle d'exécution lui-même. PHP-FPM et Apache réutilisent le même processus pour des centaines de requêtes successives : c'est précisément ce qui permet à une requête piégée de contaminer la suivante. Selon Imperva, les techniques publiées vont du plantage de processus à la lecture de fichiers arbitraires via le cache OPcache, en passant par la fuite d'environ 67 Ko de mémoire du processus dans un cookie PHPSESSID surdimensionné. Cette mémoire peut contenir des mots de passe de base de données ou des clés d'API.

Attention à un piège classique : la version affichée par php -v en ligne de commande n'est pas forcément celle qui sert vos sites. Un serveur peut avoir plusieurs versions de PHP-FPM installées côte à côte, et chaque site peut pointer vers une version différente. Il faut donc vérifier la version réellement servie par le web, site par site.

Les distributions Linux et les fournisseurs de support étendu ont reçu les correctifs avant la publication. Le paquet corrigé de votre distribution ne porte donc pas forcément le numéro 8.3.36 : Ubuntu 24.04, par exemple, corrige sa version 8.3.6 dans le paquet 8.3.6-0ubuntu0.24.04.13. Fiez-vous à l'avis de sécurité de votre distribution plutôt qu'au seul numéro de version de PHP. Dans tous les cas, le redémarrage est indispensable : tant que les anciens processus tournent, c'est l'ancien code qui répond.

Le journal d'EasyApache 4 (EA4) du 21 octobre 2026, version 25.91, couvre sept branches de PHP. Pour les branches maintenues, le numéro monte : ea-php82 passe de 8.2.34 à 8.2.35, ea-php83 de 8.3.35 à 8.3.36, ea-php84 de 8.4.26 à 8.4.27 et ea-php85 de 8.5.11 à 8.5.12. Pour ea-php74, ea-php80 et ea-php81, que cPanel a pourtant déclarées en fin de vie, le correctif est rétroporté : le numéro de version de PHP ne bouge pas, seule la révision du paquet change.

C'est le piège : php -v affiche alors une version « ancienne » alors que le code est corrigé, et une version ancienne dont le changelog ne cite pas les deux CVE reste vulnérable. Seule la lecture du changelog du paquet tranche. Une version 25.92, publiée le même jour, a d'ailleurs reconstruit les méta-paquets pour que leur changelog mentionne aussi le rétroportage.

CloudLinux publie ses propres paquets, et ils n'arrivent pas en même temps que ceux de cPanel. D'après son bulletin, les paquets ea-php (de 5.2 à 8.5) sont passés en stable le 21 octobre, les alt-php le 22 octobre sur CloudLinux 7, 8 et 9, le PHP natif du système le 22 octobre en fin de journée (UTC), et les paquets numérotés comme PHP.net le 23 octobre.

Là aussi, ce sont des rétroportages : ea-php84 y reste par exemple en 8.4.26 avec une révision propre à CloudLinux (8.4.26-2), tout en étant corrigé. Deux points d'attention : le 21 octobre, des alt-php annoncés comme publiés étaient en réalité dans le dépôt TuxCare ELS et non dans ceux de CloudLinux ; et le conseil de désactiver le dépôt php-els, donné le 22, a été corrigé le 23 au soir : laissez-le activé. Enfin, Imunify360 a publié ses règles WAF dès le 21 octobre (jeu de règles 8.83), la version 8.88 est en stable depuis le 23 : elles bloquent des vecteurs connus et ne remplacent pas la mise à jour.

MultiPHP et EasyApache gouvernent le PHP de vos sites. Les interfaces de cPanel, de WHM et le webmail Roundcube tournent, eux, sur un PHP interne livré avec cPanel lui-même, que le choix d'une version dans MultiPHP Manager ne touche pas. Le 21 octobre 2026, cPanel a publié une mise à jour de sécurité pour ce PHP interne, en précisant qu'elle « affecte PHP dans les interfaces cPanel, y compris le webmail Roundcube ».

Elle livre PHP 8.4.27 dans cPanel & WHM 138.0.18, 136.0.50 et 134.0.66, et des correctifs rétroportés pour PHP 8.1.34 dans la version 110.0.153. Ces interfaces sont ouvertes aux connexions de vos clients, donc souvent joignables depuis internet : ce sont des cibles de premier choix. Lisez votre version avec /usr/local/cpanel/cpanel -V (ou dans le bandeau de WHM) et comparez-la à ces numéros. Si votre série n'y figure pas, ne la supposez pas corrigée : consultez les notes de version de cPanel et passez à une série qui l'est.

L'avis officiel de PHP propose des réglages qui réduisent l'exposition sans rendre l'installation sûre. Ils servent à gagner quelques heures, pas à remplacer le correctif. Ils doivent être posés dans php.ini, dans le pool PHP-FPM ou dans la configuration du serveur web, jamais par ini_set() ni par un fichier .user.ini : ces derniers sont lus trop tard, après l'analyse de la requête.

Contre CVE-2026-109619, désactivez le suivi de progression des envois. Sur PHP 8.5, désactivez aussi les traces d'erreurs fatales :

; dans le pool FPM, par exemple /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
; PHP 8.5 uniquement :
php_admin_flag[fatal_error_backtraces] = off

Contre CVE-2026-109618, l'avis recommande memory_limit = -1 imposé par php_admin_value, afin qu'aucune application ne puisse le redéfinir, et une taille de requête bornée (post_max_size = 8M, ou 32M si vous avez besoin d'envois de fichiers). En contrepartie, la mémoire doit être plafonnée ailleurs, par une limite de conteneur ou de cgroup. N'utilisez pas RLIMIT_AS ni RLIMIT_DATA : ils provoquent justement l'échec d'allocation vulnérable.

Redémarrez ensuite tous les processus PHP pour que les réglages s'appliquent.

Les tentatives publiées laissent des traces caractéristiques : des processus PHP qui plantent, des dépassements de mémoire en rafale et des envois multipart anormalement volumineux. Si votre serveur a été exposé avant la mise à jour, prenez dix minutes pour vérifier.

Sur un hébergement mutualisé, ce n'est pas vous qui mettez à jour PHP : c'est l'hébergeur qui maintient les versions proposées. Votre part du travail consiste à vérifier que votre site utilise une branche encore corrigée. Dans cPanel, l'outil de choix de version (MultiPHP Manager, ou Select PHP Version sur un serveur CloudLinux) indique la version active de chaque domaine. Si votre site tourne encore en 7.4, 8.0 ou 8.1, ces branches ne reçoivent plus de version officielle de PHP : basculez vers 8.3 ou 8.4 après avoir testé votre site, en suivant notre checklist de migration PHP.

Les détails techniques et les réglages de contournement sont publiés dans l'avis de sécurité de PHP et dans les avis GitHub GHSA-w8hw-w9fx-j79w (CVE-2026-109618) et GHSA-6wmf-4rv5-p3rp (CVE-2026-109619). Pour les paquets de distribution, consultez l'annonce d'Ubuntu et celle d'AlmaLinux. Pour la suite : le catalogue KEV de la CISA, le journal EasyApache 4, les notes de version de cPanel & WHM, le bulletin de CloudLinux et la FAQ de watchTowr.