Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux failles critiques permettant une exécution de code à distance (RCE, remote code execution) sans authentification. Elles touchent l'interpréteur lui-même, donc toute application PHP. Nous détaillons ce qui est établi, le plan d'action, puis ce que notre équipe a fait sur les 159 VM PHP que nous exploitons : correctif déployé en environ 30 minutes pour PHP 8.4 et en 2 h 30 pour PHP 8.2.
Ce que l'on sait des deux failles php2shell
Les deux failles portent les identifiants CVE-2026-109618 et CVE-2026-109619. Leur score CVSS v4.0 est de 9,2 (la PHP Foundation précise que le score de 10,0 qui a circulé avant la publication était erroné).
| . | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| Nature | corruption mémoire déclenchée par un dépassement de memory_limit (OOM, out of memory) | utilisation d'un état global périmé (use-after-free) après une erreur fatale |
| Authentification | aucune | aucune |
| Cas démontré | Apache avec mod_php, réglages par défaut | Apache avec mod_php, application réelle |
D'après Rapid7, la première faille peut être déclenchée par des requêtes multipart (envoi de fichiers) spécialement construites. La seconde exploite un worker réutilisé qui conserve un état pointant vers de la mémoire libérée. Le suivi de progression des uploads de session, activé par défaut, peut servir de point d'entrée.
PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed sont concernés. Le risque est jugé le plus élevé avec mod_php, où l'exploitation peut réussir avant l'exécution du code de l'application (PHP Foundation, Tenable, Rapid7). Le chemin de code concerné le plus ancien remonte à PHP 5.4.0 (Tenable).
Quelles versions corriger ?
- Branche
- Version corrigée
- 8.5
- 8.5.12
- 8.4
- 8.4.27
- 8.3
- 8.3.36
- 8.2
- 8.2.35
- 7.4, 8.0, 8.1
- pas de version officielle ; backports sources minimaux
- 5.4 à 7.3
- fin de vie, aucun correctif du projet
Sources : PHP Foundation (versions corrigées), Tenable et Rapid7 (état des branches anciennes). Le correctif a été publié le 21 octobre 2026 à 14:00 UTC, un jour avant la date initialement prévue, après des fuites d'informations le 20 octobre et la publication anticipée d'images corrigées par un tiers (Chainguard, 21 octobre à 07:41 UTC, selon la PHP Foundation).
Conséquence pratique : si vous exploitez PHP 8.1 ou une version antérieure, aucune mise à jour simple ne vous attend. La seule voie sûre est la migration vers une branche supportée.
Exploitation : ce qui est confirmé et ce qui ne l'est pas
Les sources ne disent pas la même chose, et l'état évolue d'heure en heure.
- La PHP Foundation indique qu'aucun exploit fonctionnel n'avait été identifié au moment de la publication.
- Rapid7 (21 octobre) ne confirme aucune exploitation dans la nature, tout en jugeant un exploit viable imminent.
- Tenable, citant Amazon Threat Intelligence, rapporte une tentative dès le 17 octobre sur un réseau de pots de miel (honeypots), puis d'autres le 21 octobre. Cloudflare et watchTowr signalent aussi des tentatives. Amazon ne sait pas si elles auraient réussi.
- Patchstack, éditeur spécialisé WordPress, parle d'exploitation active. SFEIR relève qu'à 16h30 UTC le 21 octobre, Patchstack ne voyait que des sondes.
Nous retenons : tentatives d'exploitation signalées, succès non confirmés publiquement. Pour un décideur, la conclusion opérationnelle ne change pas : un code de preuve de concept a fuité, des sondes sont observées, et le délai de grâce est court.
L'ampleur de l'exposition : une estimation de Silas Cutler, rapportée par Tenable, évoque plus de 1,3 million d'hôtes potentiellement vulnérables. À prendre comme un ordre de grandeur, non comme un recensement.
Que faire dans les 24 heures
1. Inventorier. Listez tous les serveurs, conteneurs et images qui embarquent PHP : sites vitrines, WordPress, Magento, intranets, outils internes, images Docker de base. Rapid7 cite l'artefact Velociraptor Generic.Applications.PHPInventory pour cela.
2. Mettre à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, puis redémarrer tous les workers. Reconstruire les images de conteneurs : une image non reconstruite reste vulnérable.
3. En attendant, réduire l'exposition (mesures listées par la PHP Foundation et Rapid7, qui insistent sur le fait qu'elles ne rendent pas l'installation sûre) :
Limitez aussi post_max_size, upload_max_filesize et la taille des requêtes multipart sur le serveur web ou le reverse proxy. Masquer les erreurs ne protège pas, et l'absence de logs ne prouve rien.
4. Isoler les applications exposées tant que le correctif n'est pas appliqué et vérifié, comme le recommande le CERT-EU (rapporté par Tenable). Un WAF (pare-feu applicatif) peut aider : Cloudflare a déployé des règles, présentées comme provisoires et limitées à son trafic.
5. Surveiller les requêtes multipart anormales, les plantages de workers PHP et les processus enfants inattendus lancés par le serveur web.
Ce que ça change pour votre entreprise
- Risque : une exécution de code avec les droits du processus web donne un point d'appui sur le serveur, puis sur le réseau interne si celui-ci n'est pas segmenté. La segmentation limite la suite de l'attaque.
- Coût : pour une infrastructure à jour et supervisée, le correctif est une opération de maintenance. Pour un parc hétérogène (PHP 7.x, images non reconstruites, applications sans responsable), le coût réel est l'inventaire.
- Délai : le correctif est disponible, des sondes sont signalées, et un exploit public est jugé imminent. Comptez en heures, pas en semaines.
- Dette technique : une application sur PHP 7.4 ou 8.0 n'a pas de version corrigée officielle. Le coût d'une migration se compare à celui d'un incident.
Ce que nous avons fait chez Pilot Systems
Nous avons traité la faille sur l'ensemble des VM que nous exploitons et qui embarquent PHP. Voici le déroulé, avec les heures de Paris (la publication du correctif à 16:00 correspond à 14:00 UTC).
- Question
- Réponse
- Quand ?
- Début le 21 octobre au matin : étude de l'alerte, préparation, surveillance et déploiement de mesures d'atténuation. Le gros de l'opération s'est déroulé entre 16:00 (publication du correctif) et 18:30.
- Quel périmètre ?
- 159 VM avec PHP, quasi toutes en 8.4 ou 8.2. Très peu de conteneurs utilisent PHP.
- Combien de temps ?
- PHP 8.4 : environ 30 minutes entre la publication du correctif et son déploiement sur toutes les machines. PHP 8.2 : un peu plus, le temps que les paquets soient compilés ; tout était terminé à 18:30, soit 2 h 30 après la publication.
- Tous les clients en même temps ?
- Oui, par branche de PHP : 8.4 d'abord, puis 8.2.
- Quelles actions ?
- En amont : mesures d'atténuation (modification d'options PHP, règles activées sur Cloudflare). Au moment du correctif : mise à jour vers la version corrigée de chaque branche, puis redémarrage des workers.
- Quels problèmes ?
- Les paquets 8.2 compilés sont arrivés après ceux de la 8.4. Nous avions commencé à les compiler nous-mêmes ; les paquets officiels sont arrivés un peu avant la fin de notre compilation.
- Vérification ?
- Contrôle des versions déployées, puis surveillance du comportement des sites pour détecter toute anomalie.
Deux enseignements pratiques. Premièrement, les mesures d'atténuation posées dès le matin (options PHP, règles Cloudflare) ont réduit l'exposition pendant les heures d'attente du correctif, sans la supprimer : seule la mise à jour corrige, comme le rappellent la PHP Foundation et Rapid7. Deuxièmement, l'inventaire préalable fait la différence : savoir quelles VM portent quelle branche de PHP permet de traiter les branches l'une après l'autre sans attendre.
Pour un client, cela se traduit par une équipe joignable par chat ou par téléphone, qui répond en quelques secondes à des questions simples après une alerte de ce type : qu'avez-vous fait sur mon serveur, combien de temps cela a-t-il pris, quels problèmes avez-vous rencontrés, mon application a-t-elle été affectée ?
Les clients qui exploitent eux-mêmes leurs serveurs doivent assurer seuls l'inventaire, la mise à jour, la reconstruction des images et la vérification.
Conclusion
- Les failles php2shell touchent l'interpréteur, pas seulement WordPress ou un framework : inventoriez tout PHP.
- Mettez à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, redémarrez les workers, reconstruisez les images.
- Hors support (PHP 8.1 et antérieures), planifiez la migration et isolez en attendant.
FAQ
Mon site WordPress est-il concerné ? La faille est dans PHP, pas dans WordPress. Le facteur décisif est la version de PHP qui l'exécute. Patchstack et Sansec (cités par SFEIR) rapportent des exécutions de code sur WordPress, Drupal, Joomla et Magento.
Quelles versions de PHP sont corrigées ? 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026. PHP 7.4, 8.0 et 8.1 n'ont que des backports sources minimaux ; les versions antérieures n'ont pas de correctif.
Les réglages de contournement suffisent-ils ? Non. Selon la PHP Foundation et Rapid7, ils réduisent l'exposition sans rendre l'installation sûre. Seule la mise à jour corrige.
La faille est-elle déjà exploitée ? Des tentatives sont signalées par Amazon, Cloudflare, watchTowr et Patchstack ; Rapid7 ne confirmait pas d'exploitation réussie le 21 octobre. Traitez la situation comme urgente.
Mon hébergeur s'en occupe-t-il ? Cela dépend du contrat : un hébergement mutualisé géré applique souvent le correctif, une VM ou un conteneur que vous administrez non. Demandez la version PHP et la date de redémarrage des workers par écrit.