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, quel que soit son framework. Voici ce qui est établi, ce qui ne l'est pas encore, et le plan d'action pour votre infrastructure.
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.
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.