Alerte sécurité PHP : mettez à jour vos serveurs !

Mercredi 21 octobre 2026, l'équipe de PHP a publié en urgence une version corrective hors calendrier pour colmater deux failles critiques au cœur du moteur d'exécution : les failles CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2/10 en CVSS. Il s'agit de vulnérabilités d'exécution de code à distance (Remote Code Execution ou RCE) exploitables sans aucune authentification préalable, ce qui constitue le scénario le plus grave en matière de sécurité web.

Cet événement dépasse le simple correctif de routine : les détails ont fuité sur Internet dès la veille de la sortie officielle, des preuves de concept circulent déjà (l'outil d'exploitation « PHP2Shell » a fait surface) et l'ANSSI a demandé la mise hors ligne préventive de plusieurs sites institutionnels français. La NSA et le FBI ont publié des alertes conjointes invitant les organisations à appliquer immédiatement les correctifs ou à déconnecter leurs systèmes vulnérables. Certains observateurs comparent la gravité de la situation à celle de Heartbleed en 2014.

Que vous gériez des serveurs dédiés, des VPS ou des hébergements mutualisés pour vos applications Laravel, voici ce qu'il faut savoir et comment réagir.

1. De quoi s'agit-il exactement ?

Les failles ne se situent ni dans le code de vos applications ni dans vos packages Composer ; elles touchent directement le moteur de PHP lui-même.

Corruption de la mémoire lors des dépassements (CVE-2026-109618)

Lorsque la limite globale autorisée (memory_limit) est dépassée, PHP interrompt brutalement son exécution via un longjmp. Dans des scénarios précis, notamment lors du traitement de formulaires complexes ou de téléversements de fichiers, cette interruption laissait la mémoire dans un état partiellement initialisé. Le moteur pouvait ensuite réutiliser par erreur ces segments corrompus, offrant ainsi à un attaquant l'opportunité d'injecter et d'exécuter du code malveillant. Cette faille permet également une fuite de mémoire serveur : le gestionnaire de progression du téléversement peut renvoyer au client des fragments de mémoire libérée contenant des mots de passe, des jetons de session ou des clés API d'autres requêtes.

Persistance d'état interne entre requêtes (CVE-2026-109619)

Dans les environnements à processus persistants, comme PHP-FPM, l'abandon d'une requête à la suite d'une erreur fatale pouvait laisser des résidus de données en mémoire après leur libération. Une requête ultérieure, potentiellement émise par un utilisateur différent, pouvait alors accéder involontairement à ces données ou déstabiliser le moteur. L'exécution de code a été confirmée sur PHP-FPM via le mécanisme de progression de téléversement de session ; la configuration la plus exposée est Apache avec mod_php.

2. Quelles sont les versions concernées et les correctifs à appliquer ?

Toutes les versions antérieures aux sous-versions correctives publiées le 21 octobre 2026 sont vulnérables. Les correctifs ont été publiés le 21 octobre 2026.

Branche PHP	Version minimale sécurisée	Statut
PHP 8.5	8.5.12	Patchée
PHP 8.4	8.4.27	Patchée
PHP 8.3	8.3.36	Patchée
PHP 8.2	8.2.35	Patchée
PHP 7.4, 8.0, 8.1	—	EOL : backports source fournis par PHP
PHP 7.x et antérieures	—	EOL : aucun correctif

Attention, nuance importante pour les versions 7.4, 8.0 et 8.1

Ces versions ont atteint leur fin de vie officielle, mais l'équipe PHP a tout de même publié des correctifs « backportés » au niveau du code source, à compiler soi-même ou à obtenir auprès de son distributeur. Si vos applications tournent encore sur ces versions, la migration vers PHP 8.2+ reste la priorité absolue, car les backports ne sont qu'une solution temporaire.

Autre piège, plus subtil

Si vous utilisez les paquets de votre distribution (Debian, Ubuntu, RHEL et dérivés), le numéro de version affiché par php -v ne change généralement pas après une mise à jour de sécurité, parce que le correctif est intégré en amont dans le paquet existant. Une version 8.1.2 affichée peut donc être parfaitement patchée. Pour savoir où vous en êtes vraiment, interrogez le journal des modifications du paquet :

