EnforceGate vX
FR

php2shell : vulnérabilités critiques dans PHP, que faire maintenant

Nicolas | 5 minutes | Articles

Nicolas

PDG, Ingénieur sécurité

OSCP GXPN CCNP JNCIP-SP

Avertissement : événement en cours. Plusieurs points restent inconnus, et les informations de cette page peuvent être incomplètes, évoluer ou être corrigées à mesure que les faits sont confirmés. Considérez tout ce qui est marqué « signalé » comme non confirmé, et consultez les sources officielles indiquées en bas de page avant d'agir. Nous mettons cette page à jour au fil de l'évolution de la situation.
Dernière mise à jour : 21 octobre 2026, 16h11 (CEST)

En bref

Le projet PHP a publié les versions PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux vulnérabilités critiques qui peuvent permettre l'exécution de code à distance sans authentification. PHP demande à tous les utilisateurs de mettre à jour immédiatement et indique que la mise à jour est le seul choix sûr. PHP fait tourner une très grande part du web, des sites WordPress et autres systèmes de gestion de contenu aux applications métier sur mesure : la plupart des organisations en utilisent quelque part, souvent sans le savoir.

Si vous utilisez PHP, mettez à jour maintenant. Nous distinguons ci-dessous ce que PHP a confirmé de ce qui est seulement rapporté, et nous listons ce qu'il faut faire, y compris pour les systèmes qui ne peuvent pas être mis à jour aujourd'hui.

Chronologie

Du plus récent au plus ancien. Chaque entrée indique qui en est la source.

  1. 21 octobre 2026 Avis Debian
    Debian publie l'avis DSA-6574-1 : php8.4 dans Debian 13 (trixie) est corrigé dans la version 8.4.27-1~deb13u1 pour CVE-2026-109618 et CVE-2026-109619, que Debian décrit comme un suivi incorrect de l'état de la mémoire pouvant conduire à l'exécution de code arbitraire. Source: Debian
  2. 21 octobre 2026 Confirmé par PHP
    L'avis de PHP indique que le dépôt de Remi, maintenu par des bénévoles, n'aura pas de mises à jour aujourd'hui, et invite ses utilisateurs à passer aux paquets de leur distribution ou à compiler depuis les sources. Il précise aussi que PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet PHP, et renvoie à des rétroportages minimaux du code source pour 7.4, 8.0 et 8.1. Source: PHP.net
  3. 21 octobre 2026 Confirmé par PHP
    PHP publie les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent CVE-2026-109618 et CVE-2026-109619, deux failles critiques pouvant permettre l'exécution de code à distance sans authentification. PHP indique que la mise à jour est le seul choix sûr. Source: PHP.net
  4. Matin du 21 octobre 2026 Signalé, non confirmé
    Cloudflare signale des attaques précoces contre des sites PHP et déploie des règles WAF.
  5. 20 octobre 2026 Signalé, non confirmé
    Des informations sur les failles auraient fuité avant la divulgation coordonnée, prévue à l'origine le 22 octobre. Les documents ayant fuité annonçaient un score CVSS de 10,0 ; la note officielle de PHP est de 9,2.
  6. 20 octobre 2026 Confirmé par PHP
    L'équipe de sécurité de PHP annonce une mise à jour de sécurité critique pour le mercredi 21 octobre 2026 à 14h00 UTC (16h00 CEST), qui corrige deux vulnérabilités, toutes deux notées 9,2 (CVSS v4.0). Source: PHP.net

Ce que nous savons

