PHP2Shell : les failles de sécurité PHP qui ont provoqué des mises hors ligne

Des sites devenus inaccessibles, des services suspendus et des administrateurs mobilisés en urgence : PHP2Shell a déclenché une importante opération de sécurisation du web. Derrière ce nom se trouvent deux failles de sécurité critiques dans PHP, référencées CVE-2026-109618 et CVE-2026-109619.

Notées 9,2 sur 10 selon CVSS v4.0, elles peuvent permettre une exécution de code à distance sans authentification. Le problème concerne le moteur PHP lui-même. Un site correctement développé peut donc être exposé si son serveur utilise une version vulnérable. Des correctifs sont disponibles depuis le 21 octobre 2026 : leur déploiement constitue la priorité.

Pourquoi des sites web ont-ils été mis hors ligne soudainement ?

Les interruptions ne signifient pas automatiquement que les sites ont été piratés. Face à PHP2Shell, des administrateurs ont suspendu leurs services pour réduire l’exposition pendant la préparation et l’installation des correctifs. Le Monde rapporte ces mises en maintenance préventives.

Cette décision correspond aux recommandations du CERT-EU sur PHP2Shell : corriger immédiatement les installations concernées et, lorsque cela reste impossible, envisager leur isolement des réseaux publics jusqu’à vérification du correctif.

Certaines restrictions ont également ciblé des fonctionnalités. Sur sa page officielle de suivi des services, Infomaniak a notamment annoncé des limitations temporaires des transferts de fichiers. Une interruption peut ainsi relever d’une mesure de protection décidée par le prestataire, plutôt que d’une panne provoquée par un attaquant.

Pourquoi la publication des correctifs a-t-elle été accélérée ?

La PHP Foundation explique la chronologie de PHP2Shell : les identifiants des vulnérabilités ont commencé à circuler le 20 octobre, avant la divulgation coordonnée. Le projet a alors avancé la publication initialement prévue le 22 octobre au 21 octobre.

Une vidéo de démonstration publiée par erreur a également circulé. Cette succession d’événements a réduit le temps disponible pour préparer les déploiements. Les équipes devaient rendre les correctifs accessibles tout en permettant aux distributeurs de finaliser leurs paquets. Ce calendrier explique la concentration des interventions et des mesures préventives sur une période aussi courte.

PHP2Shell : que permettent réellement ces vulnérabilités ?

Une RCE, pour « Remote Code Execution », permet d’exécuter des instructions sur un serveur distant. Dans les scénarios concernés, l’attaquant n’a pas besoin de disposer préalablement d’un compte administrateur ni de connaître un mot de passe.

Les conséquences dépendent des droits du processus PHP et de l’environnement. Elles peuvent inclure la modification du site, l’accès à des données sensibles ou l’installation d’un accès persistant non autorisé. Cela ne signifie pas automatiquement l’obtention des privilèges maximaux sur toute l’infrastructure.

Les recherches publiées par Wiz sur PHP2Shell décrivent également des possibilités de lecture de la mémoire des processus. Cette mémoire peut contenir des secrets, comme des jetons d’authentification ou des clés API. La confidentialité des données constitue donc un enjeu majeur.

Comment fonctionnent les deux failles PHP2Shell ?

CVE-2026-109618 : une corruption mémoire lors d’une erreur OOM

La première vulnérabilité concerne la gestion des erreurs Out of Memory, ou OOM. Lorsqu’une allocation mémoire échoue, PHP peut interrompre une opération alors que certaines structures internes ne sont pas entièrement initialisées.

Le nettoyage de la requête risque ensuite de considérer ces données invalides comme utilisables. Cette incohérence peut conduire à une corruption mémoire, puis à une exécution de code dans certaines conditions.

L’avis technique de CVE-2026-109618 précise qu’une exploitation a été démontrée avec Apache et mod_php, avant même l’exécution du code applicatif. Une protection ajoutée uniquement dans le site ne suffit donc pas à traiter ce scénario.

CVE-2026-109619 : un état interne réutilisé après libération

La seconde vulnérabilité concerne des informations internes qui restent référencées alors que la mémoire correspondante a été libérée.

Un processus PHP peut traiter plusieurs requêtes successives. Si une requête laisse un état incohérent, une opération exécutée lors d’une requête suivante peut réutiliser cet état avant sa réinitialisation. Ce mécanisme relève d’un problème de use-after-free, ou utilisation après libération.

L’avis officiel de CVE-2026-109619 décrit plusieurs chemins possibles. Les conditions d’exploitation varient selon les versions, la configuration et les opérations atteignables. Toutes les installations ne présentent donc pas exactement le même scénario d’attaque.

Quels sites et hébergements sont concernés ?

Le périmètre dépasse un CMS particulier. WordPress, Drupal, Joomla, les applications métier et les développements sur mesure peuvent être concernés lorsqu’ils reposent sur un interpréteur PHP vulnérable.

