PHP2Shell : deux failles du moteur PHP donnent la main sur le serveur, sans authentification
Publié le
Le 21 octobre 2026, le projet PHP publie en urgence quatre versions correctives. Elles corrigent PHP2Shell, deux failles du cœur de PHP notées 9.2 (CVSS v4) : CVE-2026-109618 et CVE-2026-109619. Toutes deux permettent l’exécution de code à distance sans authentification, avec les droits du compte du serveur web. Les détails avaient fuité la veille, deux jours avant la date de divulgation prévue, et l’exploitation a été observée dès le jour du correctif.
Corrigé : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 (21 octobre 2026)
Que permet concrètement PHP2Shell ?
CVE-2026-109618 se déclenche quand PHP manque de mémoire au milieu de la préparation d’une requête : des structures internes restent à moitié construites et deviennent exploitables. CVE-2026-109619 tient à un état global qui survit à la requête qui l’a créé : la requête suivante traitée par le même processus agit sur des données périmées.
Le point commun, et ce qui rend la faille si grave : tout se passe dans le traitement de la requête par PHP, avant que votre script ne commence à s’exécuter. Une requête d’envoi de fichier (multipart) suffit, sur n’importe quelle page qui accepte un POST, même si cette page ignore complètement les fichiers reçus.
Mon site Magento ou WordPress est-il concerné ?
Oui, dès lors qu’il tourne sur une version de PHP non corrigée. La faille n’est ni dans Magento, ni dans WordPress, ni dans votre extension : elle est dans le moteur qui les exécute. Laravel, Drupal, Symfony, PrestaShop, une API maison en PHP : même situation.
Tous les modes d’exécution sont touchés (PHP-FPM, php-cgi, FrankenPHP, LiteSpeed). Le projet PHP considère Apache avec mod_php comme le cas le plus exposé : c’est d’ailleurs sur ce type d’installation qu’une exécution de code réelle a été confirmée sur des pots de miel le 24 octobre 2026.
La faille est-elle déjà exploitée ?
Oui. Amazon Threat Intelligence a relevé des tentatives dès le 17 octobre, quatre jours avant le correctif. watchTowr observe des attaques sur ses pots de miel depuis le 21 octobre. Une exécution de code complète a été documentée le 24 octobre sur une installation Apache mod_php en PHP 8.4.26, et selon watchTowr, la CISA a ajouté CVE-2026-109618 à son catalogue des failles exploitées le 26 octobre.
Une troisième faille, CVE-2026-115560, n’a pas encore de correctif. Elle ne concerne que des combinaisons rares de configuration et de code applicatif ; en attendant, le projet PHP recommande de désactiver `session.upload_progress.enabled`.
Que faire dès aujourd’hui ?
Mettre PHP à jour vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 selon votre branche, puis redémarrer tous les processus PHP : un worker qui tourne garde l’ancien code. Le projet PHP est clair : aucun réglage de configuration ne referme complètement ces failles.
PHP 7.4, 8.0 et 8.1 ne reçoivent que des correctifs source minimaux ou ceux de votre distribution. PHP 7.3 et versions antérieures, PHP 5 compris, restent vulnérables sans correctif : c’est le moment de migrer.
Inventoriez en priorité ce qui est exposé à Internet et ce qui tourne en mod_php. Les serveurs oubliés (préproduction, ancien site vitrine, outil interne publié) sont ceux qui seront compromis en premier.
Qui est concerné ?
- PHP 8.2 avant 8.2.35, 8.3 avant 8.3.36, 8.4 avant 8.4.27, 8.5 avant 8.5.12
- PHP 7.4, 8.0 et 8.1 : toutes versions, correctifs source ou distribution uniquement
- PHP 7.3 et antérieures, PHP 5 compris : vulnérables, aucun correctif
- Tous les modes d’exécution web : mod_php (le plus exposé), PHP-FPM, php-cgi, FrankenPHP, LiteSpeed
- Exploitation observée depuis le 21 octobre 2026, tentatives dès le 17 octobre
Comment AtriShield bloque-t-il la faille ?
Patch virtuel (Business et Enterprise) : la faille est neutralisée à l’entrée de votre serveur, sans modifier votre application et sans attendre la fenêtre de maintenance. Des métadonnées de sécurité remontent à votre console.
- ✓Patch virtuel à l’entrée : les requêtes multipart portant le champ `PHP_SESSION_UPLOAD_PROGRESS` sont coupées avant PHP sur les routes qui n’en ont pas l’usage.
- ✓Les corps d’envoi anormaux (volume, champs répétés en masse) qui cherchent à épuiser la mémoire de PHP sont écartés avant d’atteindre le moteur.
- ✓Une seule règle protège tout ce qui tourne sur le serveur (boutique, blog, back-office, API), puisqu’elle agit avant PHP.
- ✓La mise à jour de PHP reste indispensable : aucun filtre, à l’entrée ou dans la configuration, ne remplace le correctif. Le patch virtuel couvre l’intervalle.
- ✓Les tentatives sont journalisées et remontent à votre console : vous savez si vos serveurs ont été visés, et depuis quand.
Sources
- watchTowr - PHP2Shell FAQ: CVE-2026-109618 & CVE-2026-109619 Fixes
- BleepingComputer - PHP2Shell security flaws now successfully exploited in the wild
- Akamai - Understanding PHP2Shell: Everything You Need to Know
- Qualys - PHP2Shell: Find, Mitigate, and Patch Now
Analyse publiée par Atrilya Solutions à partir de publications de sécurité publiques. Les liens ci-dessus renvoient aux sources d’origine.