Confirmé par le projet PHP

  • PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent CVE-2026-109618 et CVE-2026-109619, toutes deux critiques (CVSS v4.0 9,2), qui peuvent permettre l'exécution de code à distance sans authentification.
  • CVE-2026-109618 : la gestion d'un manque de mémoire peut interrompre PHP alors que les données internes de la requête ne sont que partiellement initialisées, et le nettoyage de la requête peut alors traiter ces données invalides comme valides. Voir l'avis GitHub .
  • CVE-2026-109619 : un état interne propre à une requête peut survivre à la libération de sa mémoire, et une requête suivante traitée par le même processus peut utiliser cet état périmé. Voir l'avis GitHub .
  • Versions touchées, selon les deux avis GitHub : toutes les versions antérieures à 8.2.35, 8.3.36, 8.4.27 et 8.5.12 dans leurs branches respectives. Les deux failles sont notées critiques, CVSS v4.0 9,2 : exploitables par le réseau, sans privilèges ni interaction de l'utilisateur, mais avec une complexité d'attaque élevée. Les faiblesses listées sont l'utilisation après libération, la gestion incorrecte de conditions exceptionnelles, l'accès à un pointeur non initialisé, l'allocation mémoire séquentielle mal contrôlée et l'initialisation incorrecte d'une ressource.
  • Qui est exposé : toutes les installations PHP qui traitent des requêtes web, y compris PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. PHP estime le risque le plus élevé pour mod_php, avec une exploitation démontrée dans laquelle une requête non authentifiée déclenche l'attaque avant l'exécution de tout code applicatif.
  • PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour du projet PHP. Certaines distributions et certains fournisseurs de support à long terme proposent des correctifs rétroportés ; PHP conseille de contacter votre fournisseur ou de passer à une version supportée. PHP fournit aussi des rétroportages minimaux du code source pour 7.4 , 8.0 et 8.1 .
  • Les distributions Linux et les fournisseurs de support à long terme ont reçu les correctifs à l'avance : vérifiez auprès de votre fournisseur si des paquets à jour sont disponibles.
  • Le dépôt de Remi , maintenu par des bénévoles, n'aura pas de mises à jour aujourd'hui, et PHP invite ses utilisateurs à passer aux paquets de leur distribution ou à compiler depuis les sources.
  • PHP 8.2 arrive en fin de vie le 31 décembre 2026.
  • Il n'existe aucune mesure d'atténuation complète. Les mesures indiquées par PHP réduisent l'exposition à certains chemins d'attaque, mais ne rendent pas une installation sûre.

Rapporté, pas confirmé par PHP

  • Les failles ont été surnommées « php2shell » par watchTowr , qui affirme avoir reproduit CVE-2026-109618.
  • Les failles remonteraient jusqu'à PHP 5.4. Les avis de PHP ne listent les versions touchées que comme toutes celles qui précèdent les versions corrigées des branches supportées, sans dire jusqu'où elles remontent.
  • Les détails auraient fuité avant la divulgation coordonnée, prévue le 22 octobre, et les documents ayant fuité annonçaient un score CVSS de 10,0 contre 9,2 pour la note officielle de PHP.
  • Des attaques contre des sites PHP ont été signalées dans la matinée du 21 octobre, et des chercheurs en sécurité s'attendent à une exploitation massive maintenant que le correctif est public.

Qui est concerné

Toute organisation qui exploite PHP : systèmes de gestion de contenu comme WordPress , Drupal , WooCommerce et Adobe Commerce, applications PHP sur mesure, portails et intranets, et images de conteneurs qui embarquent PHP. Si vous ne savez pas si vous utilisez PHP, posez la question à la personne qui héberge ou maintient votre site et vos applications métier.

PHP ne se trouve pas seulement sur les serveurs web. Dans certains cas, il fonctionne aussi sur de petits appareils comme des téléphones IP ou des imprimantes, généralement derrière leur page d'administration web. Ils sont faciles à oublier dans un inventaire, et leur correctif peut dépendre d'une mise à jour du micrologiciel publiée par le fabricant. Incluez-les dans votre vérification et interrogez le fournisseur.

Que faire maintenant

  1. Mettez d'abord à jour les systèmes accessibles depuis Internet vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou vers le paquet corrigé de votre fournisseur (téléchargements ).
  2. Faites l'inventaire de tous les serveurs, images de conteneurs et comptes d'hébergement qui utilisent PHP, avec leur version, et ajoutez les petits appareils susceptibles de l'exécuter, comme les téléphones IP et les imprimantes.
  3. PHP 8.1 ou plus ancien : vérifiez si votre fournisseur livre un correctif rétroporté, ou planifiez la mise à niveau.
  4. Vérifiez votre source de paquets. Si vous dépendez du dépôt de Remi, n'attendez pas aujourd'hui : passez aux paquets de votre distribution ou compilez depuis les sources, comme le conseille PHP.
  5. Reconstruisez les images de conteneurs, pas seulement les hôtes.
  6. Placez un WAF ou un reverse proxy devant les applications PHP exposées sur Internet, dans la mesure du possible. Cela réduit le risque ; ce n'est pas un correctif.

Si vous ne pouvez pas mettre à jour tout de suite

