Annoncées la veille, publiées mercredi 21 octobre 2026 : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent deux failles qui permettent d'exécuter du code sur un serveur sans avoir le moindre compte. Note de gravité : 9,2 sur 10 (CVSS v4). Si votre site ou votre application tourne sous PHP, la mise à jour passe avant le reste de la semaine.
Que corrigent exactement ces deux failles ?
Le projet PHP les référence CVE-2026-109618 et CVE-2026-109619. La communauté les a surnommées PHP2Shell. Même conséquence pour les deux, une exécution de code à distance sans authentification, mais pas la même mécanique.
La première naît quand PHP manque de mémoire. Le traitement de ce cas peut l'interrompre alors que les données internes de la requête ne sont qu'à moitié initialisées, et le nettoyage de fin de requête les prend ensuite pour valides. La seconde laisse survivre un état interne de la requête alors que sa mémoire a été libérée : la requête suivante, traitée par le même processus, peut s'en servir avant que PHP ne le remette à zéro.
Le point qui change tout : l'attaque se joue avant que votre code ne tourne. Le projet PHP juge le risque le plus élevé avec mod_php, où un exploit démontré déclenche l'attaque avant tout code applicatif. Que votre application soit bien écrite ne vous protège donc pas.
Qui doit agir, et que fait déjà son hébergeur ?
Tout ce qui sert des pages avec PHP est concerné : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Cela couvre Laravel, mais aussi WordPress, Dolibarr, PrestaShop ou Magento, qui tournent tous sur PHP. Laravel Forge précise que les deux failles touchent des versions de PHP qui remontent à 2004.
| Où tourne votre PHP | Ce qui est déjà fait | Ce qu'il vous reste à faire |
|---|---|---|
| Laravel Cloud | Correctif appliqué en place par Laravel | Rien, les nouveaux déploiements utilisent des images à jour |
| Laravel Forge | Rien : les mises à jour automatiques ne touchent pas à PHP | "Update PHP" sur chaque serveur, ou la ligne de commande |
| Laravel Vapor | Runtimes corrigés disponibles | Redéployer (nouveau déploiement si image personnalisée) |
| Serveur Debian ou Ubuntu à vous | Paquets de la distribution ou du dépôt PHP | Mettre à jour le paquet, redémarrer |
| Conteneurs Docker | Rien | Reconstruire les images |
| Hébergement mutualisé | Dépend de l'hébergeur | Lui demander la version de PHP et la date du correctif |
Un détail pour les serveurs Red Hat et dérivés : le projet PHP prévient que le dépôt bénévole rpms.remirepo.net n'aurait pas de mise à jour le jour de la sortie, et conseille les paquets de la distribution ou une compilation depuis les sources.
Comment mettre PHP à jour sur un serveur Ubuntu ou Debian ?
Commencez par la version qui sert réellement le web, pas celle de la ligne de commande, qui peut être différente :
php -v php-fpm8.4 -v
Puis la mise à jour du paquet, ici pour PHP 8.4 (répétez pour chaque version installée). La commande vient de la documentation de Forge, avec les dépôts d'Ondřej Surý :
sudo apt-get update apt-cache policy php8.4-fpm sudo apt-get install --only-upgrade -y \ -o Dpkg::Options::="--force-confold" \ $(dpkg -l 'php8.4*' | awk '/^ii/ {print $2}')
La ligne Candidate doit afficher la version corrigée. Sinon, les paquets ne sont pas encore arrivés dans le dépôt : patientez un peu. Sur les paquets de distribution, le numéro peut paraître ancien alors que le correctif est présent. Cherchez alors la CVE dans le journal des modifications du paquet :
apt changelog php8.2-fpm | grep -i 'CVE-2026-1096'
Dernier geste, souvent oublié : redémarrer les processus longs. PHP-FPM redémarre avec le paquet, mais les workers de files d'attente, Horizon ou Octane gardent l'ancien PHP en mémoire.
php artisan queue:restart php artisan horizon:terminate php artisan octane:reload
Deux cas sans correctif : PHP 8.1 et antérieurs ne reçoivent plus rien du projet PHP (certaines distributions rétroportent, demandez à votre fournisseur), et Forge indique qu'un serveur sous Ubuntu 20.04 ou plus ancien ne peut pas être mis à jour. Il faut migrer. PHP 8.2 s'arrêtera de toute façon le 31 décembre 2026 : autant viser 8.4 ou 8.5.
Docker : l'image embarque son propre PHP
Mettre à jour la machine hôte ne change rien : chaque conteneur contient son PHP. Vérifiez dans chacun, puis reconstruisez sans cache :
docker exec <conteneur> php -v docker build --pull --no-cache -t monapp:2026-10-22 .
Méfiez-vous des étiquettes d'image figées sur une ancienne version de correctif (une version précise de PHP 8.2, par exemple) : --pull ne les fait pas avancer, il faut modifier l'étiquette dans le Dockerfile. Et reconstruisez aussi les conteneurs des workers et du planificateur, pas seulement celui du site.
Et si la mise à jour est impossible aujourd'hui ?
Le projet PHP est net : seule la mise à jour règle le problème, les contournements réduisent l'exposition sans rendre le serveur sûr. Pour tenir quelques heures, voici ceux qu'il recommande, à poser dans la configuration du pool PHP-FPM ou du serveur web, pas dans ini_set() ni dans un .user.ini :
; pool PHP-FPM (www.conf) php_admin_value[memory_limit] = -1 php_admin_value[post_max_size] = 8M php_admin_value[session.upload_progress.enabled] = 0 ; PHP 8.5 uniquement php_admin_value[fatal_error_backtraces] = 0
Le memory_limit à -1 paraît à contre-sens, mais la première faille se joue justement quand la limite est atteinte. La borne mémoire passe alors par le conteneur ou le cgroup, jamais par RLIMIT_AS ni RLIMIT_DATA, qui provoquent le même échec d'allocation. Gardez post_max_size bas (32M si vous recevez des fichiers) et limitez la taille des requêtes sur le serveur web ou le proxy. Redémarrez ensuite tous les workers. Un pare-feu applicatif ne suffit pas non plus : d'après la checklist de triage citée en source, Cloudflare a constaté que les attaquants adaptaient leurs charges utiles à ses règles.
Après le correctif, que vérifier sur le serveur ?
Les identifiants des failles circulent depuis le 20 octobre, avant la sortie du correctif. Prenez cette date comme repère et cherchez ce qui n'a rien à faire là, par exemple des fichiers PHP récents hors des dossiers de dépendances, ou dans storage et public/uploads :
find /var/www -type f -name '*.php' -newermt '2026-10-20' \ -not -path '*/vendor/*' -not -path '*/node_modules/*' find /var/www/app/storage /var/www/app/public/uploads -type f \ \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \)
Un déploiement légitime modifie aussi des fichiers : comparez avec l'historique de vos mises en production. Notre article sur la recherche des derniers fichiers modifiés avec find détaille la méthode.
Regardez ensuite ce qui permettrait à quelqu'un de revenir : tâches cron, minuteurs systemd, comptes utilisateurs inconnus, clés SSH ajoutées. Côté journaux, les chercheurs signalent des requêtes multipart inhabituelles suivies d'erreurs de mémoire, des erreurs 500 à répétition, des cookies de session démesurés et des redémarrages inexpliqués de workers.
En cas de doute, considérez que ce qu'un worker manipule a pu être lu : mots de passe de base de données, clés d'API, identifiants de messagerie, sessions actives. Changez-les. Pour APP_KEY sous Laravel, la rotation invalide les sessions et les données chiffrées avec elle : les versions récentes savent faire une rotation progressive avec APP_PREVIOUS_KEYS. Le correctif ajoute aussi une limite mémoire stricte, dont le dépassement termine le processus sans passer par les fonctions de fin d'exécution : revoyez memory_limit et post_max_size par rapport aux besoins réels de votre application. Et si une intrusion est avérée, repartez d'une image propre et d'une sauvegarde saine : un nettoyage à la main laisse presque toujours quelque chose.
Le suivi des serveurs fait partie de notre offre d'hébergement et de maintenance, et vous pouvez nous écrire si vous voulez qu'on regarde un serveur avec vous.
- Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ; PHP 8.1 et antérieurs ne sont plus corrigés par le projet.
- Mettre à jour Laravel ne met pas PHP à jour : c'est le serveur ou l'image Docker qu'il faut traiter.
- Après la mise à jour, redémarrez PHP-FPM et tous les workers, puis cherchez les fichiers récents à partir du 20 octobre.
- Les contournements ne remplacent pas le correctif.
Sources : annonce de sécurité de PHP, point d'étape de Laravel, procédure Forge et checklist de triage de Harry Agustiana.
Questions fréquentes
Quelles versions de PHP contiennent le correctif ?
PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026. PHP 8.1 et les versions plus anciennes ne reçoivent plus de mises à jour du projet PHP, même si certaines distributions proposent un correctif rétroporté.
Mettre à jour Laravel suffit-il à corriger la faille ?
Non. La faille est dans PHP lui-même, pas dans le framework. Il faut mettre à jour PHP sur le serveur ou dans l'image Docker, puis redémarrer PHP-FPM et les workers de files d'attente.
Mon site est sur un hébergement mutualisé, que dois-je faire ?
C'est votre hébergeur qui met PHP à jour. Demandez-lui quelle version tourne pour votre site et si les correctifs du 21 octobre sont appliqués ; si vous pouvez choisir la version de PHP dans votre espace client, prenez une version corrigée.
Comment savoir si mon serveur a déjà été attaqué ?
Cherchez les fichiers PHP modifiés depuis le 20 octobre hors des dossiers de dépendances, les fichiers PHP dans storage ou les dossiers d'envoi, les tâches planifiées ou clés SSH inconnues, et les erreurs de mémoire ou 500 répétées dans les journaux. En cas de doute, changez les mots de passe et clés que l'application manipule.