Alerte sécuritéMis à jour
Faille PHP critique : si votre site tourne sous PHP, c’est maintenant qu’il faut agir.
Deux vulnérabilités baptisées PHP2Shell permettent à un attaquant d’exécuter du code sur votre serveur sans se connecter. Les sites WordPress, WooCommerce, Drupal, Joomla, Magento et Laravel sont tous exposés. Le correctif est disponible depuis le 21 octobre : nous vérifions votre installation, appliquons le correctif, puis contrôlons qu’il ne s’est rien passé entre-temps.
- Identifiants
- CVE-2026-109618, CVE-2026-109619
- Gravité
- Critique — CVSS 9.2
- Connexion requise
- Non
- Versions touchées
- PHP 5.4 à 8.5
- Corrigé dans
- 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35
- Sans correctif officiel
- PHP 8.1 et antérieures
- Exploitation
- Tentatives d’attaque signalées par Cloudflare et watchTowr
Vérification gratuite
Votre site est-il concerné ? Réponse en 10 secondes.
Saisissez votre adresse : nous lisons ce que votre serveur révèle publiquement. Ou indiquez directement votre version de PHP si vous la connaissez.
Risque
Ce que cela signifie pour une entreprise.
Votre serveur peut être pris en main
Exécution de code sans connexion : un attaquant peut installer un logiciel malveillant, envoyer du spam, rediriger vos visiteurs ou voler des données de carte sur la page de paiement de votre boutique.
La mémoire du serveur peut être lue
Même sans exécuter de code, la faille peut faire fuiter la mémoire du serveur — mots de passe, clés d’API, jetons de session — que votre site ait une connexion ou non.
La responsabilité RGPD est la vôtre
En cas de fuite de données personnelles, le RGPD impose en général de la notifier à l’autorité de protection des données sous 72 heures. Une mise à jour coûte bien moins cher.
Qui est concerné
Quelle version de PHP utilisez-vous ?
Toute installation PHP qui sert des pages web est concernée : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. mod_php présente le risque le plus élevé.
8.5.12, 8.4.27, 8.3.36, 8.2.35 ou plus récent
Corrigé
Rien à faire côté PHP — vérifiez que chaque serveur et sous-domaine l’utilise.
8.2 – 8.5, version corrective antérieure
Vulnérable
Mise à jour vers la version corrigée de votre branche. Attention : la 8.2 arrive en fin de vie le 31 décembre 2026.
7.4 – 8.1
Vulnérable, sans version officielle
Passage à 8.3 ou 8.4, ou paquet corrigé de l’hébergeur ou de la distribution. PHP n’a publié qu’un correctif au niveau du code source.
5.4 – 7.3
Vulnérable, aucun correctif
Migration urgente vers une version maintenue ; d’ici là, protection temporaire ou mode maintenance.
Shopify, Wix, Shoprenter, Unas
Responsabilité du fournisseur
Ils exploitent et corrigent leurs serveurs. Les modules sur mesure ou vos propres serveurs à côté peuvent rester exposés.
| Votre PHP | Statut | Que faire |
|---|---|---|
| 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou plus récent | Corrigé | Rien à faire côté PHP — vérifiez que chaque serveur et sous-domaine l’utilise. |
| 8.2 – 8.5, version corrective antérieure | Vulnérable | Mise à jour vers la version corrigée de votre branche. Attention : la 8.2 arrive en fin de vie le 31 décembre 2026. |
| 7.4 – 8.1 | Vulnérable, sans version officielle | Passage à 8.3 ou 8.4, ou paquet corrigé de l’hébergeur ou de la distribution. PHP n’a publié qu’un correctif au niveau du code source. |
| 5.4 – 7.3 | Vulnérable, aucun correctif | Migration urgente vers une version maintenue ; d’ici là, protection temporaire ou mode maintenance. |
| Shopify, Wix, Shoprenter, Unas | Responsabilité du fournisseur | Ils exploitent et corrigent leurs serveurs. Les modules sur mesure ou vos propres serveurs à côté peuvent rester exposés. |
Ce que nous faisons
Ce que nous faisons, dès aujourd’hui.
Une seule équipe responsable, de la première vérification au rapport écrit — vous n’avez pas à démêler quel conseil s’applique à votre installation.
- 01
Inventaire
Nous repérons chaque endroit où PHP tourne : site en production, sous-domaines de test ou oubliés, conteneurs, interfaces d’administration. Nous vérifions la version dans le contexte web, pas seulement en ligne de commande.
- 02
Correction
Nous mettons PHP à jour ou nous coordonnons avec votre hébergeur. Sur un vieux PHP (7.4–8.1), nous migrons vers 8.3 ou 8.4 et testons que vos extensions et votre thème fonctionnent toujours.
- 03
Protection temporaire
Si la mise à jour ne peut pas être immédiate, nous réduisons la surface d’attaque avec les réglages provisoires officiels et un filtrage des requêtes — en sachant qu’ils ne remplacent pas le correctif.
- 04
Contrôles a posteriori
Nous examinons les journaux à la recherche des traces connues, vérifions les comptes administrateurs et les fichiers modifiés, et changeons si besoin mots de passe, clés d’API et clés de sécurité WordPress.
- 05
Rapport écrit
Ce que nous avons trouvé, corrigé, et le risque qui subsiste. Un document à remettre à votre direction ou à votre assureur.
Protection temporaire
Impossible de mettre à jour aujourd’hui ? En attendant, faites ceci.
Les réglages provisoires de l’avis de sécurité PHP. Ils réduisent l’exposition mais, selon PHP lui-même, ne rendent pas une installation sûre.
memory_limit = -1Via php_admin_value, pour que l’application ne puisse pas le surcharger (CVE-2026-109618).
post_max_size = 8MGardez une valeur basse ; 32M maximum si vous avez besoin d’envois de fichiers.
session.upload_progress.enabled = 0CVE-2026-109619.
fatal_error_backtraces = 0PHP 8.5 uniquement.
Redémarrez ensuite tous les processus PHP (PHP-FPM, Apache).
- Avec memory_limit = -1, une seule requête peut consommer toute la mémoire du serveur : surveillez-la.
- Le mode maintenance de WordPress ou de la boutique ne protège pas : PHP traite la requête avant que l’application ne vérifie le mode.
- Les règles WAF de Cloudflare n’aident que si votre serveur n’accepte que le trafic de Cloudflare.
- N’installez pas d’extension « correctif » inconnue ni de code copié-collé.
Signaux d’alerte
Signes que votre serveur a pu être visé.
- Requêtes multipart (type envoi de fichier) inhabituelles suivies d’erreurs de limite mémoire
- Erreurs HTTP 500 répétées
- Cookies PHPSESSID anormalement longs ou malformés
- Redémarrages inexpliqués des processus PHP
Aucun de ces signes ne prouve une intrusion. Si vous les observez : mettez à jour, considérez le serveur comme potentiellement compromis et changez les mots de passe et clés qu’il contient.
Vos questions, nos réponses.
Qu’est-ce que PHP2Shell ?
Le nom donné à deux vulnérabilités PHP critiques, CVE-2026-109618 et CVE-2026-109619. Ce sont des erreurs de gestion mémoire dans la façon dont PHP traite les erreurs fatales, notamment le manque de mémoire : un attaquant peut exécuter du code sur le serveur, ou lire sa mémoire, sans se connecter. PHP a publié les correctifs le 21 octobre 2026.
Mon site WordPress est-il concerné ?
Oui, si votre serveur fait tourner un PHP non corrigé entre 5.4 et 8.5 — quelles que soient votre version de WordPress et vos extensions. Les chercheurs ont démontré l’attaque sans connexion sur des versions récentes de WordPress, Drupal, Joomla et Magento. La faille est dans PHP, pas dans WordPress : une mise à jour de WordPress ne la corrige pas.
Je suis en hébergement mutualisé. Mon hébergeur ne s’en charge-t-il pas ?
L’hébergeur met généralement PHP à jour sur le serveur, mais sur la plupart des offres c’est vous qui choisissez la version de PHP utilisée par votre site. Si elle est en 8.1 ou antérieure, il se peut qu’aucun correctif n’existe. Vérifiez la version choisie dans votre panneau et demandez à votre hébergeur quand le correctif a été installé.
Ma boutique est sur Shopify ou Wix. Dois-je faire quelque chose ?
Les plateformes hébergées (Shopify, Wix, Shoprenter, Unas) exploitent et corrigent leurs propres serveurs : rien à faire côté PHP. Un site, un blog ou une intégration hébergés sur votre propre serveur à côté méritent en revanche une vérification.
Être derrière Cloudflare suffit-il ?
Non. Cloudflare a déployé des règles contre les attaques connues, même sur l’offre gratuite, mais c’est une solution d’attente qui ne vaut que si votre serveur n’accepte que le trafic de Cloudflare. Elle ne remplace pas la mise à jour.
Nous sommes en PHP 7.4. Que faire ?
Le projet PHP ne publie aucune version officielle pour la 8.1 et les branches antérieures (seulement un correctif au niveau du code source pour 7.4–8.1). La vraie solution est de passer à 8.3 ou 8.4. Avec d’anciennes extensions WordPress ou du code sur mesure, cela demande des tests — nous nous en chargeons.
Comment savoir si mon site a été piraté ?
Seuls les journaux et les fichiers du serveur permettent de l’affirmer. Traces typiques : erreurs de limite mémoire après des requêtes inhabituelles, nombreuses erreurs 500, cookies PHPSESSID étranges. Si le site était vulnérable avant le correctif, changer les mots de passe et clés d’API est recommandé — nous le faisons lors des contrôles a posteriori.
Combien coûte la correction ?
Nous vous donnons un prix fixe avant de toucher à quoi que ce soit. Il dépend du nombre de serveurs et des versions de PHP concernées : une mise à jour au sein d’une branche maintenue est rapide ; une migration depuis la 7.4 demande davantage de tests. Pour nos partenaires, les mises à jour de sécurité font partie de l’abonnement mensuel.
Sources
Sources.
Cette page s’appuie sur l’avis officiel de PHP et sur les publications des chercheurs. Nous la mettons à jour au fil de la situation.
N’attendez pas le premier incident.
Envoyez-nous l’adresse de votre site. Nous vous disons le jour même s’il est concerné et combien coûte la correction.