Tout savoir sur la faille PHP qui secoue plus de la moitié des plateformes web

Le 21 octobre 2026, une bombe silencieuse a explosé dans le monde du développement web. Deux failles critiques découvertes au cœur même de PHP, le langage qui alimente plus de 77 % des sites web dans le monde, ont été rendues publiques après avoir été exploitées dans l'ombre pendant quatre jours. Des serveurs ont été compromis. Des données ont été exposées. Et des milliers de développeurs ne le savaient pas encore.

Ces deux vulnérabilités, baptisées collectivement PHP2Shell (CVE-2026-109618 et CVE-2026-109619), permettent à n'importe quel attaquant non authentifié d'exécuter du code arbitraire sur ton serveur, sans compte, sans mot de passe, juste en envoyant la bonne requête. Score CVSS v4.0 : 9.2 sur 10. Classification : Critique.

Si tu utilises Laravel en production, cet article est peut-être la chose la plus importante que tu liras aujourd'hui.

1. C'est quoi PHP2Shell ?

PHP2Shell est le nom collectif donné à deux vulnérabilités critiques découvertes dans le moteur PHP lui-même, pas dans un framework, pas dans un package, mais dans le runtime qui fait tourner toute application PHP.

Les deux failles permettent à un attaquant non authentifié d'exécuter du code arbitraire sur le serveur cible. C'est ce qu'on appelle une RCE (Remote Code Execution), la catégorie la plus grave des vulnérabilités web.

Le nom est intentionnellement évocateur : PHP → Shell. Un attaquant qui exploite PHP2Shell n'a pas besoin d'un compte sur ton serveur. Il a juste besoin que PHP tourne.

Timeline de la divulgation

Date	Événement
~ oct. 2026	Wiz Security découvre les deux vulnérabilités, entame une disclosure coordonnée avec l'équipe PHP
17 octobre 2026	Amazon Threat Intelligence observe la première tentative d'exploitation, avant toute divulgation publique. Les informations avaient fuité.
21 octobre 2026	PHP publie des correctifs d'urgence. Les CVEs sont rendus publics.
21 oct. (soir)	Tenable confirme une exploitation active. Cloudflare signale des tentatives à large échelle. NCSC UK publie une alerte urgente.

Ce n'est pas une alerte théorique. Des acteurs malveillants tentaient d'exploiter ces failles 4 jours avant que les patches existent. Si tu n'as pas encore mis à jour, ta fenêtre d'exposition est ouverte depuis plusieurs jours.

2. Les deux failles expliquées simplement

CVE-2026-109618 : La gestion hors-mémoire (OOM)

Quand PHP manque de mémoire au milieu du traitement d'une requête, il tente de nettoyer. Mais dans certaines situations, les données de la requête sont partiellement initialisées et le code de nettoyage les traite comme valides.

Ce désalignement peut permettre à un attaquant de contrôler ce que PHP "nettoie", jusqu'à exécuter du code arbitraire.

L'analogie : Imagine un chef cuisinier qui perd connaissance à mi-préparation. Son commis, croyant que tout est prêt, sert les plats tels quels, dont certains contiennent des ingrédients crus. Si un attaquant peut provoquer cet "évanouissement" (en envoyant une requête conçue pour épuiser la mémoire), il peut potentiellement contrôler ce que PHP "sert" ensuite.

CVE-2026-109619 : L'état qui survit à la mémoire

L'état interne d'une requête peut persister en mémoire après sa libération officielle. Une requête ultérieure sur le même worker PHP peut accéder à ces données périmées et les exploiter.

L'analogie : C'est comme si dans un open-space, un employé laissait ses dossiers confidentiels ouverts en partant. Le collègue qui s'installe ensuite à la même place peut lire et modifier les informations du précédent. Dans PHP, le "bureau", c'est la mémoire d'un worker partagé.

Note : Il existe des divergences mineures entre les rapports de Sansec, Huntress et Datadog sur l'attribution exacte CVE→vecteur. Les mécanismes décrits ici sont ceux sur lesquels la majorité des sources concordent. Consulte les advisories officielles PHP (GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp) pour les détails définitifs.

3. Mon app Laravel est-elle vulnérable ?

