Analyser mon site

Tous les articles

php2shell : deux failles critiques de PHP sont corrigées. Mettez à jour le PHP de votre site dès aujourd'hui

PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent CVE-2026-109618 et CVE-2026-109619, deux failles d'exécution de code à distance sans authentification. Qui est concerné, comment vérifier votre version de PHP et que faire maintenant.

Radek, ENSOMEDIAPublié le 9 min de lectureIn EnglishPo polskuAuf DeutschEn español中文بالعربية

Le 21 octobre 2026, le projet PHP a publié PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ces versions corrigent deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, qui peuvent permettre à un attaquant d'exécuter du code sur un serveur web sans se connecter. L'équipe PHP indique que tous les utilisateurs de PHP doivent mettre à jour immédiatement (php.net).

Si votre site fonctionne avec WordPress, WooCommerce, Joomla, Drupal ou tout autre logiciel PHP, vous êtes concerné. Les failles se trouvent dans PHP lui-même, pas dans WordPress ni dans une extension, donc mettre à jour WordPress ne les corrige pas. C'est votre PHP qu'il faut mettre à jour, en général par l'intermédiaire de votre hébergeur.

Ce qui s'est passé

  • 20 octobre 2026 : l'équipe de sécurité de PHP a annoncé pour le 21 octobre 2026 à 14:00 UTC une version de sécurité corrigeant deux vulnérabilités critiques notées CVSS v4.0 9.2 (php.net).
  • 21 octobre 2026, 03:02 UTC : Cloudflare a activé pour ses clients, y compris l'offre gratuite, des règles de pare-feu contre l'attaque. Cloudflare dit que les détails ont fuité avant la publication officielle et qu'il a observé du trafic d'attaque visant ses clients (blog de Cloudflare).
  • 21 octobre 2026 : PHP a publié les versions corrigées et deux avis de sécurité, GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp, tous deux notés Critical, 9.2.

Les deux failles sont appelées « php2shell » (blog de Cloudflare, BleepingComputer). Le National Cyber Security Centre britannique demande aux organisations de mettre à jour et d'envisager de mettre un système hors ligne s'il ne peut pas être mis à jour ou protégé rapidement (NCSC).

Qui est concerné

Selon PHP, toute installation de PHP qui traite des requêtes web est exposée, y compris PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. PHP juge le risque le plus élevé avec mod_php, où un exploit démontré fonctionne avec une seule requête sans authentification, avant l'exécution du moindre code applicatif (php.net).

Les deux avis déclarent concernées toutes les versions antérieures à 8.2.35, 8.3.36, 8.4.27 et 8.5.12 (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp). Les branches plus anciennes le sont aussi : le NCSC parle de PHP 5 et suivants (NCSC), Cloudflare de PHP 5.4 ou plus récent (blog de Cloudflare).

Si votre site utilise PHP et que personne n'a mis PHP à jour depuis l'après-midi du 21 octobre, considérez qu'il est concerné.

Comment vérifier la version de PHP de votre site

Dans WordPress : allez dans Outils > Santé du site > Infos et ouvrez la section Serveur. Elle indique la version de PHP sur laquelle tourne votre site (documentation WordPress.org). Si Santé du site signale aussi que votre site utilise une version obsolète de PHP, traitez-le comme urgent.

Dans le panneau de votre hébergeur : la plupart des panneaux (cPanel, Plesk, DirectAdmin et ceux propres à chaque hébergeur) ont une page pour consulter ou choisir la version de PHP, souvent appelée « Version de PHP », « Sélecteur PHP » ou « Paramètres PHP ». Si vous ne la trouvez pas, demandez à votre hébergeur.

Comparez ce que vous voyez avec les versions corrigées ci-dessous. Une réserve : les distributions Linux et les fournisseurs de support à long terme ont reçu les correctifs à l'avance et livrent leurs propres paquets (php.net). Leur numéro de version peut ne pas correspondre à ceux du projet PHP même si le correctif est inclus. Si votre hébergeur utilise les paquets de la distribution, la réponse fiable vient de l'hébergeur, pas du seul numéro.

Que faire maintenant

1. Passer à une version corrigée

