PHP2Shell et CVE-2024-4577 : les deux failles PHP à corriger d'urgence

Une faille de sécurité PHP n'est jamais un sujet réservé aux développeurs. PHP fait tourner WordPress, la plupart des sites vitrines et une bonne partie des boutiques en ligne que nous voyons chez nos clients à Douala et Yaoundé. Quand le cœur du langage est vulnérable, c'est votre site, votre base clients et parfois votre serveur entier qui sont exposés.

Deux failles sortent du lot ces dernières années, parce qu'elles ont été réellement exploitées par des attaquants : PHP2Shell, corrigée en urgence le 21 octobre 2026, et CVE-2024-4577, utilisée par un rançongiciel en 2024. Voici ce qui se passe, qui est touché, quelles versions installer et comment vérifier votre hébergement mutualisé.

Pourquoi une faille de sécurité PHP touche presque tout le monde

Votre site WordPress n'est qu'une couche posée sur PHP. Les extensions, le thème et le cœur de WordPress sont écrits en PHP, et c'est le moteur PHP de l'hébergeur qui les exécute. Si ce moteur a un défaut, mettre à jour WordPress ne suffit pas.

Le danger le plus grave porte un nom : l'exécution de code à distance. Un attaquant envoie une requête à votre site et obtient le droit de lancer ses propres commandes sur le serveur. À partir de là, il peut déposer une porte dérobée, voler la base de données ou chiffrer vos fichiers.

Les deux failles présentées ici entrent dans cette catégorie. La première concerne pratiquement tous les sites PHP. La seconde vise un cas plus étroit, les serveurs Windows, mais elle a été exploitée très vite et à grande échelle.

PHP2Shell (CVE-2026-109618 et CVE-2026-109619) : ce qui se passe

PHP2Shell désigne deux vulnérabilités du cœur de PHP, publiées par le projet PHP le 21 octobre 2026. Selon l'avis officiel publié sur php.net, elles peuvent permettre une exécution de code à distance sans authentification. Les deux sont notées 9,2 sur 10 selon le barème CVSS v4.0.

Le calendrier a été chaotique. D'après Huntress, des informations ont fuité le 20 octobre, alors que la publication était prévue plus tard dans la semaine. Le projet PHP a alors avancé la sortie des correctifs d'un jour.

Sur le fond, l'avis de PHP décrit deux défauts de gestion de la mémoire :

• CVE-2026-109618 : quand PHP manque de mémoire en plein traitement d'une requête, certaines données internes restent à moitié initialisées. Le nettoyage de fin de requête les traite ensuite comme valides.
• CVE-2026-109619 : un état interne lié à une requête peut survivre après la libération de sa mémoire. Une requête suivante, traitée par le même processus, peut alors réutiliser cet état périmé.

Le point le plus inquiétant figure dans l'avis lui-même. Le projet PHP indique qu'un exploit a été démontré avec mod_php, où une requête non authentifiée déclenche l'attaque avant même que le code de votre site ne s'exécute. Autrement dit, un site WordPress parfaitement à jour reste exposé si le PHP du serveur ne l'est pas.

Une exploitation confirmée

Selon Help Net Security, qui cite Amazon Threat Intelligence, un pot de miel d'Amazon a enregistré une tentative d'exploitation dès le 17 octobre 2026, quatre jours avant la publication. Le 26 octobre, l'agence américaine CISA a ajouté les deux vulnérabilités à son catalogue des failles activement exploitées (KEV).

D'après Huntress, des chercheurs de Wiz ont aussi publié une démonstration d'attaque contre WordPress, Drupal et Joomla. Le sujet n'est donc plus théorique.

PHP2Shell : qui est touché et quelles versions installer

L'avis de PHP est clair : sont à risque toutes les installations PHP qui servent des requêtes web. Cela inclut PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé pour mod_php.

Les versions corrigées sont les suivantes :