- Debian/Ubuntu :
  zgrep CVE-2026-109618 /usr/share/doc/php*/changelog.Debian.gz

- RHEL, AlmaLinux ou Rocky Linux (paquets Remi : php81-php-common, etc.) : 
  rpm -q --changelog php-common | grep CVE-2026-109618.

3. Quel impact pour nos projets Laravel ?

Laravel repose fortement sur la gestion des requêtes HTTP, le traitement des fichiers, l'injection de dépendances et la manipulation intensive des structures en mémoire. Le framework lui-même n'est pas en cause, mais c'est presque un détail : une faille au niveau du binaire PHP sous-jacent contourne toutes les protections applicatives que Laravel met en place (middlewares, validation, sanitisation).

Si un pirate parvient à provoquer une corruption de la mémoire sur votre serveur via une requête spécialement conçue à cet effet, il peut exécuter des commandes arbitraires avec les privilèges du processus web (www-data, nginx, etc.) : lecture de votre fichier .env et de vos clés d'API, accès direct à votre base de données, installation d'un webshell, pivot vers le reste de votre infrastructure. Vos tests, votre code review et votre discipline de validation n'y changent rien : c'est le runtime qui est compromis.

4. Que devez-vous faire immédiatement ?

Sur un serveur dédié, VPS ou forge (Forge, Ploi, RunCloud, etc.)

Connectez-vous à votre serveur et mettez à jour les paquets PHP de votre système :

# Sur Ubuntu / Debian
sudo apt update
sudo apt full-upgrade

# Redémarrer PHP-FPM (ajustez selon votre version)
sudo systemctl restart php8.3-fpm

Vérifiez ensuite la version effective et le journal du paquet (cf. la nuance de la section 2) :

php -v

Redémarrez également vos services longs embarquant PHP (workers de file d'attente, Horizon, planificateur) : un processus PHP lancé sur une ancienne version reste vulnérable jusqu'à son redémarrage.

En environnement de développement (Docker/Laravel Sail)

Reconstruisez vos images Docker pour récupérer les derniers paquets et déployez la mise à jour sur vos environnements de production, et pas seulement en local :

sail build --no-cache

Sur un hébergement mutualisé

Vous n'avez pas la main sur le binaire PHP, mais les grands hébergeurs ont généralement déployé le correctif dès sa publication. Cpanel/WHM, par exemple, a sorti les mises à jour pour ses versions PHP 7.4 et supérieures. Concrètement :

Connectez-vous à votre panneau de gestion (cPanel, console d'administration).
Vérifiez la version exacte de PHP exécutée par votre site (via SSH si disponible, ou temporairement avec phpinfo()).
Si la version affichée est inférieure à la version corrective de votre branche et qu'aucune mise à jour n'est annoncée, contactez le service d'assistance de votre hébergeur pour vous assurer que le déploiement est en cours.

Si vous ne pouvez pas appliquer le correctif immédiatement

Pendant le temps de la mise à jour, réduisez la surface d'exposition : restreignez l'accès public à l'application (liste blanche d'adresses IP, page de maintenance), appliquez les règles de filtrage publiées par les principaux WAF (Cloudflare les a diffusées dès le jour de l'annonce) et, si nécessaire, désactivez les fonctionnalités à risque telles que la progression de téléversement de session (session.upload_progress.enabled). Ces mesures ne remplacent pas le correctif ; elles ne font que gagner du temps.

Conclusion

En matière de sécurité web, la réactivité est essentielle. Des preuves de concept circulent déjà : le risque n'est plus théorique, il est exploité à l'heure actuelle sur les serveurs inactifs. Prenez quelques minutes aujourd'hui pour auditer les versions PHP de vos serveurs de production et de staging, redémarrez vos workers et poussez la mise à jour de vos images Docker. Une simple mise à jour des paquets suffit à fermer la porte à ces deux vulnérabilités. N'oubliez pas que pour toute requête de sécurité, la règle d'or reste : patcher d'abord, redémarrer ensuite, vérifier toujours.

LARAVEL