Votre branche PHP Version corrigée État du support
8.5 8.5.12 Correctifs de sécurité jusqu'au 31 déc. 2029
8.4 8.4.27 Correctifs de sécurité jusqu'au 31 déc. 2028
8.3 8.3.36 Correctifs de sécurité jusqu'au 31 déc. 2027
8.2 8.2.35 Correctifs de sécurité jusqu'au 31 déc. 2026, puis fin de vie
8.1 et antérieures Aucune version officielle Fin de vie, voir ci-dessous

Versions corrigées : php.net. Dates de support : versions de PHP prises en charge.

Si vous êtes sur PHP 8.2, passez dès maintenant à 8.2.35 et prévoyez la migration vers 8.3 ou plus récent. PHP 8.2 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026 (php.net).

2. Si vous êtes sur PHP 8.1, 8.0, 7.4 ou antérieur

Le projet PHP ne publie plus de mises à jour pour PHP 8.1 et les versions antérieures. Certaines distributions et certains fournisseurs de LTS proposent des correctifs rétroportés. Vu la gravité, l'équipe de sécurité de PHP a aussi publié des rétroportages minimaux du code source pour PHP 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP depuis les sources ou n'ont pas de fournisseur de LTS (php.net).

Pour un site d'entreprise ordinaire sur un hébergement mutualisé ou géré, la réponse est plus simple : passez à une version prise en charge (8.3 ou plus récent) dans le panneau de votre hébergeur, ou demandez-lui de le faire. Testez ensuite le site, car d'anciennes extensions et d'anciens thèmes cessent parfois de fonctionner avec un PHP plus récent.

3. Demandez à votre hébergeur

Envoyez à votre hébergeur un court message :

Bonjour, le PHP de mon compte (domaine : example.fr) est-il déjà corrigé contre CVE-2026-109618 et CVE-2026-109619 ? Quelle version ou quel paquet PHP exact utilise-t-il, et quand la mise à jour sera-t-elle appliquée si elle n'est pas encore faite ?

Si vous gérez votre propre serveur et utilisez le dépôt rpms.remirepo.net, maintenu par des bénévoles, PHP indique qu'il n'aura pas de mises à jour le 21 octobre et recommande de passer aux paquets de la distribution ou de compiler depuis les sources (php.net).

4. Un pare-feu gagne quelques jours, ce n'est pas le correctif

Cloudflare a déployé des règles contre les méthodes d'attaque connues sur toutes les offres avec WAF, y compris Free (blog de Cloudflare). Le CTO de Cloudflare les a qualifiées de solution provisoire et a demandé aux administrateurs d'appliquer le correctif (Tenable). PHP dit lui-même qu'il n'existe pas de contournement complet et que la mise à jour est le seul choix sûr (php.net).

Deux limites. Les règles couvrent des schémas d'attaque connus, et les attaquants modifiaient déjà leurs charges pour les contourner (blog de Cloudflare). Et les règles ne protègent rien si les attaquants peuvent joindre directement votre serveur par son adresse IP : le serveur d'origine ne doit donc accepter le trafic web que de Cloudflare (Sansec).

5. Si vous ne pouvez pas mettre à jour aujourd'hui

PHP énumère des changements de configuration qui réduisent l'exposition aux voies d'attaque connues sans rendre un serveur sûr (php.net). Ce sont des réglages du serveur : sur un hébergement mutualisé, c'est votre hébergeur qui doit les appliquer. Remettez cette liste à votre développeur ou à votre hébergeur :

  • Pour CVE-2026-109618 : définissez memory_limit=-1 de façon que les applications ne puissent pas le modifier (par exemple php_admin_value dans le pool FPM ou la configuration Apache), fixez un post_max_size bas (8M sans envois de fichiers, 32M avec) avec upload_max_filesize en dessous, et limitez la taille de la requête, le nombre de champs, les parties multipart et les en-têtes au niveau du serveur web ou du proxy. N'utilisez pas RLIMIT_AS ni RLIMIT_DATA.
  • Pour CVE-2026-109619 : définissez session.upload_progress.enabled=0 dans php.ini, le pool FPM ou la configuration du serveur et redémarrez tous les workers (ini_set() et .user.ini ne fonctionnent pas pour cela). Sur PHP 8.5, définissez aussi fatal_error_backtraces=0 et redémarrez tous les workers. Supprimez les réglages par requête invalides ou obsolètes qui produisent des avertissements.