Branche PHP	Version minimale corrigée	Statut
8.5	8.5.12	Maintenue
8.4	8.4.27	Maintenue
8.3	8.3.36	Maintenue
8.2	8.2.35	Maintenue
8.1 et plus anciennes	Aucune version officielle	Plus mises à jour par le projet PHP

Pour les branches 7.4, 8.0 et 8.1, le projet PHP a publié des correctifs minimaux sous forme de code source. Ils servent aux administrateurs qui compilent PHP eux-mêmes ou aux distributions Linux. Sur un hébergement mutualisé, ce n'est pas une solution sur laquelle vous pouvez compter : il faut passer à une branche maintenue.

Le projet PHP liste des réglages qui réduisent l'exposition, comme désactiver session.upload_progress.enabled ou limiter la taille des requêtes. Il précise toutefois qu'ils ne rendent pas une installation sûre. La mise à jour reste la seule réponse complète.

CVE-2024-4577 : l'injection d'arguments dans PHP-CGI sous Windows

La seconde faille date de juin 2024, mais elle reste un cas d'école. Elle a été découverte par la société taïwanaise DEVCORE, qui l'a signalée au projet PHP le 7 mai 2024. Le correctif est sorti le 6 juin 2024.

Le principe est subtil. Sous Windows, une fonction de conversion de caractères, appelée « Best-Fit », transforme certains caractères spéciaux en tiret ordinaire. Un attaquant peut ainsi glisser des options de ligne de commande à php-cgi.exe, en contournant une ancienne protection. Résultat : il fait exécuter le code de son choix.

DEVCORE a confirmé l'exploitation sur des systèmes Windows configurés en chinois traditionnel, chinois simplifié et japonais. Les autres langues n'avaient pas pu être entièrement évaluées. Point important : XAMPP pour Windows était vulnérable dans sa configuration par défaut.

Un rançongiciel en quelques jours

Selon Imperva, des attaquants ont utilisé la faille pour diffuser le rançongiciel TellYouThePass dès le 8 juin 2024, deux jours après le correctif. Ils déposaient des portes dérobées puis chiffraient les fichiers, en laissant une demande de rançon à la racine du site. La CISA a ajouté CVE-2024-4577 à son catalogue KEV le 12 juin 2024, avec la mention d'un usage connu par des rançongiciels.

Qui est touché et versions corrigées

Sont concernés les serveurs Windows qui exécutent PHP en mode CGI ou exposent l'exécutable PHP, ce qui inclut XAMPP. Les versions corrigées sont 8.3.8, 8.2.20 et 8.1.29. Les branches 8.0, 7 et 5 n'ont reçu aucun correctif.

La plupart des hébergements mutualisés tournent sous Linux et ne sont pas concernés par cette faille. En revanche, nous voyons encore des entreprises qui hébergent leur logiciel de gestion ou leur intranet sur un PC Windows avec XAMPP, parfois accessible depuis Internet. Si c'est votre cas, ce serveur doit être mis à jour ou retiré d'Internet sans attendre.

Et CVE-2024-2961, la faille d'iconv ?

On cite souvent une troisième vulnérabilité : CVE-2024-2961. Elle ne se trouve pas dans PHP mais dans glibc, une bibliothèque système de Linux, au niveau de la conversion vers le jeu de caractères ISO-2022-CN-EXT. Le chercheur Charles Fol a montré qu'elle pouvait être exploitée à travers PHP.

Sa conclusion, publiée sur la liste oss-security, est frappante : une simple faille de lecture de fichier dans une application PHP pouvait devenir une exécution de code. La correction passe ici par la mise à jour du système d'exploitation du serveur, donc par votre hébergeur. C'est un bon rappel : la sécurité de votre site dépend aussi de couches que vous ne voyez pas.

Vérifier votre version de PHP sur un hébergement mutualisé

Bonne nouvelle : vérifier prend cinq minutes. Trois méthodes, de la plus simple à la plus précise :

