Faille PHP2Shell : guide de correction par hébergeur

Q: Mon hébergeur mutualisé a-t-il corrigé automatiquement la faille PHP ?

Chez OVHcloud (mutualisé), Infomaniak et o2switch, oui : les correctifs ont été déployés sur les plateformes mutualisées les 21 et 22 octobre 2026. Vérifiez quand même la date de compilation de PHP dans un phpinfo, et changez de version si vous êtes sur une branche obsolète.

Q: Mon site WordPress est à jour, suis-je protégé ?

Non. La faille est dans PHP, pas dans WordPress. Mettre à jour WordPress, le thème et les extensions reste indispensable, mais seule la mise à jour de PHP corrige PHP2Shell.

Q: Quelles sont les versions de PHP corrigées ?

PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026. Les hébergeurs et distributions Linux peuvent afficher d'autres numéros quand ils rétroportent le correctif.

Q: Pourquoi des sites étaient-ils « en maintenance » le 21 octobre 2026 ?

Par précaution. Entre la fuite des détails et l'installation des correctifs, de nombreux propriétaires et hébergeurs ont préféré couper l'accès public plutôt que laisser tourner un PHP vulnérable, comme le recommande le CERT-FR pour les systèmes non corrigeables rapidement.

Q: Un site PrestaShop, Joomla ou Drupal est-il concerné ?

Oui, comme tout site ou application qui fonctionne avec PHP : PrestaShop, Joomla, Drupal, Magento, Laravel, Symfony, mais aussi un webmail Roundcube ou un phpMyAdmin.

Q: J'ai un VPS, mon hébergeur va-t-il s'en occuper ?

Non, sauf contrat d'infogérance. Sur un VPS ou un serveur dédié, c'est à vous (ou à votre prestataire) de mettre à jour les paquets PHP et de redémarrer PHP-FPM ou Apache.

Le 21 octobre 2026 à 16 h (heure de Paris), le projet PHP a publié en urgence PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ces versions corrigent deux failles critiques surnommées PHP2Shell (CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10) qui permettent d’exécuter du code sur un serveur à distance, sans aucun identifiant. Les détails avaient fuité la veille, et des tentatives d’attaque ont été signalées avant même la sortie du correctif. PHP fait tourner environ 69 % des sites dont le langage serveur est identifié (cyberattaque.org) : l’affaire a vite dépassé le cercle des développeurs, jusqu’au Monde et à la RTS.

Depuis hier, deux questions reviennent en boucle chez mes clients : « Mon hébergeur s’en occupe, non ? » et « Je ne suis pas sur WordPress, je suis tranquille ? ». Les réponses courtes : pas toujours, et non.

Ce guide fait le point sur ce qui est corrigé automatiquement (et ce qui ne l’est pas), puis détaille la marche à suivre chez OVHcloud, Infomaniak, o2switch, WPServeur et sur un serveur privé (VPS ou dédié).

Dès la publication des correctifs, j’ai passé en revue le parc d’une trentaine de sites clients que je maintiens. Deux vérifications, site par site : est-ce qu’il restait des sites en PHP 7.x, ces versions qu’on oublie parce que « ça marche », et est-ce que chaque hébergeur avait réellement appliqué le correctif, pas seulement annoncé qu’il allait le faire. C’est exactement cette méthode que je détaille ci-dessous.

PHP2Shell en 30 secondes

Élément	Détail
Failles	CVE-2026-109618 (corruption mémoire après épuisement de la mémoire) et CVE-2026-109619 (données d’une requête qui survivent à la suivante)
Gravité	Critique, 9,2/10 (CVSS v4.0)
Risque	Exécution de code à distance, sans compte ni mot de passe, avec les droits du serveur web
Versions touchées	Toutes les versions de PHP qui servent des pages web, jusqu’à PHP 5.4 inclus
Versions corrigées	8.5.12, 8.4.27, 8.3.36, 8.2.35
PHP 8.1 et plus ancien	Pas de version officielle : correctif rétroporté par l’hébergeur ou la distribution, sinon migration
Exploitation	Tentatives signalées dès le 21 octobre au matin (Cloudflare) ; pas d’exploitation massive constatée avant le correctif selon Huntress, mais attaques automatisées attendues

Sources : avis de sécurité PHP (GitHub), CISA, Sansec.

Pour l’image : la faille n’est pas dans votre site, elle est dans le moteur qui le fait tourner. Un WordPress parfaitement à jour sur un PHP non corrigé reste exposé.