PHP indique que ces mesures réduisent l'exposition à certains chemins d'attaque mais ne rendent pas une installation sûre. Ce sont des palliatifs en attendant la mise à jour, et ce sont les termes de PHP, pas les nôtres.

  • Pour CVE-2026-109618 : définissez memory_limit=-1, de préférence là où les applications ne peuvent pas le modifier ; fixez un post_max_size bas (8M pour les applications sans téléversement de fichiers, 32M avec) avec upload_max_filesize en dessous ; et appliquez au niveau du serveur web ou du proxy des limites sur la taille décodée des requêtes et sur le nombre de variables d'entrée, de parties multipart, d'en-têtes et de téléversements, et abaissez max_input_nesting_level ; si l'application n'utilise pas les requêtes multipart, bloquez-les à ce niveau. N'utilisez pas RLIMIT_AS ni RLIMIT_DATA, qui peuvent provoquer l'échec vulnérable.
  • Pour CVE-2026-109619 : définissez session.upload_progress.enabled=0 dans php.ini ou dans la configuration du pool FPM ou du serveur (pas avec ini_set() ni .user.ini) et redémarrez tous les processus. Cela bloque les chemins de session confirmés, mais pas d'autres variantes. Sous PHP 8.5, fatal_error_backtraces=0 bloque uniquement le chemin confirmé lié aux traces d'erreurs fatales. L'avis suggère aussi de supprimer les erreurs fatales atteignables par un attaquant et les messages de diagnostic de configuration, et, si les performances le permettent, pm.max_requests=1. Il précise qu'il n'existe aucune mesure de configuration générique complète.

Debian et Ubuntu

Debian et Ubuntu diffusent les correctifs PHP par leurs propres canaux de sécurité, en général sous la forme d'un paquet corrigé de la même version de PHP : un paquet qui affiche encore un ancien numéro, comme 8.1.2 ou 8.3.6, n'est donc pas forcément vulnérable. Ne jugez pas votre exposition d'après php -v seul. Debian a publié un avis sur ces failles (DSA-6574-1 ) ; nous n'avions pas encore vu d'avis Ubuntu.

  • Debian 13 (trixie). L'avis DSA-6574-1, daté du 21 octobre, couvre CVE-2026-109618 et CVE-2026-109619 et recommande de mettre à jour les paquets php8.4 ; la version corrigée est 8.4.27-1~deb13u1. Debian décrit les failles comme un suivi incorrect de l'état de la mémoire pouvant conduire à l'exécution de code arbitraire.
  • Version fournie par défaut (d'après des avis récents) : Debian 12 avec PHP 8.2 (nous n'avons vu aucun avis pour cette version pour l'instant) et Debian 13 avec PHP 8.4 ; Ubuntu 22.04 avec PHP 8.1, Ubuntu 24.04 avec PHP 8.3 et Ubuntu 26.04 avec PHP 8.5 (voir USN-8564-1 ).
  • Ubuntu 22.04 et PHP 8.1. PHP 8.1 a atteint sa fin de vie côté PHP. C'est à Ubuntu de dire si et quand un correctif sera publié ; surveillez ses avis de sécurité.
  • Où chercher : le Debian Security Tracker et les avis de sécurité Ubuntu , en cherchant les identifiants CVE ci-dessus.
  • Pour appliquer une mise à jour : exécutez apt update, puis apt list --upgradable et repérez vos paquets PHP. apt changelog <paquet> indique quelles CVE un paquet donné corrige.
  • Dépôts tiers. Si vous avez installé PHP depuis un dépôt externe ou un PPA plutôt que depuis Debian ou Ubuntu, consultez l'annonce de ce dépôt. Nous n'avons vu aucune déclaration de leur part.

Après la mise à jour

  • Redémarrez tous les processus PHP, afin que les processus en cours utilisent le nouveau code.
  • Si vous n'utilisez pas la progression des téléversements de session, conservez session.upload_progress.enabled=0 même après la mise à jour : l'avis sur CVE-2026-109619 le recommande.
  • Des attaques ont été signalées avant que le correctif soit public : la mise à jour seule ne prouve donc pas que vous n'avez pas été compromis. Examinez les journaux du serveur web et des applications à partir du 20 octobre, et recherchez des fichiers, des processus et des connexions sortantes inattendus.

Comment Exosys peut vous aider

  • Mise à jour d'urgence des serveurs et conteneurs PHP, dans le cadre de notre offre Infrastructure sécurisée.
  • Évaluation de compromission si vous pensez que quelque chose s'est déjà produit.
  • Audit du code de vos applications PHP pour le long terme, avec notre service d'audit logiciel.

Si vous ne savez pas si vous êtes concerné, ou si vous souhaitez de l'aide, appelez-nous au +41 27 508 02 86 ou écrivez-nous. Indiquez que votre demande concerne php2shell, nous nous occupons du reste.

Nous contacter au sujet de php2shell

Sources