PHP2Shell : les deux failles RCE de PHP (CVE-2026-109618 et CVE-2026-109619) et quoi faire aujourd'hui

Le 21 octobre 2026, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux failles critiques du moteur PHP, surnommées PHP2Shell. Toutes deux peuvent permettre à un attaquant non authentifié d'exécuter du code sur un serveur PHP, dans les bonnes conditions. Elles sont notées CVSS 4.0 9,2, des preuves de concept publiques existent, et le 26 octobre la CISA les a ajoutées à son catalogue des vulnérabilités activement exploitées.

Les failles sont dans PHP lui-même, sous votre framework. Mettre à jour Laravel, Symfony ou WordPress ne les corrige pas : c'est le moteur PHP du serveur qu'il faut mettre à jour.

Les deux vulnérabilités

CVE-2026-109618

Corruption mémoire après un manque de mémoire. Quand une requête atteint memory_limit au mauvais moment, PHP abandonne la requête et laisse des données internes à moitié initialisées que le nettoyage traite ensuite comme valides. Des requêtes multipart forgées peuvent le déclencher même dans les limites de taille normales.

Sur Apache avec mod_php, cela peut arriver avant que le code de l'application ne s'exécute, et l'exécution de code à distance a été démontrée avec la configuration par défaut.

CVE-2026-109619

Utilisation de mémoire libérée entre deux requêtes. Une erreur fatale au mauvais moment (mémoire épuisée, délai dépassé) peut laisser un état interne pointant vers une mémoire libérée à la fin d'une requête précédente. La requête suivante sur le même worker peut l'utiliser.

L'exécution de code a été confirmée via la progression d'upload des sessions, activée par défaut, et sur PHP 8.5 via les traces des erreurs fatales.

Qui est exposé

Apache avec mod_php : le risque le plus élevé, car la première faille est atteignable avant votre application.
PHP-FPM : exposé via certains chemins du code applicatif et via les sessions ; le recyclage des workers réduit les chances par requête sans supprimer le risque.
Aussi touchés : php-cgi, FrankenPHP et LiteSpeed.
Versions : PHP 8.2 avant 8.2.35, 8.3 avant 8.3.36, 8.4 avant 8.4.27 et 8.5 avant 8.5.12. PHP 8.1 et antérieurs ne reçoivent plus de versions régulières ; seuls des correctifs de code source limités existent.

Correction : mettre PHP à jour, puis redémarrer

Vérifiez la version qui sert réellement les requêtes web, pas seulement le CLI : php -v peut différer du module Apache ou du pool FPM.
Passez en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou plus récent). Les paquets des distributions peuvent contenir le correctif sous un ancien numéro : Ubuntu 24.04 a par exemple corrigé 8.3.6-0ubuntu0.24.04.13. Lisez le changelog du paquet pour y trouver les CVE.
Redémarrez Apache et chaque pool PHP-FPM. Un worker démarré avant la mise à jour exécute encore l'ancien code en mémoire.
Si le serveur était exposé avant le correctif, cherchez des signes de compromission : fichiers PHP inattendus dans les dossiers d'upload, nouvelles tâches cron, processus inconnus.

Si vous ne pouvez pas corriger aujourd'hui

Ces mesures réduisent l'exposition sans remplacer la mise à jour. Appliquez-les dans php.ini, le pool FPM ou la configuration du serveur, jamais avec ini_set() ou .user.ini, qui arrivent trop tard, puis redémarrez les workers.

session.upload_progress.enabled=0 ferme le chemin des sessions de CVE-2026-109619.
Sur PHP 8.5, fatal_error_backtraces=0.
Gardez post_max_size petit (8M, ou 32M si vous acceptez des uploads) et bloquez les requêtes multipart au proxy sur les routes qui n'en reçoivent pas.
Masquer les erreurs avec display_errors ou @ ne sert à rien : l'état obsolète est quand même lu.

Une troisième faille PHP, pas encore corrigée

Une autre faille, CVE-2026-115560, a été divulguée le 23 octobre. Elle concerne la sérialisation des sessions et la progression d'upload, demande une configuration inhabituelle et n'a pas encore de correctif. Désactiver la progression d'upload des sessions la bloque aussi : raison de plus d'appliquer ce réglage maintenant.

Ce que nous avons fait sur nos serveurs

Nous faisons tourner PHP en production, alors nous avons fait les mêmes vérifications sur nos serveurs : chacun sert PHP depuis une version corrigée ou un paquet de distribution qui contient le correctif, et chaque processus Apache et PHP-FPM a été redémarré après la mise à jour. Si vous avez un doute sur les vôtres, les trois vérifications ci-dessus prennent dix minutes.

Sources

Besoin d'aide pour vérifier vos serveurs PHP ?

Nous corrigeons, vérifions et sécurisons des environnements Laravel et PHP en production.

Contacter Elaitech