Pourquoi tant de sites ont été mis en maintenance le 21 octobre

Si vous avez croisé des pages « site en maintenance » mardi et mercredi, ce n’était pas une panne. Entre la fuite du 20 octobre et l’installation effective des correctifs, beaucoup d’équipes ont fait le choix le plus sûr : couper l’accès public plutôt que laisser tourner un PHP vulnérable.

C’est d’ailleurs ce que recommande le CERT-FR pour les systèmes qui ne peuvent pas être corrigés rapidement : les isoler, voire couper leur accès public (cyberattaque.org). Trois raisons rendaient ce réflexe logique :

la faille est exploitable sans identifiant, donc n’importe quel visiteur (ou robot) pouvait tenter sa chance ;
le correctif publié sert aussi de mode d’emploi : en comparant l’ancien et le nouveau code, les attaquants peuvent reconstituer l’exploit en quelques heures ;
les mesures provisoires bloquent aussi des fonctions utiles (envoi de fichiers, médiathèque WordPress, certains formulaires), autant fermer proprement le temps de mettre à jour.

Pour un site vitrine, quelques heures de maintenance coûtent peu. Pour une boutique WooCommerce ou PrestaShop, la décision est plus délicate : c’est là qu’un hébergeur réactif (ou un prestataire qui surveille ces alertes) fait la différence.

Est-ce que seuls les sites WordPress sont concernés ?

Non. PHP2Shell touche le cœur de PHP, pas un CMS. Tout ce qui tourne en PHP et répond à des requêtes web est concerné, quel que soit le mode d’exécution : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed (runZero).

Sansec a démontré l’exploitation sans authentification sur WordPress, Magento, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony et WHMCS. WooCommerce, PrestaShop et Shopware sont exposés de la même façon, même avec un code parfaitement sain.

Concrètement, pensez aussi à tout ce qu’on oublie :

le webmail (Roundcube) de votre hébergement ;
le phpMyAdmin laissé accessible ;
un vieux sous-domaine de test ou de préproduction ;
un intranet, un extranet client, un outil de facturation auto-hébergé.

Et les sites qui ne sont pas en PHP ?

Un site Astro, Next.js en export statique ou HTML pur n’exécute pas de PHP côté serveur : il n’est pas exposé à cette faille. C’est d’ailleurs l’un des arguments que je développe dans mon comparatif Astro vs WordPress et dans ma méthode de refonte WordPress vers Astro.

Attention au piège du WordPress headless : si votre front est en Astro mais que le back-office WordPress tourne sur un serveur accessible depuis Internet, ce WordPress-là reste à corriger.

Est-ce que la correction se fait automatiquement sur les serveurs ?

Ça dépend uniquement du type d’hébergement, pas de votre CMS ni de vos extensions.

Type d’hébergement	Qui corrige PHP ?	Votre action
Mutualisé (OVH, Infomaniak, o2switch…)	L’hébergeur	Vérifier, et migrer si vous êtes sur une version obsolète
Infogéré / WordPress managé (WPServeur…)	L’hébergeur	Vérifier ou demander confirmation au support
VPS ou serveur dédié non infogéré	Vous	Mettre à jour, redémarrer PHP, vérifier
Conteneurs Docker	Vous	Reconstruire les images et redéployer
Serveur géré par une agence ou un prestataire	Le prestataire	Demander une confirmation écrite

Le piège classique : beaucoup de petites structures ont un VPS en pensant avoir un hébergement « géré ». Chez OVHcloud par exemple, l’hébergeur le dit noir sur blanc : il n’intervient pas sur vos VPS et serveurs dédiés sans votre accord (blog OVHcloud). Personne ne fera la mise à jour à votre place.

Deuxième piège : une mise à jour installée n’est pas une mise à jour active. Tant que PHP-FPM ou Apache n’ont pas redémarré, l’ancienne version continue de tourner en mémoire.

Comment vérifier sa version de PHP (et pourquoi le numéro ne suffit pas)

Sur WordPress : Outils › Santé du site › Infos › Serveur. La version de PHP utilisée par le site y est affichée.

Sur n’importe quel site PHP : déposez un fichier info.php contenant <?php phpinfo(); à la racine, ouvrez-le dans le navigateur, notez la version et la date de compilation (« Build Date »), puis supprimez le fichier immédiatement.

Le numéro de version ne dit pas tout. Plusieurs hébergeurs et distributions Linux rétroportent le correctif sans changer le numéro officiel :

