PHP2Shell : correctifs d’urgence pour PHP

Deux vulnérabilités critiques nommées PHP2Shell (CVE-2026-109618 et CVE-2026-109619) permettent une prise de contrôle de processus PHP via une réutilisatio

byEric Wallet

30 octobre 2026

Ce qui s’est passé

Le 21 octobre 2026, le projet PHP a publié en urgence les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux failles critiques, surnommées « PHP2Shell ». Elles sont décrites dans l’avis de sécurité de php.net. Les identifiants sont apparus publiquement la veille de la sortie, ce qui a donné de l’avance aux attaquants, d’après l’annonce de la PHP Foundation.

CVE (Common Vulnerabilities and Exposures) : identifiant public et standardisé d’une vulnérabilité. Il permet de retrouver les avis, correctifs et références techniques. Vérifiez toujours la fiche CVE et les bulletins des mainteneurs.

Une précision sur le mécanisme. Il ne s’agit pas d’une simple « allocation qui échoue » dont les restes seraient réutilisés. Le problème vient de la façon dont PHP réagit à un dépassement de memory_limit : il interrompt le travail en cours, et l’état interne du processus peut rester incohérent. D’après l’analyse d’OX Security, les deux failles découlent de cette gestion de la mémoire insuffisante, mais constituent deux défauts distincts.

Des tentatives d’exploitation ont été constatées dès le jour de la publication. Selon BleepingComputer, des honeypots ont enregistré le 24 octobre des exécutions de commandes réussies sur un Apache avec mod_php et PHP 8.4.26. Les chercheurs précisent que ces serveurs avaient une configuration favorable à l’attaque. Cela ne prouve donc pas la même fiabilité sur d’autres configurations.

Pourquoi cela concerne les développeurs

La faille se situe dans le moteur PHP, pas dans votre framework ni dans vos dépendances. Mettre à jour WordPress, Symfony ou Laravel ne suffit donc pas : la requête peut compromettre le runtime avant que votre code applicatif ne s’exécute.

Les conséquences possibles sont celles d’une exécution de code à distance sans authentification. Le code attaquant s’exécute avec les droits du processus web. Il peut donc lire ce que ce compte lit (fichiers de configuration, identifiants d’application) et écrire là où il écrit, par exemple pour déposer un webshell. Plus les droits du compte sont larges, plus l’impact est lourd.

CVE-2026-109618 et CVE-2026-109619 en détail

CVE-2026-109618 : exécution de code via corruption après dépassement mémoire

Ce que c’est : une faille de type use-after-free. Un dépassement de mémoire laisse l’état de la requête partiellement initialisé, puis l’arrêt de la requête exploite cet état invalide (avis GHSA-w8hw-w9fx-j79w).
Touchés : toutes les versions antérieures à 8.2.35, 8.3.36, 8.4.27 et 8.5.12, branches en fin de vie comprises.
Correctif : mise à jour vers l’une de ces versions.

CVE-2026-109619 : exécution de code via état global périmé

Ce que c’est : un état global conservé par un worker pointe vers la mémoire libérée d’une requête précédente. La requête suivante, traitée par le même worker, peut l’exploiter avant la réinitialisation (avis GHSA-6wmf-4rv5-p3rp).
Touchés : mêmes versions que ci-dessus.
Correctif : mêmes versions corrigées.

Le risque est présenté comme le plus élevé avec Apache et mod_php. PHP-FPM, FrankenPHP et LiteSpeed sont aussi cités comme exposés, selon Pentest-Tools. Les deux failles ont une gravité de 9,2 (CVSS v4.0).

PHP 8.1 et antérieurs : aucune version officielle n’a été publiée. Le projet a diffusé des correctifs minimaux sous forme de sources pour 7.4, 8.0 et 8.1, et certaines distributions ou éditeurs LTS fournissent des paquets rétroportés. Sans rétroportage fourni par votre distribution, la seule voie sûre est de migrer vers une branche supportée.

Vérifier si vous êtes concerné

Commencez par la version et le mode d’exécution :

php -v
php-fpm -v            # ou php-fpm8.3 -v selon votre paquet
apachectl -M | grep -i php
ps aux | grep -E 'php-fpm|httpd|apache2|lsphp|frankenphp'

Attention : php -v renvoie la version du binaire en ligne de commande, qui peut différer de celle réellement utilisée par le serveur web. Vérifiez aussi la version du binaire FPM, du module Apache ou de l’image de conteneur qui sert les requêtes.

