Ce que vous risquez
PHP fait tourner la plupart des sites de commerçants, de WordPress à PrestaShop. Avec PHP2Shell, voici ce qu'une version non corrigée laisse à portée d'un pirate :
La prise de contrôle de votre serveur
Une faille qui permet d'exécuter des commandes sur votre serveur à distance, sans aucun mot de passe : le pirate y fait ce qu'il veut, y compris y laisser une porte dérobée.
Le vol de votre base clients
Noms, e-mails, adresses, historiques de commandes, mots de passe : tout ce que lit votre site, le pirate peut le lire et l'emporter.
Des paiements détournés
Si votre site encaisse en ligne, une faille qui permet d'insérer un faux formulaire de paiement et de capter les numéros de carte de vos clients.
Un site bloqué ou suspendu
Un site piraté qui diffuse des pages malveillantes peut être signalé comme dangereux par Google, ou suspendu par l'hébergeur s'il envoie du spam ou attaque d'autres serveurs.
Une notification à la CNIL sous 72 h
Si des données personnelles ont fuité, le RGPD impose en principe de notifier la CNIL dans les 72 heures, et parfois d'informer les personnes concernées.
12 sur 13
Le soir de la publication du correctif, nous avons contrôlé 13 serveurs PHP en production : 12 étaient encore vulnérables, dont 2 sur des versions de PHP qui ne recevront jamais de correctif. Mettre à jour un site ne met pas à jour le PHP qui le fait tourner.
Contrôle PHP2Shell
149 € HT
Intervention sous 24 à 48 h ouvrées
- Vérification de la version de PHP qui sert réellement le site (pas seulement php -v) et de la présence du correctif de votre distribution
- Pose des atténuations côté serveur quand c'est possible (dont session.upload_progress.enabled=0), testées avant activation
- Recherche de signes d'intrusion : fichiers PHP récents ou inconnus, comptes administrateurs ajoutés, tâches planifiées
- Rapport écrit avec la conclusion et le plan d'action
- Nouveau bilan de sécurité remis avec le rapport (scan relancé après intervention)
Non inclus : la montée de version de PHP. Elle est testée sur une copie de votre site et fait l'objet d'un devis séparé, validé par vous.
En hébergement mutualisé, sans accès au serveur, le contrôle porte sur ce qui est accessible (espace client, fichiers du site) et nous vous accompagnons auprès de votre hébergeur.
Vérifiez vous-même (si vous avez accès au serveur)
Sur Debian ou Ubuntu : le correctif est-il installé ?
Connectez-vous en SSH et lancez :
dpkg -l 'php*-common' | grep ^ii
zgrep -l 'CVE-2026-109618' /usr/share/doc/php*-common/changelog.Debian.gzLa première commande liste les paquets PHP installés et leur version. La seconde cherche la faille dans le journal des correctifs : pas de résultat = correctif absent.
Quelle version de PHP sert vraiment votre site ?
php -v donne la version en ligne de commande, qui peut différer de celle du site. Déposez à la racine du site un fichier temporaire au nom imprévisible (par exemple v-8f3k2.php) contenant :
<?php echo PHP_VERSION;Ouvrez-le dans votre navigateur, notez la version, puis supprimez ce fichier aussitôt. Laissé en ligne, il indique votre version à n'importe qui, y compris aux robots d'attaque.
Un doute sur le résultat ? Envoyez-le nous, on vous dit ce qu'il signifie.
Comment connaître la version de PHP de votre site
- Avec notre test gratuit, si votre serveur annonce sa version : le rapport la compare aux versions corrigées. Masquer sa version est une bonne pratique, mais le test ne peut alors pas conclure : seul un contrôle du serveur permet de savoir si le correctif est appliqué.
- Dans WordPress : Outils, Santé du site, onglet Infos, rubrique Serveur. Dans PrestaShop : Paramètres avancés, Informations.
- Dans l'espace client de votre hébergeur, rubrique de configuration PHP de l'hébergement.
- Sur un serveur que vous administrez : avec les commandes ci-dessus.
Attention : les distributions Linux appliquent souvent le correctif sans changer le numéro de version affiché. Un numéro ancien n'est donc pas une preuve de vulnérabilité, mais c'est un signal à vérifier sans attendre.
En attendant la mise à jour : les atténuations
La seule vraie correction est de mettre PHP à jour. En attendant, ces réglages réduisent le risque, à poser côté serveur par la personne qui l'administre :
- Contre CVE-2026-109618 :
memory_limit=-1imposé au niveau du serveur, de façon que le site ne puisse pas le redéfinir. Revers de la médaille : un script ne sera plus limité en mémoire, à surveiller. - Contre CVE-2026-109619 :
session.upload_progress.enabled=0. - En PHP 8.5, ajoutez aussi
fatal_error_backtraces=0. - Puis redémarrez tous les processus PHP (PHP-FPM, Apache) pour que les réglages s'appliquent.
- Derrière Cloudflare, activez les règles de pare-feu applicatif publiées contre PHP2Shell, disponibles même sur l'offre gratuite. C'est une rustine, pas une correction.
Sur un hébergement mutualisé, vous n'avez en général pas la main sur ces réglages : demandez à votre hébergeur où il en est.
Déjà des signes d'intrusion ?
Une faille exploitée avant la mise à jour peut avoir laissé une porte dérobée, qui survivra au correctif. Fichiers PHP récents ou inconnus, administrateurs ajoutés, tâches planifiées inconnues, redirections étranges : ne vous contentez pas de mettre à jour, voir site piraté : que faire.
PHP2Shell en détail
Les deux failles
- CVE-2026-109618 : corruption mémoire déclenchée lors d'un dépassement de mémoire.
- CVE-2026-109619 : état global réutilisé après avoir été libéré (use-after-free).
- Gravité : 9,2 sur 10 chacune (CVSS v4.0), exécution de code à distance sans authentification. Exécution confirmée sur certaines versions de WordPress, Drupal, Joomla et Magento. Des codes d'attaque circulent publiquement : ne les testez pas sur votre site, ils ne sont pas vérifiés et peuvent eux-mêmes contenir des logiciels malveillants.
Les versions de PHP corrigées
| Votre version | Situation |
|---|---|
| PHP 8.5 | Corrigée à partir de 8.5.12 |
| PHP 8.4 | Corrigée à partir de 8.4.27 |
| PHP 8.3 | Corrigée à partir de 8.3.36 |
| PHP 8.2 | Corrigée à partir de 8.2.35 (plus de support sécurité après le 31 décembre 2026) |
| PHP 7.4 à 8.1 | Pas de version officielle corrigée, seulement des correctifs à appliquer au code source |
| PHP 5.4 à 7.3 | Aucun correctif : seule une montée de version protège |
Si vous devez changer de version, visez au moins PHP 8.3 : la branche 8.2 ne recevra plus de correctifs de sécurité après le 31 décembre 2026.
Les modes d'exécution de PHP touchés
Toute installation de PHP qui sert des pages web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed. Le risque est le plus élevé avec Apache mod_php, où l'attaque démontrée se déclenche avant même que le code du site ne s'exécute. Que votre site soit sous WordPress, PrestaShop ou un autre CMS ne change rien : la faille est dans PHP.
Sources
Avis officiels de php.net, analyse de Tenable, avis 2026-018 du CERT-EU, publications de Cloudflare et suivi de sécurité Debian. Page mise à jour au fil des informations publiées.