chez o2switch (CloudLinux), une version corrigée peut s’afficher en 8.4.26 avec un suffixe de build ;
chez Infomaniak, les branches 7.4, 8.0 et 8.1 reçoivent un correctif maison sans nouveau numéro ;
sous Debian, Ubuntu ou Red Hat, c’est le numéro du paquet qui change, pas forcément la version PHP.

Dans ces cas, la date de compilation (21 octobre 2026 ou après) ou le journal des modifications du paquet sont les vraies preuves.

Guide de correction par hébergeur

OVHcloud

Hébergement mutualisé (Web Cloud) : OVHcloud indique que ses clients mutualisés « bénéficieront automatiquement d’un composant PHP mis à jour ». L’hébergeur a aussi déployé des règles de pare-feu applicatif sur ses clusters (Clubic).

Votre part :

Vérifiez la version de PHP utilisée (Santé du site ou phpinfo).
Si votre site tourne encore en PHP 7.x ou 8.0/8.1, passez à une version maintenue. Sur le mutualisé OVH, la version se règle dans le fichier .ovhconfig à la racine de l’hébergement (ligne app.engine.version) ou depuis l’espace client Web Cloud › Hébergements.
Testez le site après le changement.

VPS et serveurs dédiés (Kimsufi, So you Start, Rise, Advance…) : rien n’est automatique. Suivez la section « Serveur privé » plus bas. OVHcloud conseille un snapshot du VPS avant la mise à jour et estime l’opération à une quinzaine de minutes par serveur.

Infomaniak

Hébergement web (mutualisé) : Infomaniak a désactivé session.upload_progress sur toute la plateforme le 21 octobre en fin d’après-midi, puis lancé le déploiement des versions corrigées pour PHP 7.4 à 8.5, avec des correctifs rétroportés pour 7.4, 8.0 et 8.1. Aucune action n’est demandée aux clients, sauf pour les sites restés sur une version non maintenue (dibodev).

Votre part :

Vérifiez la version et la date de compilation de PHP.
Pour changer de version : Manager › Hébergement › votre site › Plus d’informations › PHP › Modifier. Le réglage se fait site par site et s’applique immédiatement.
Faites le changement d’abord sur une copie du site si vous sautez plusieurs versions (7.4 vers 8.3, par exemple).

Cloud Server et VPS Infomaniak : sur un Cloud Server géré, les versions PHP sont fournies par Infomaniak ; vérifiez dans le Manager la version utilisée par chaque site. Sur un VPS non géré, c’est à vous de jouer (section « Serveur privé »).

o2switch

o2switch a désactivé session.upload_progress dès le matin du 21 octobre et redémarré les processus PHP (Clubic). L’hébergeur s’appuie sur CloudLinux, dont les paquets corrigés ont été déployés dans la nuit du 21 au 22 octobre sur toutes les versions de PHP, de 5.2 à 8.5. Aucune action n’est nécessaire de votre côté (o2switch sur X).

Votre part :

Ne vous fiez pas au numéro de version : CloudLinux recompile ses propres paquets (par exemple 8.4.26-5 ou 8.3.35-6 au lieu de 8.4.27 et 8.3.36). Les numéros de build corrigés sont listés sur changelog.cloudlinux.com, rubrique Alt-PHP Versions.
Le plus simple : dans un phpinfo, la date de compilation doit être le 21 octobre 2026 ou plus récente.
Si vous changez de version dans cPanel (Sélectionner une version de PHP), vérifiez les extensions activées : elles ne suivent pas toujours d’une version à l’autre (mbstring, gd, intl…). J’en parle dans mon guide configurer o2switch pour WordPress.

WPServeur

WPServeur est un hébergeur WordPress infogéré : la gestion de PHP fait partie du service, ce n’est pas à vous d’installer les correctifs. Au 22 octobre 2026, je n’ai pas trouvé de communication publique de WPServeur sur PHP2Shell.

Votre part :

Vérifiez la version de PHP dans Outils › Santé du site de chaque site.
Ouvrez un ticket au support avec une question précise, du type : « Pouvez-vous confirmer que les correctifs CVE-2026-109618 et CVE-2026-109619 sont appliqués et actifs sur le serveur qui héberge mon site ? »
Gardez la réponse écrite : c’est votre preuve en cas d’incident (et pour vos obligations RGPD si le site traite des données personnelles).

Serveur privé (VPS, dédié, Docker)