Vérifier sa version PHP

php -v

Branche	Vulnérable si	Version corrigée	Statut
PHP 8.5	≤ 8.5.11	8.5.12	✅ Patch disponible
PHP 8.4	≤ 8.4.26	8.4.27	✅ Patch disponible
PHP 8.3	≤ 8.3.35	8.3.36	✅ Patch disponible
PHP 8.2	≤ 8.2.34	8.2.35	✅ Patch disponible
PHP 8.1	Toutes	n/a	❌ EOL, aucun fix
PHP 8.0 / 7.x	Toutes	n/a	❌ EOL, aucun fix

Check-list d'exposition

Application accessible depuis internet ? → Priorité maximale, patcher dans l'heure.
Mode d'exécution PHP : mod_php (Apache) = risque maximal selon Tenable. PHP-FPM = exposé. CLI uniquement = non exposé.
PHP 8.1 ou inférieur en production ? → Aucun patch disponible. Migrer vers 8.2+ est la seule vraie solution.
Hébergeur géré (Laravel Cloud, Forge, Render…) ? → Vérifier le dashboard ou contacter le support. Certains ont déjà patché automatiquement.
Docker avec image PHP officielle ? → Les images php:8.X-fpm et php:8.X-apache sont déjà mises à jour sur Docker Hub.

4. Comment patcher : commandes prêtes à l'emploi

Ubuntu / Debian

# Mettre à jour les dépôts et PHP
sudo apt update
sudo apt upgrade php8.4 php8.4-fpm   # adapter selon votre version

# Vérifier que le patch est appliqué
php -v

# Redémarrer PHP-FPM
sudo systemctl restart php8.4-fpm

Red Hat / Fedora / Rocky Linux

sudo dnf update php php-fpm
sudo systemctl restart php-fpm

macOS (développement local)

brew upgrade php
# ou pour une version spécifique :
brew upgrade php@8.4

Docker

# Remplacer l'image de base par une version patchée
FROM php:8.4.27-fpm-alpine
# ou
FROM php:8.3.36-apache

Laravel Forge (via SSH)

sudo apt update && sudo apt upgrade -y php8.4 php8.4-fpm
sudo systemctl restart php8.4-fpm nginx

Après le patch : vérifier que l'app démarre correctement, puis :

php artisan config:cache
php artisan route:cache

5. Si je ne peux pas patcher maintenant

⚠ Ces mitigations ne remplacent pas le patch. Applique-les uniquement si tu es bloqué par un freeze de déploiement.

Désactiver session.upload_progress dans php.ini : session.upload_progress.enabled = Off. Cela réduit la surface d'attaque sans corriger la faille.
Réduire post_max_size et upload_max_filesize à des valeurs strictement nécessaires. Cela limite les vecteurs OOM (CVE-2026-109618).
Activer les règles PHP RCE sur ton WAF (Cloudflare, AWS WAF). Cela filtre les patterns d'exploitation connus, mais ne corrige pas la faille sous-jacente.
Monitorer les logs Apache/Nginx pour détecter des requêtes anormalement longues, des erreurs 500 en rafale, ou des payloads inhabituels.

PHP 8.1 et inférieur : aucune mitigation ne compense l'absence de patch. La seule vraie solution est de migrer vers PHP 8.2+.

6. Ce qu'on retient

Les failles core-runtime sont les plus dangereuses

La plupart des vulnérabilités web touchent une librairie ou une app. PHP2Shell touche PHP lui-même, avant même que ton code Laravel tourne. Il n'existe aucune défense applicative contre ça. La seule solution : garder PHP à jour.

La fenêtre d'exploitation précède parfois le patch

PHP2Shell a été tenté 4 jours avant la publication des correctifs. Ce n'est pas un cas unique : des CVEs fuient régulièrement avant leur date de divulgation officielle. Abonne-toi aux bulletins de sécurité PHP et aux alertes de l'ANSSI/CERT.

Les versions EOL sont un risque opérationnel permanent

PHP 8.1 est sorti de support actif. PHP 7.x, depuis longtemps. Ces versions existent encore massivement en production et elles resteront vulnérables à PHP2Shell indéfiniment. Migrer n'est plus une option, c'est une obligation de sécurité.