Aller au contenu
PubliéPHPsécuritéCVE-2026-109618CVE-2026-109619php2shell

php2shell : deux failles critiques dans PHP, ce qu'il faut faire

Équipe Seagle22 octobre 20265 min de lecture

Résumé

Le 21 octobre 2026, le projet PHP a corrigé deux failles critiques surnommées « php2shell ». Cet article résume ce qui est établi, qui est concerné et les gestes à faire dans l'ordre. Il est écrit pour être utile même si vous gérez tout seul.

1. Ce qui s'est passé

Le projet PHP a publié le 21 octobre 2026 (14:00 UTC) des correctifs pour deux failles d'exécution de code à distance :

  • CVE-2026-109618 : corruption de la mémoire lorsque PHP manque de mémoire (OOM), déclenchée par des requêtes multipart.
  • CVE-2026-109619 : réutilisation d'un état périmé entre deux requêtes traitées par le même processus.

Chacune est notée 9,2 sur 10 (CVSS v4.0). Elles peuvent être exploitées sans authentification, par une requête envoyée avant tout code de votre application. Un attaquant qui réussit peut exécuter du code sur le serveur et lire la mémoire du processus, donc potentiellement des mots de passe, des jetons ou des clés d'API.

Ce qui est observé, à la date du 21 octobre :

  • Palo Alto Networks (Unit 42) a vu des preuves de concept pour les deux failles et estime à plus de 22,6 millions le nombre d'instances potentiellement vulnérables (méthode d'estimation non détaillée).
  • Cloudflare a observé du trafic d'attaque chez ses clients.
  • Patchstack n'a relevé que des tentatives de sondage, sans preuve de compromission ; le CERT-FR ne mentionne pas d'exploitation.
  • Des faux codes d'exploitation circulent sur GitHub, certains piégés (JFrog).

Ce qui n'est pas établi : une panne ou une compromission à grande échelle. Aucune source ne la confirme.

2. Qui est concerné

Tout serveur qui fait tourner PHP pour le web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Le cas mod_php est le plus exposé.

  • Pour CVE-2026-109618, un PHP-FPM démarré normalement est exposé.
  • Pour CVE-2026-109619, la condition recoupée est session.upload_progress.enabled=On (valeur par défaut), sans appel à session_start().

Wiz indique que toutes les versions depuis la 5.4 sont touchées par au moins une des deux failles.

WordPress, PrestaShop ou Laravel ne sont pas en cause : la faille est dans l'interpréteur PHP. Mettre à jour le site ou ses extensions ne corrige rien ; c'est PHP, côté serveur, qu'il faut mettre à jour.

3. Que faire maintenant

Mettre à jour PHP est la seule mesure complète. Versions corrigées :

BrancheVersion corrigée
8.58.5.12
8.48.4.27
8.38.3.36
8.28.2.35 (fin de support le 31/12/2026)

Les branches 8.1 et antérieures n'ont pas de correctif officiel. Des rétroportages de la source existent pour 7.4, 8.0 et 8.1 ; à défaut, demandez un correctif à votre fournisseur, migrez, ou isolez le service.

Selon votre cas :

  • Hébergement mutualisé : PHP est géré par l'hébergeur. Demandez-lui la date du correctif.
  • Serveur (VPS) : appliquez les mises à jour de votre distribution, puis redémarrez PHP-FPM ou Apache.
  • Conteneur : reconstruisez sur une image officielle php en version corrigée, puis redéployez. Si vous utilisez une image applicative (Nextcloud, WordPress), vérifiez le PHP embarqué.

Si vous ne pouvez pas mettre à jour tout de suite, des contournements partiels existent. Ils réduisent le risque sans le supprimer et ne sont pas qualifiés par le CERT-FR :

  • Désactiver session.upload_progress.enabled dans php.ini ou dans le pool FPM (php_admin_flag[session.upload_progress.enabled] = off), puis redémarrer tous les workers. ini_set() et .user.ini ne suffisent pas. Cela ne couvre que CVE-2026-109619.
  • Sous PHP 8.5, fatal_error_backtraces=0.
  • Sous FPM, pm.max_requests=1, au prix de performances.
  • Au niveau du pare-feu applicatif (WAF) : bloquer les requêtes Content-Type: multipart si votre application n'en a pas besoin, sinon les surveiller. Cloudflare a activé des règles par défaut depuis le 21 octobre 03:02 UTC, y compris sur l'offre gratuite ; ce n'est pas un correctif.

À éviter : installer une extension « correctif » non officielle, et exécuter un code d'attaque trouvé en ligne.

Signes à surveiller : requêtes multipart inhabituelles associées à des erreurs memory_limit, cookies PHPSESSID de taille anormale, redémarrages de workers. Dans ce cas, présumez une compromission et renouvelez vos secrets.

4. Comment vérifier sa version

  • Ligne de commande : php -v donne la version du PHP en ligne de commande. Celle utilisée par le web (FPM, mod_php) peut différer si plusieurs PHP sont installés.
  • Conteneur : docker exec <conteneur> php -v.
  • WordPress : Outils > Santé du site > Info > Serveur.
  • Laravel : php artisan about (version CLI).
  • Mutualisé : la rubrique « version PHP » du panneau de votre hébergeur, dont l'emplacement varie.
  • phpinfo() : possible via une page temporaire, à supprimer immédiatement après lecture, car elle expose votre configuration.

Comparez ensuite avec le tableau ci-dessus.

5. Ce que Seagle propose

Seagle est un éditeur logiciel français. Si vous préférez ne pas gérer cela seul, nous proposons un diagnostic et une mise à jour express : relevé de la version en place, passage à une version corrigée, contournement immédiat si nécessaire, puis rapport court. Nous ne sondons jamais un site ou un serveur sans demande écrite de son responsable. Pour en parler, écrivez-nous via la page contact du site.

Sources

Consultées le 21 octobre 2026.