Faille PHP2Shell : sécurisez vos serveurs PHPavant qu'ils ne soient exploités
Mis à jour le
Deux vulnérabilités critiques de PHP (CVE-2026-109618 et CVE-2026-109619, surnommées « PHP2Shell ») permettent d'exécuter du code à distance sans authentification sur un serveur qui sert des requêtes web. Les correctifs sont sortis le 21 octobre 2026 et des tentatives d'exploitation sont observées depuis le même jour. Intranets, extranets, applications métier, e-commerce : si vos serveurs exécutent PHP, nous les inventorions, appliquons les atténuations sans attendre, planifions la montée de version et vérifions qu'ils n'ont pas déjà été compromis.
Inventaire et atténuations d'abord, montée de version planifiée ensuite.
Une faille dans PHP lui-même, exploitée dès la sortie des correctifs
Deux failles, notées 9,2 sur 10
CVE-2026-109618 : corruption mémoire lors d'un dépassement de mémoire. CVE-2026-109619 : use-after-free, fuite mémoire confirmée. CVSS v4.0 de 9,2 chacune, exécution de code à distance sans authentification.
L'interpréteur, pas seulement les CMS
PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed : toute installation qui sert des requêtes web est exposée, avec un risque maximal sous mod_php. Votre code métier ne vous protège pas.
Une exploitation déjà en cours
CVE fuitées le 20 octobre, correctifs publiés le 21, tentatives d'exploitation observées dès le 21 (Cloudflare, watchTowr). Exécution de code confirmée sur certaines versions de WordPress, Drupal, Joomla et Magento.
Un numéro de version trompeur
Les distributions Linux ont souvent intégré le correctif sans changer le numéro affiché. Un serveur peut sembler vulnérable et être corrigé, ou l'inverse : seul un contrôle paquet par paquet tranche.
PHP 5.4 à 8.5 sont touchées. Où en est votre branche ?
Rappel : sur une distribution Linux, le correctif peut être présent sans que le numéro de version change. Ce tableau vaut pour les versions officielles de PHP.
| Branche | Statut |
|---|---|
| PHP 8.5 | Corrigée en 8.5.12 |
| PHP 8.4 | Corrigée en 8.4.27 |
| PHP 8.3 | Corrigée en 8.3.36 |
| PHP 8.2 | Corrigée en 8.2.35, fin du support sécurité le 31/12/2026 |
| PHP 7.4 à 8.1 | Correctifs source uniquement, à recompiler ou via la distribution |
| PHP 5.4 à 7.3 | Aucun correctif : isoler puis migrer |
Les serveurs PHP que personne ne regarde plus
Le site vitrine se met souvent à jour tout seul chez son hébergeur. Ce sont les serveurs gérés en interne ou par un ancien prestataire qui posent problème :
Intranets et extranets
Portails clients, espaces fournisseurs, outils RH ou documentaires : souvent anciens, rarement mis à jour, et exposés sur internet pour être accessibles à distance.
Applications métier
Logiciels développés en interne ou par un prestataire, frameworks Symfony ou Laravel, vieilles applications maintenues sur une version de PHP figée pour ne rien casser.
E-commerce
Magento, PrestaShop, WooCommerce : des serveurs qui manipulent des comptes clients et des paiements, cibles prioritaires d'une exécution de code à distance.
Éditeurs et SaaS
Une plateforme hébergée pour vos clients, ou un logiciel livré avec PHP : vos clients vont vous poser la question, et le Cyber Resilience Act encadre déjà le signalement des failles exploitées.
Éditeur de logiciel ? Voyez aussi ce que le Cyber Resilience Act exige en matière de signalement. Vous n'avez qu'un site vitrine ou une petite boutique en ligne ? Un test de sécurité de site web suffit souvent pour faire le point.
Inventorier, atténuer, corriger, vérifier
Nous administrons des serveurs PHP en production depuis des années : nous savons ce qu'une montée de version peut casser, et comment la préparer. Vos équipes gardent la main, nous travaillons avec elles ou à leur place selon vos moyens.
Inventorier
Chaque serveur, conteneur et version de PHP qui sert du web : branche, paquet, mode d'exécution (FPM, mod_php, CGI), exposition à internet. On sait enfin ce qui est vulnérable.
Atténuer sans attendre
Sur les serveurs vulnérables, dès le premier jour : memory_limit=-1 imposé côté serveur, session.upload_progress désactivé, fatal_error_backtraces à 0 en 8.5, redémarrage des workers. Isolement des applications sans correctif.
Mettre à jour et tester
Montée vers la version corrigée, ou vers une branche supportée si vous êtes en 8.2 ou avant : tests de compatibilité sur une copie, fenêtre de bascule convenue avec vous, retour arrière préparé.
Vérifier l'absence de compromission
Journaux depuis le 20 octobre, fichiers PHP ajoutés ou modifiés, tâches planifiées, comptes, connexions sortantes. Un rapport écrit de ce qui a été vu, corrigé et ce qui reste à faire.
Une règle de pare-feu applicatif (WAF Cloudflare ou autre) réduit l'exposition le temps de l'intervention, mais ne remplace pas la mise à jour. Le CERT-EU (avis 2026-018) recommande d'envisager l'isolement des applications exposées tant que la correction n'est pas vérifiée : c'est ce que nous faisons pour les serveurs qui ne peuvent pas être mis à jour rapidement.
Des signes d'intrusion sur un serveur ?
Fichiers inconnus, tâches planifiées suspectes, trafic sortant anormal, serveur qui rame sans raison : ne vous contentez pas de mettre PHP à jour. Il faut contenir, chercher ce que l'attaquant a fait et reconstruire proprement.
PHP2Shell en clair
Qu'est-ce que la faille PHP2Shell ?
C'est le surnom donné à deux vulnérabilités de l'interpréteur PHP : CVE-2026-109618, une corruption mémoire déclenchée lors d'un dépassement de mémoire, et CVE-2026-109619, un use-after-free dont la fuite mémoire est confirmée. Chacune est notée 9,2 en CVSS v4.0 et permet une exécution de code à distance sans authentification. Les CVE ont fuité le 20 octobre 2026, les correctifs ont été publiés le 21, et des tentatives d'exploitation sont observées depuis ce même jour.
Quelles versions de PHP sont touchées ?
Toutes les branches de PHP 5.4 à 8.5. Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour PHP 7.4 à 8.1, il n'existe que des correctifs au niveau du code source, à recompiler ou à obtenir via votre distribution. Pour PHP 5.4 à 7.3, aucun correctif n'est publié : ces serveurs doivent être isolés puis migrés.
Comment savoir si mon serveur est vulnérable ?
Le numéro affiché par php -v ne suffit pas. Les distributions Linux ont reçu les correctifs en avance et les ont souvent intégrés sans changer le numéro de version visible : il faut vérifier le paquet installé et son historique de correctifs. À l'inverse, une image Docker, un PHP compilé à la main ou une seconde version installée pour une vieille application peuvent rester vulnérables sur un serveur que l'on croyait à jour. C'est pourquoi notre intervention commence par un inventaire, serveur par serveur.
Quels serveurs sont concernés ?
Toute installation PHP qui sert des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Le risque est maximal avec mod_php. Une exécution de code a été confirmée sur certaines versions de WordPress, Drupal, Joomla et Magento, mais une application métier développée en interne n'est pas à l'abri pour autant : c'est l'interpréteur qui est vulnérable, pas seulement les CMS.
Peut-on se protéger sans mettre à jour PHP tout de suite ?
Temporairement, oui, et c'est ce que nous faisons en premier : imposer memory_limit=-1 côté serveur, désactiver session.upload_progress.enabled, mettre fatal_error_backtraces à 0 en PHP 8.5, puis redémarrer les workers pour que la configuration soit prise en compte. Ces réglages ont un coût (sans plafond mémoire, un script gourmand peut peser sur le serveur) et ne sont qu'une rustine, comme une règle de WAF Cloudflare. La seule vraie correction reste la mise à jour de PHP.
Mon hébergeur ne s'en occupe-t-il pas ?
Cela dépend du contrat. Sur un hébergement mutualisé ou une offre infogérée, l'hébergeur met généralement PHP à jour : demandez-lui une confirmation écrite. Sur un serveur virtuel, un serveur dédié ou une instance cloud, la mise à jour de PHP est de votre responsabilité, même si la machine est chez OVHcloud, Scaleway ou AWS.
Comment savoir si nous avons déjà été compromis ?
En cherchant les traces d'une exploitation depuis le 20 octobre : requêtes anormales dans les journaux, fichiers PHP apparus ou modifiés (webshells), tâches planifiées ou comptes ajoutés, connexions sortantes inhabituelles. Une mise à jour ferme la porte mais ne retire pas un attaquant déjà entré. Si des indices apparaissent, l'intervention bascule en réponse à incident.
Je suis encore en PHP 8.2 ou en PHP 7 : que faire ?
PHP 8.2 est corrigé (8.2.35), mais n'aura plus de support de sécurité après le 31 décembre 2026 : c'est le moment de planifier le passage en 8.3 ou au-delà. En PHP 7.4 à 8.1, seuls des correctifs source existent ; en dessous, rien. Dans ces deux cas nous isolons l'application exposée, comme le recommande l'avis 2026-018 du CERT-EU, et construisons avec vous le plan de migration et de tests de compatibilité.
Dites-nous combien de serveurs PHP vous exploitez
Nombre de serveurs, versions de PHP si vous les connaissez, applications concernées, hébergement : avec ces éléments, nous vous proposons un plan d'intervention en commençant par les serveurs les plus exposés.