Détails techniques

Les deux failles viennent du même type de problème : quand une requête se termine de façon anormale, PHP peut laisser la mémoire dans un état cassé auquel une étape ultérieure fait confiance (BleepingComputer, blog de Cloudflare).

CVE-2026-109618, RCE par corruption lors d’un manque de mémoire (OOM) (GHSA-w8hw-w9fx-j79w). PHP utilise longjmp() pour interrompre une requête lorsqu'il manque de mémoire. À certains endroits, la mémoire de la requête est accessible avant d'être entièrement initialisée. Si une allocation échoue à ce moment, l'arrêt de la requête peut lire les données à moitié construites. Les attaquants peuvent provoquer le manque de mémoire avec des requêtes multipart : un corps sans longueur de contenu exploitable, une partie avec un nombre énorme d'en-têtes, ou de nombreux champs de fichier vides avec des noms imbriqués. Avec Apache mod_php, cela se produit pendant l'analyse automatique du corps, avant l'exécution de tout code applicatif. L'exécution de code à distance sous le compte du worker web a été confirmée contre mod_php avec les limites d'entrée et de mémoire par défaut. FPM est jugé vulnérable d'après l'analyse du code source, mais aucun exploit complet pour FPM n'a été démontré. Le correctif remplace longjmp() en cas de manque de mémoire par un arrêt doux différé à un point sûr et un _exit() brutal à un seuil plus élevé.

CVE-2026-109619, RCE par état global périmé (GHSA-6wmf-4rv5-p3rp). Un worker PHP conserve un état global (état des erreurs, des sessions, des objets et des extensions) qui pointe vers une mémoire appartenant à une seule requête. Une erreur fatale, y compris un manque de mémoire ou Maximum execution time exceeded, peut sauter la réinitialisation de cet état. La requête suivante traitée par le même worker peut alors utiliser la mémoire libérée avant l'initialisation normale, soit une utilisation après libération (use after free). Deux consommateurs précoces sont confirmés : les avertissements issus de réglages INI par requête appliqués avant l'initialisation, et la progression d'envoi de session, activée par défaut et qui n'exige pas que l'application appelle session_start(). La voie fatal_error_backtraces de PHP 8.5 sert de base à l'exploit confirmé contre mod_php. La voie des sessions a été validée contre mod_php et FPM. Masquer les erreurs avec error_reporting, display_errors ou @ ne protège pas.

Les deux avis obtiennent 9.2 avec le vecteur CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N : attaque par le réseau, aucun privilège, aucune interaction de l'utilisateur, complexité d'attaque élevée et impact total sur la confidentialité, l'intégrité et la disponibilité du serveur.

Ce que vérifie ShieldWave

De l'extérieur, personne ne peut savoir si un serveur a le correctif. Une analyse ne voit que la version de PHP que le serveur annonce de lui-même.

  • L'analyse gratuite sur shieldwave.io lit l'en-tête de réponse X-Powered-By. Si le serveur annonce une version de PHP antérieure à la version corrigée de sa branche, ou une branche qui ne reçoit aucun correctif, le rapport liste un constat php2shell avec les deux numéros CVE et la version dont vous avez besoin. Beaucoup d'hébergeurs masquent cet en-tête, et les distributions corrigent sans changer le numéro : un constat signifie donc « demandez à votre hébergeur », et l'absence de constat ne prouve pas que le serveur est corrigé.
  • L'extension Ensomedia Security pour WordPress affiche la version de PHP sur laquelle tourne le site et indique si cette branche est encore prise en charge (page de l'extension). Elle repère ainsi le pire cas de cet incident : un site sur PHP 8.1, 8.0, 7.4 ou antérieur, qui ne reçoit aucun correctif officiel. L'extension est gratuite, ne demande aucun compte et se trouve dans le répertoire WordPress.org. Dans votre tableau de bord, allez dans Extensions > Ajouter et cherchez « Ensomedia Security ».

Pour connaître le niveau exact de correctif, utilisez Santé du site et le tableau ci-dessus, puis faites confirmer par votre hébergeur.

Sources

Officielles :

Autres :