PHP2Shell : deux failles critiques dans PHP lui-même (CVE-2026-109618 et CVE-2026-109619), mettez à jour maintenant

Le 21 octobre 2026, le projet PHP a publié des versions correctives pour deux failles critiques dans le moteur PHP lui-même, regroupées par leurs découvreurs sous le nom PHP2Shell. Ce n'est pas un plugin, un framework ou un CMS : c'est l'interpréteur qui fait tourner WordPress, Drupal, Magento, Laravel et la majorité des sites web.

L'avis de PHP est sans ambiguïté : toutes les installations PHP qui servent des requêtes web sont concernées, et la seule réponse complète est la mise à jour.

Le score est celui publié par l'équipe sécurité de PHP ; NVD n'a pas encore publié le sien.

Les deux failles

CVE-2026-109618 — corruption après un manque de mémoire. Quand PHP atteint sa limite de mémoire, il abandonne la requête en cours par un saut brutal hors du contexte d'exécution. Certains contextes laissent alors de la mémoire de la requête dans un état non initialisé, et la procédure de nettoyage qui suit peut lire ces données invalides comme si elles étaient valides. Selon NVD, plusieurs manières de provoquer ce manque de mémoire mènent de façon reproductible à l'exécution de code.

CVE-2026-109619 — état global périmé. PHP garde des pointeurs globaux qui visent temporairement la mémoire d'une requête. Dans certains cas, ces pointeurs ne sont pas remis à zéro, ou sont réalimentés après l'avoir été. La requête suivante traitée par le même processus peut alors lire cet état qui pointe vers de la mémoire déjà libérée.

Ce qui rend la situation sérieuse

• Aucun code applicatif n'est nécessaire. Wiz indique qu'une simple page « Hello World » sur une version touchée peut être vulnérable : les failles se situent sous l'application.
• Aucune authentification. Les deux sont exploitables à distance, sans compte.
• mod_php est le cas le plus exposé. L'avis PHP cite un exploit démontré où une requête non authentifiée déclenche l'attaque avant même que le code de l'application ne s'exécute.
• La surface est immense. Wiz écrit que toutes les versions publiées depuis dix ans sont touchées par au moins une des deux failles, jusqu'à la branche 5.4.

Le vecteur indique une complexité d'attaque élevée (AC:H) et des conditions préalables (AT:P) : l'exploitation dépend de l'état de la mémoire et du processus. Ce n'est pas une barrière pour un attaquant qui dispose d'un exploit fonctionnel.

Exploitation

Ni l'avis PHP, ni Wiz, ni la CISA ne font état d'exploitation active à la date de rédaction : la CVE n'est pas au catalogue CISA KEV, et l'évaluation SSVC de la CISA indiquait « exploitation : none » le 21 octobre à 14 h 34 UTC. Plusieurs médias spécialisés (Help Net Security, Patchstack) évoquent toutefois des détails ayant circulé avant la publication et de premières tentatives d'attaque. Nous ne pouvons pas le confirmer, mais avec un exploit démontré et une surface pareille, il faut raisonner comme si l'exploitation était imminente.

Versions corrigées

Branches en fin de vie. Le projet PHP ne publie plus de versions pour 8.1 et les branches plus anciennes. Il a fourni des correctifs minimaux sous forme de branches de code source pour les branches 7.4, 8.0 et 8.1, et certaines distributions et éditeurs de support étendu livrent leurs propres paquets corrigés. À défaut, la réponse est une migration vers une branche maintenue.

Paquets des distributions. Les distributions Linux et les éditeurs de support étendu ont reçu les correctifs à l'avance : vérifie les mises à jour de ton gestionnaire de paquets. Si tu utilises le dépôt communautaire rpms.remirepo.net, l'avis PHP précise qu'il n'aura pas de mise à jour le jour de la publication et recommande de passer aux paquets de la distribution ou de compiler depuis les sources.

Vérifier la version réellement utilisée par le serveur web, pas seulement celle de la ligne de commande — elles diffèrent souvent :

php -v
php-fpm -v            # ou php-fpm8.3 -v, selon la distribution
apachectl -M | grep -i php   # mod_php chargé ?

Une page phpinfo() temporaire, supprimée juste après, donne la version effectivement chargée par le serveur.

Mesures temporaires si la mise à jour doit attendre

L'avis PHP est clair : ces mesures réduisent l'exposition à certains chemins d'attaque mais ne rendent pas une installation sûre. Elles se placent dans php.ini, dans la configuration du pool FPM ou du serveur web — pas via ini_set() ni .user.ini — et exigent un redémarrage de tous les processus PHP.

Contre CVE-2026-109619 :

session.upload_progress.enabled = 0
; PHP 8.5 uniquement :
fatal_error_backtraces = 0

La première bloque les chemins confirmés passant par les sessions, pas les autres variantes.

Contre CVE-2026-109618 :

; Sans upload de fichiers :
post_max_size = 8M
; Avec upload de fichiers :
post_max_size = 32M
; upload_max_filesize doit rester inférieur à post_max_size

L'avis recommande aussi memory_limit=-1 imposé de façon non modifiable par l'application (par exemple php_admin_value dans le pool FPM), une limite de mémoire au niveau du conteneur ou du cgroup comme garde-fou de disponibilité, et des limites côté serveur web ou proxy sur la taille des requêtes, le nombre de champs et de parties multipart. Il déconseille RLIMIT_AS et RLIMIT_DATA, qui peuvent justement provoquer l'échec d'allocation vulnérable.

Détection

Wiz signale que les journaux applicatifs contiennent peu d'indices, puisque tout se passe sous l'application. Les signaux à surveiller :

• Requêtes multipart inhabituelles suivies d'erreurs de limite mémoire (Allowed memory size … exhausted) ou de rafales d'erreurs HTTP 500 ;
• Cookies PHPSESSID anormalement longs ou mal formés dans les réponses ;
• Redémarrages inexpliqués de processus PHP-FPM ou d'enfants Apache.

Mitigation, dans l'ordre

1. Inventorier tous les serveurs qui exécutent PHP pour le web, y compris les machines oubliées : intranet, vieux WordPress, outils internes.
2. Mettre à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou vers le paquet corrigé de ta distribution, puis redémarrer PHP-FPM ou Apache.
3. Commencer par mod_php et les serveurs exposés à Internet.
4. Appliquer les mesures temporaires là où la mise à jour ne peut pas être immédiate, en gardant en tête qu'elles ne suffisent pas.
5. Planifier la sortie des branches 8.1 et antérieures.

Pourquoi surveiller en continu vos versions de PHP

PHP est souvent la dépendance que personne n'inventorie : il est installé avec le système, mis à jour « quand on y pense », et sa version varie d'un serveur à l'autre. Une faille dans le moteur touche alors tout ce qui tourne dessus, d'un coup.

Avec cveo.tech, ajoute tes serveurs et leurs versions de PHP à ton parc, et reçois une alerte dès qu'une CVE critique les concerne — y compris quand elle est encore en attente d'analyse par NVD.