C’est le cas où personne ne viendra corriger à votre place. Comptez 15 minutes par serveur.

1. Sauvegardez. Snapshot du VPS, ou au minimum les fichiers de configuration et les bases de données.

2. Identifiez toutes les versions de PHP installées. Sur un serveur, il y en a souvent plusieurs.

php -v
# Debian / Ubuntu : versions installées et services FPM actifs
ls /etc/php/
systemctl list-units --type=service | grep -i fpm

3. Mettez à jour les paquets.

# Debian / Ubuntu (y compris le dépôt ondrej/php)
sudo apt update && sudo apt upgrade

# AlmaLinux / Rocky Linux / RHEL
sudo dnf upgrade

Si PHP est compilé depuis les sources, récupérez la version corrigée sur php.net. Note : le dépôt Remi (très utilisé sur les serveurs Red Hat) ne proposait pas encore le correctif le 21 octobre (Sansec), revérifiez.

4. Redémarrez PHP. L’étape la plus souvent oubliée.

# PHP-FPM (remplacez 8.3 par votre version, à faire pour chaque version active)
sudo systemctl restart php8.3-fpm
# Apache (mod_php)
sudo systemctl restart apache2     # Debian / Ubuntu
sudo systemctl restart httpd       # RHEL / Alma / Rocky

Pensez aussi aux processus PHP persistants : workers de files d’attente (Laravel, Symfony Messenger), FrankenPHP en mode worker, tâches lancées par Supervisor. Ils gardent l’ancien PHP en mémoire tant qu’ils ne sont pas relancés.

5. Vérifiez que le correctif est bien là.

# Debian / Ubuntu
apt changelog php8.3-fpm | grep -E "CVE-2026-10961(8|9)"
# RHEL / Alma / Rocky
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961(8|9)"

Puis contrôlez la version et la date de compilation via un phpinfo temporaire (à supprimer ensuite).

Docker : reconstruisez vos images sur une image PHP à jour et redéployez.

docker compose build --pull && docker compose up -d

Plesk / cPanel sur votre serveur : les versions PHP fournies par le panneau se mettent à jour via les mises à jour du panneau lui-même. Lancez-les, puis vérifiez chaque version utilisée par vos sites.

Vous ne pouvez pas mettre à jour tout de suite ?

Le projet PHP est clair : seule la mise à jour protège complètement. En attendant, ces réglages réduisent le risque (php.ini, puis redémarrage de PHP) :

; Fichier dédié, ex. /etc/php/8.3/fpm/conf.d/99-php2shell.ini
session.upload_progress.enabled = Off
; PHP 8.5 uniquement
fatal_error_backtraces = 0
; Si le site n'a pas besoin d'envoi de fichiers lourds
post_max_size = 8M

Où placer le réglage compte : dans le php.ini du serveur ou via php_admin_flag dans le pool PHP-FPM. Un ini_set() dans le code ou un fichier .user.ini ne suffit pas. Sur un mutualisé, c’est donc à l’hébergeur de l’appliquer.
Si votre application n’utilise aucun formulaire avec envoi de fichiers, bloquez les requêtes multipart/form-data au niveau du serveur web ou du proxy.
Un pare-feu applicatif (Cloudflare, y compris l’offre gratuite, a mis à jour ses règles le 21 octobre) ajoute une couche, sans remplacer le correctif.
PHP évoque aussi memory_limit = -1 contre la première faille. À manier avec prudence : une seule requête peut alors consommer toute la mémoire du serveur.

Et non, une extension de sécurité WordPress ne protège pas contre PHP2Shell : elle s’exécute dans PHP, après la zone où se trouve la faille.

Après la correction : vérifier qu’on n’a pas été touché

Point important : une mise à jour ne prouve pas que le serveur n’était pas déjà compromis. Elle ferme la porte, elle ne vérifie pas si quelqu’un est entré. Sur un site resté exposé plusieurs heures, je recommande :

Changer les secrets : mots de passe administrateurs, accès base de données, clés d’API, et les clés de sécurité de wp-config.php sur WordPress. La seconde faille peut faire fuiter des données de la mémoire du serveur.
Contrôler les fichiers modifiés depuis le 21 octobre (fichiers PHP inconnus dans uploads, mu-plugins, à la racine).
Lire les journaux : pics de requêtes multipart/form-data, pics de consommation mémoire, processus PHP inhabituels.
Lister les comptes administrateurs : sur WordPress, Utilisateurs › Administrateurs ; tout compte créé depuis le 20 octobre doit être expliqué.
Lancer un scan de malwares sur l’ensemble de l’hébergement.