1. Dans WordPress : menu Outils, puis Santé du site, onglet Infos, rubrique Serveur. La version de PHP y est affichée.
2. Dans le panneau d'hébergement : sous cPanel, cherchez « Sélectionner une version de PHP » ou « MultiPHP Manager ». Sous Plesk, ouvrez les paramètres PHP du domaine. Vous y voyez la branche active, par exemple 8.3.
3. Avec un fichier de test : créez un fichier contenant <?php phpinfo();, ouvrez-le dans le navigateur, notez la version exacte, puis supprimez le fichier immédiatement. Il révèle des informations utiles aux attaquants.

Comparez ensuite le numéro obtenu avec le tableau ci-dessus. Attention à un piège : certains hébergeurs appliquent des correctifs sans changer le numéro affiché, et d'autres affichent une branche sans préciser la version mineure. Dans le doute, la seule réponse fiable est celle de l'hébergeur.

Corriger : la marche à suivre sur un mutualisé

Sur un hébergement mutualisé, vous ne contrôlez pas le serveur. Vous contrôlez la branche de PHP et la pression que vous mettez sur votre hébergeur. Voici l'ordre que nous suivons pour nos clients :

1. Ouvrez un ticket chez l'hébergeur et demandez par écrit si les correctifs de CVE-2026-109618 et CVE-2026-109619 sont appliqués sur votre serveur, et à quelle date. Une réponse vague n'est pas une réponse.
2. Quittez les branches abandonnées. Si votre site tourne en PHP 8.1, 8.0 ou 7.x, passez à 8.3 ou 8.4. Ces anciennes branches ne recevront plus de correctifs officiels.
3. Testez avant de basculer. Un changement de branche peut casser une extension ancienne. Faites une sauvegarde complète, testez sur une copie du site si votre hébergeur le permet, puis basculez.
4. Mettez à jour WordPress, le thème et les extensions pour qu'ils soient compatibles avec la nouvelle version de PHP.
5. Si l'hébergeur ne corrige pas, changez d'hébergeur. Un serveur PHP non corrigé contre une faille exploitée n'est pas un risque acceptable pour un site qui encaisse des paiements Mobile Money ou collecte des données clients.

Repérer une compromission

Corriger une faille de sécurité PHP ferme la porte, mais ne chasse pas un intrus déjà entré. Huntress recommande notamment de chercher des fichiers ajoutés dans le dossier du site, des tâches planifiées inconnues et des comptes créés récemment. Sur un site WordPress, cela se traduit concrètement par quelques vérifications :

• des comptes administrateurs que vous ne reconnaissez pas ;
• des fichiers PHP récents dans les dossiers d'images ou d'envois ;
• des tâches cron inconnues dans le panneau d'hébergement ;
• des redirections vers des sites de jeux ou de pharmacie, souvent visibles seulement sur mobile ;
• une alerte de Google Search Console signalant un piratage.

Au moindre doute, changez tous les mots de passe (hébergement, FTP, base de données, administrateurs WordPress) et restaurez une sauvegarde antérieure à l'incident. Pour la suite, notre checklist pour sécuriser son site web détaille les protections à mettre en place durablement.

Ce que ces deux failles nous apprennent

La leçon est la même dans les deux cas : entre la publication d'une faille de sécurité PHP et les premières attaques, il s'écoule parfois quelques jours, voire moins. Pour CVE-2024-4577, deux jours ont suffi. Pour PHP2Shell, une tentative a précédé la publication.

Un site n'est pas un produit livré une fois pour toutes. Il repose sur un langage, un système et un hébergeur qui doivent être suivis. Chez nos clients, les sites compromis ont presque toujours un point commun : une version de PHP ou une extension que personne ne surveillait.

Vous ne savez pas quelle version de PHP fait tourner votre site, ou votre hébergeur tarde à répondre ? Réservez un audit offert : nous vérifions votre hébergement, la version de PHP et les signes de compromission, puis nous vous disons clairement quoi corriger. Pour une prise en charge complète, découvrez aussi nos services.