Wiz a démontré des exploitations sur plusieurs CMS, mais souligne que les défauts se trouvent dans PHP. Une application très simple peut également être exposée : la qualité de son code ne corrige pas une vulnérabilité du moteur.

L’alerte officielle du projet PHP inclut PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé particulièrement élevé avec mod_php. Utiliser PHP-FPM ne constitue toutefois pas une preuve de protection : les installations concernées doivent recevoir les correctifs.

« 70 % du web » : un chiffre à comprendre correctement

Au 22 octobre 2026, les statistiques de W3Techs sur PHP indiquent une utilisation par 69,3 % des sites dont le langage côté serveur est identifié.

Ce chiffre décrit l’adoption de PHP. Il ne mesure ni le pourcentage de sites effectivement piratés, ni celui des installations encore vulnérables après les mises à jour. L’exposition réelle dépend notamment de la version déployée et des correctifs appliqués.

Quelles versions PHP corrigent PHP2Shell ?

Les versions suivantes intègrent les corrections officielles publiées le 21 octobre 2026.

Un fournisseur Linux peut rétroporter les corrections dans ses paquets. Dans ce cas, contrôlez son bulletin de sécurité et la révision installée : le numéro PHP affiché ne suffit pas toujours à déterminer si le correctif est présent.

Pour PHP 8.1 et les branches antérieures, privilégiez une migration vers une version supportée. Des fournisseurs proposent des rétroportages ; le projet PHP a également publié des correctifs sources minimaux exceptionnels pour PHP 7.4, 8.0 et 8.1. Cela ne rétablit pas leur maintenance habituelle.

Comment protéger son site contre PHP2Shell ?

La démarche commence par un inventaire précis. Le NCSC recommande d’identifier les installations PHP dans toute l’infrastructure, en donnant la priorité aux services exposés à Internet.

1. Identifier les versions actives. Vérifiez chaque site, serveur, conteneur et environnement accessible. La version utilisée en ligne de commande peut différer de celle exécutant les requêtes web.

2. Contacter le responsable de l’hébergement. Demandez une confirmation explicite de la correction des deux CVE. Sur un serveur administré directement, organisez vous-même le déploiement avec votre prestataire technique.

3. Préparer et appliquer la mise à jour. Conservez les sauvegardes utiles sans retarder une mise en sécurité urgente. Vérifiez la compatibilité des fonctions essentielles et déployez le paquet corrigé.

4. Valider la protection effective. Redémarrez les processus concernés, contrôlez la version réellement chargée et testez les parcours utilisateurs avant de rétablir les accès suspendus.

Cloudflare et un WAF suffisent-ils ?

Un pare-feu applicatif web, ou WAF, peut réduire l’exposition à certains chemins d’exploitation. Cloudflare indique avoir déployé des protections contre PHP2Shell, tout en demandant aux clients de corriger PHP.

Ces protections restent complémentaires. Leur couverture dépend notamment du trafic effectivement filtré et des variantes d’attaque. Un serveur d’origine accessible directement peut également contourner la protection attendue.

Ne considérez donc pas une règle WAF comme une correction du moteur. Si la mise à jour immédiate est impossible, évaluez l’isolement du service avec l’administrateur, conformément aux recommandations des autorités.

Faut-il rechercher une éventuelle compromission ?

Oui, particulièrement lorsque le serveur est resté exposé. Amazon Threat Intelligence rapporte des tentatives liées à PHP2Shell observées dès le 17 octobre 2026 sur ses capteurs. Cette observation ne démontre pas que chaque tentative aurait réussi contre un serveur réel.

Examinez les journaux disponibles, les modifications inhabituelles de fichiers et les exécutions inattendues de processus. Conservez les éléments utiles à l’investigation.

Une mise à jour ne supprime pas nécessairement une compromission antérieure. Si des indices sont confirmés, prévoyez une restauration depuis un environnement sain et le renouvellement des secrets exposés.

FAQ sur les failles PHP2Shell

Mettre WordPress à jour corrige-t-il PHP2Shell ?

Non. La correction concerne l’interpréteur PHP du serveur. Mettre à jour WordPress, un thème ou une extension ne remplace pas cette intervention. Demandez à votre hébergeur quelle version corrigée fonctionne réellement.

Mon site fonctionne normalement : est-il protégé ?

Pas nécessairement. Une vulnérabilité peut exister sans symptôme visible. Le fonctionnement normal du site ne prouve ni l’installation des correctifs ni l’absence d’une compromission discrète.

Faut-il fermer tous les sites utilisant PHP ?

Non. La décision dépend de l’exposition et de la possibilité de corriger immédiatement. L’isolement vise les services vulnérables qui ne peuvent pas être sécurisés sans délai ; un environnement corrigé et vérifié peut fonctionner.

Augmenter la mémoire PHP résout-il le problème ?

Non. Modifier memory_limit ne constitue pas une correction complète de PHP2Shell. Les atténuations documentées ne couvrent que certains chemins d’exploitation et doivent être évaluées techniquement. La mise à jour reste indispensable.