Sur Debian ou Ubuntu, les distributions rétroportent souvent les correctifs sans changer le numéro de version amont. Consultez donc le journal des modifications du paquet :

apt changelog php8.3-fpm | grep -i -E 'CVE-2026-10961[89]'
# RHEL / Rocky / Alma
rpm -q --changelog php-fpm | grep -i -E 'CVE-2026-10961[89]'

Vérifiez ensuite l’état de la directive session.upload_progress (utile pour la mitigation ci-dessous) :

php -i | grep session.upload_progress.enabled

Pour détecter une exploitation, cherchez des fichiers PHP récents ou inattendus, des processus enfants anormaux lancés par le serveur web et des POST vers des endpoints non publics :

find /var/www -name '*.php' -mtime -10 -ls
ps -eo pid,ppid,user,cmd --forest | grep -E 'apache|www-data|php' 
grep -E '"POST ' /var/log/nginx/access.log* /var/log/apache2/access*.log*

Les journaux d’accès ne contiennent normalement pas le corps des requêtes. Pour repérer l’usage du champ d’upload de session dans des POST multipart, il faut un WAF ou un IDS. Des règles Sigma ont été diffusées par la CISA, d’après les médias cités plus haut.

Correctifs et mitigations immédiates

1. Mettre à jour. C’est la seule correction complète. Installez la version corrigée de votre branche, puis redémarrez PHP-FPM ou le serveur web, faute de quoi d’anciens workers continuent de tourner :

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm     # adaptez au nom de votre service
sudo systemctl restart apache2        # si mod_php

Si vous utilisez le dépôt communautaire rpms.remirepo.net, l’avis PHP recommande de passer aux paquets de votre distribution ou de compiler depuis les sources, car ce dépôt n’était pas à jour le jour de la sortie (UpGuard).

2. Conteneurs. Reconstruisez vos images avec une version PHP corrigée, puis redéployez. Un simple apt upgrade dans un conteneur en cours d’exécution ne remplace pas ce redéploiement.

3. Hébergement mutualisé ou PaaS. Demandez à votre hébergeur de confirmer la version déployée et la date du correctif.

4. Mitigation temporaire. Si la mise à jour est impossible immédiatement, la désactivation de la progression d’upload de session était déjà recommandée avant les correctifs, d’après Techzine. Elle ne remplace pas la mise à jour :

; php.ini
session.upload_progress.enabled = 0

; ou, dans un pool PHP-FPM
php_admin_value[session.upload_progress.enabled] = 0

Complétez avec une règle de WAF si vous en avez un, et réduisez les privilèges du compte qui exécute PHP. Lorsque c’est possible, isolez l’hôte du réseau public le temps de la mise à jour.

Une troisième faille à surveiller. PHP a aussi signalé la CVE-2026-115560, sans correctif à la date des sources consultées. Elle ne serait exploitable que dans une combinaison inhabituelle de configuration et de code applicatif, et la même mitigation (session.upload_progress.enabled=0) est conseillée en attendant (BleepingComputer).

Si vous suspectez une compromission

Isolez la machine du réseau sans l’éteindre brutalement, pour préserver les traces en mémoire.
Sauvegardez les journaux et, si possible, une image disque pour analyse.
Cherchez des indicateurs : fichiers PHP modifiés ou récents, connexions sortantes inhabituelles, tâches cron ou comptes ajoutés.
Réinstallez le système et les runtimes à partir de sources de confiance, redéployez votre code depuis votre dépôt, puis renouvelez tous les secrets accessibles par le compte PHP (clés d’API, mots de passe de base de données, jetons).

Quelques commandes utiles pour l’investigation de base :

ss -tunap | grep -v 127.0.0.1
lsof -u www-data -nP | grep -i ESTABLISHED
crontab -l -u www-data; ls -la /etc/cron.*
find / -xdev -type f -mtime -10 -newer /etc/hostname 2>/dev/null | head -100

Des scanners comme rkhunter ou Maldet, ou un outil de collecte de journaux (SIEM), aident à corréler les indices. Leur absence de détection ne prouve pas que la machine est saine.

Suivi et organisation

Suivez les deux identifiants CVE et l’avis officiel de php.net, ainsi que les bulletins de votre distribution.
Faites l’inventaire de toutes vos instances PHP, y compris les images de conteneurs et les serveurs oubliés.
Prévoyez un processus de correctif accéléré : tests de non-régression ciblés, puis déploiement progressif.
Planifiez la sortie des branches en fin de vie. D’après les sources consultées, PHP 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026.