Si vous trouvez quelque chose de suspect, ne restaurez pas une sauvegarde à l’aveugle : j’explique pourquoi dans mon retour d’expérience sur le piratage WordPress.

Et si vous êtes encore en PHP 8.1 ou plus ancien ?

C’est le vrai sujet de fond. Ces versions ne sont plus maintenues par le projet PHP : vous dépendez entièrement du bon vouloir de votre hébergeur. Cette fois, la plupart ont rétroporté le correctif. La prochaine fois, rien ne le garantit.

Visez PHP 8.3 ou plus récent. La branche 8.2 ne sera plus corrigée après le 31 décembre 2026 : y migrer maintenant, c’est recommencer dans deux mois. Pour WordPress, mon guide de migration vers PHP 8.5 détaille la méthode (copie de test, extensions, thème, journal d’erreurs).

FAQ : faille PHP2Shell

Mon hébergeur mutualisé a-t-il corrigé automatiquement la faille PHP ?

Chez OVHcloud (mutualisé), Infomaniak et o2switch, oui : les correctifs ont été déployés sur les plateformes mutualisées les 21 et 22 octobre 2026. Vérifiez quand même la date de compilation de PHP dans un phpinfo, et changez de version si vous êtes sur une branche obsolète.

Mon site WordPress est à jour, suis-je protégé ?

Non. La faille est dans PHP, pas dans WordPress. Mettre à jour WordPress, le thème et les extensions reste indispensable, mais seule la mise à jour de PHP corrige PHP2Shell.

Quelles sont les versions de PHP corrigées ?

PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026. Les hébergeurs et distributions Linux peuvent afficher d’autres numéros quand ils rétroportent le correctif.

Pourquoi des sites étaient-ils « en maintenance » le 21 octobre 2026 ?

Par précaution. Entre la fuite des détails et l’installation des correctifs, de nombreux propriétaires et hébergeurs ont préféré couper l’accès public plutôt que laisser tourner un PHP vulnérable, comme le recommande le CERT-FR pour les systèmes non corrigeables rapidement.

Un site PrestaShop, Joomla ou Drupal est-il concerné ?

Oui, comme tout site ou application qui fonctionne avec PHP : PrestaShop, Joomla, Drupal, Magento, Laravel, Symfony, mais aussi un webmail Roundcube ou un phpMyAdmin.

J’ai un VPS, mon hébergeur va-t-il s’en occuper ?

Non, sauf contrat d’infogérance. Sur un VPS ou un serveur dédié, c’est à vous (ou à votre prestataire) de mettre à jour les paquets PHP et de redémarrer PHP-FPM ou Apache.

Besoin d’un coup de main ?

Je vérifie et corrige PHP2Shell sur vos sites et serveurs : contrôle de version réel, mise à jour, redémarrage, puis recherche de traces de compromission. Pour les sites déjà sous contrat de maintenance, c’est inclus.

👉 Demander une vérification de mon site

Faille PHP2Shell (octobre 2026) : guide de correction par hébergeur

PHP2Shell en 30 secondes

Pourquoi tant de sites ont été mis en maintenance le 21 octobre

Est-ce que seuls les sites WordPress sont concernés ?

Et les sites qui ne sont pas en PHP ?

Est-ce que la correction se fait automatiquement sur les serveurs ?

Comment vérifier sa version de PHP (et pourquoi le numéro ne suffit pas)

Guide de correction par hébergeur

OVHcloud

Infomaniak

o2switch

WPServeur

Serveur privé (VPS, dédié, Docker)

Vous ne pouvez pas mettre à jour tout de suite ?

Après la correction : vérifier qu’on n’a pas été touché

Et si vous êtes encore en PHP 8.1 ou plus ancien ?

FAQ : faille PHP2Shell

Mon hébergeur mutualisé a-t-il corrigé automatiquement la faille PHP ?

Mon site WordPress est à jour, suis-je protégé ?

Quelles sont les versions de PHP corrigées ?

Pourquoi des sites étaient-ils « en maintenance » le 21 octobre 2026 ?

Un site PrestaShop, Joomla ou Drupal est-il concerné ?

J’ai un VPS, mon hébergeur va-t-il s’en occuper ?

Besoin d’un coup de main ?

À lire aussi sur le blog Digitalcorner