En bref :

Produit / Composant	Versions concernées	Intégré dans
PHP 8.5	avant 8.5.12	8.5.12
PHP 8.4	avant 8.4.27	8.4.27
PHP 8.3	avant 8.3.36	8.3.36
PHP 8.2	avant 8.2.35	8.2.35
PHP 8.1 et antérieur	concernés, plus aucun support officiel	pas de version officielle ; backports de source pour 7.4, 8.0 et 8.1

• Points faibles : CVE-2026-109618 et CVE-2026-109619 (statut CVSS 9.2, (critique)
• Exploit : Proof of Concept public ; selon Amazon, exploitation large, une première tentative d'attaque déjà le 17 octobre.
• Patch disponible depuis : 21.10.2026, des paquets pour Debian et Ubuntu déjà disponibles.
• Criticité BSI : 3 / Orange (BITS-H 2026-297981-1132, version 1.1)

Chronologie : Ce qui s'est passé jusqu'à présent.

• 17 octobre 2026 : Amazon enregistre dans ses honeypots (MadPot) une première tentative d'exploitation, quatre jours avant la publication.
• 20 octobre 2026 : Les détails des vulnérabilités sont révélés prématurément. Le projet PHP annonce une version de sécurité d'urgence.
• 21 octobre 2026, 16:00 CEST : PHP publie les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ainsi que les avis techniques. Les découvreurs de Wiz Research, OpenAI Codex Security et Calif présentent leur recherche sur php2shell.com.
• 21 octobre 2026 : CERT-EU et BSI avertissent, le BSI classe la situation comme Orange et signale dans la version 1.1 un Proof of Concept public. Ubuntu publie des paquets corrigés (USN-8948-1), Debian met également des paquets à disposition. Certains opérateurs en Allemagne retirent les sites Web par mesure de précaution.
• Depuis le 21 octobre 2026 : Selon Amazon, PHP2Shell est largement exploité. Le RUS-CERT de l'université de Stuttgart a vérifié un exploit public sur un système de test.

Quel logiciel est concerné ?

La vulnérabilité se trouve dans PHP lui-même, et non dans une application particulière. Par conséquent, tout logiciel fonctionnant sur une version vulnérable de PHP est concerné : systèmes de gestion de contenu tels que WordPress, Drupal, TYPO3 et Joomla, boutiques comme Magento, Shopware et WooCommerce, Nextcloud, Moodle, MediaWiki et des applications développées sur Laravel ou Symfony. Selon les découvreurs, une simple page „ Hello World “ sur une version vulnérable de PHP est suffisante. Une mise à jour de l'application seule ne résout pas le problème, il est crucial de considérer l'environnement d'exécution PHP sous-jacent.

Le BSI souligne également que PHP se trouve dans des composants de produits et d'appareils propriétaires, notamment dans les distributions de pare-feu pfSense et OPNsense. Le NCSC néerlandais compile sur GitHub une liste de produits concernés, qui est régulièrement mise à jour.

Sont menacées, selon l'avis PHP, toutes les installations PHP traitant des requêtes Web, y compris PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet PHP estime le risque le plus élevé avec mod_php il y a un exploit démontré, où une requête sans authentification déclenche l'attaque avant même que le code de l'application ne soit exécuté.

PHP-FPM est également affecté. Pour CVE-2026-109619, l'exécution de code à distance a également été démontrée contre PHP-FPM selon l'avis de GitHub, via la fonction Session Upload Progress activée par défaut. Cependant, cette méthode nécessite une opération appropriée dans l'application. Red Hat classe la vulnérabilité comme moins critique pour sa distribution („ Important “) : sous Red Hat Enterprise Linux, PHP-FPM fonctionne par défaut, et l'exécution de code y est en pratique difficile.

Que peuvent atteindre les attaquants avec l'exploit.

• Exécuter du code : En cas d'exploitation réussie, les attaquants exécutent du code avec les droits du compte Web Worker. Les découvreurs ont démontré cela sans connexion contre les images de conteneurs actuelles de WordPress, Drupal et Joomla.
• Lire la mémoire : CVE-2026-109619 permet également de lire la mémoire du processus PHP, sans exécuter de code. Selon les découvreurs, cela peut contenir des mots de passe, des jetons d'authentification, des clés API et des certificats d'autres requêtes ou du serveur. De telles attaques sont plus difficiles à détecter.

Les deux vulnérabilités en détail :

• CVE-2026-109618 – Exécution de code à distance via des erreurs d'Out-of-Memory (GHSA-w8hw-w9fx-j79w) : Si PHP interrompt une requête en raison d'un manque de mémoire, alors que les données de requête internes sont seulement partiellement initialisées, la routine de nettoyage peut traiter ces données invalides comme valides. Selon l'advisory, le manque de mémoire peut être induit entre autres par des requêtes Multipart préparées.
• CVE-2026-109619 – Exécution de code à distance via un état global obsolète (GHSA-6wmf-4rv5-p3rp) : Un état appartenant à une requête peut survivre dans le processus de travail après que sa mémoire a déjà été libérée. Une requête ultérieure dans le même travail peut utiliser cet état avant qu'il ne soit réinitialisé (Use-after-free).

L'évaluation CVSS indique une complexité d'attaque élevée. Avec des exploits publics et des attaques en cours, cela n'a pratiquement plus d'importance dans la pratique. Unit 42 de Palo Alto Networks compte, selon ses propres données de télémétrie, plus de 22,6 millions d'instances accessibles depuis Internet, potentiellement vulnérables.

Trouver les systèmes PHP affectés dans l'inventaire

Qui veut patcher rapidement doit d'abord savoir où PHP fonctionne. Un inventaire complet comprend non seulement les serveurs Web connus, mais aussi les sous-domaines, les anciens systèmes, les environnements de test, les conteneurs Docker, les appareils avec PHP intégré et les sites Web chez des hébergeurs externes ou des fournisseurs de services.

Comment vérifier la version de PHP ?

• Sur le serveur : php -v affiche la version de la ligne de commande. Le serveur Web peut utiliser une autre version. Pour PHP-FPM, vérifiez donc également la version FPM, selon la distribution, par exemple avec php-fpm -v ou php-fpm8.3 -v.
• Paquets installés : sous Debian et Ubuntu avec dpkg -l | grep php, sous Red Hat et systèmes apparentés avec rpm -qa | grep php. La version du paquet de la distribution est déterminante, pas le numéro de version de PHP lui-même.
• Docker : La version de PHP se trouve dans l'image. Les images doivent être mises à jour ou reconstruites, une mise à jour sur l'hôte ne suffit pas.
• De l'extérieur : certains serveurs révèlent la version de PHP dans l'en-tête HTTP X-Powered-By. L'absence de l'en-tête ne signifie pas qu'aucun PHP ne fonctionne.

Paquets patchés des distributions Linux

Distribution	Paquet	Intégré dans
Debian 13 (trixie)	php8.4	8.4.27-1~deb13u1
Debian 12 (bookworm)	php8.2	8.2.35-1~deb12u1
Ubuntu 26.10	php8.5	8.5.9-0ubuntu2.1
Ubuntu 26.04 LTS	php8.5	8.5.4-0ubuntu1.5
Ubuntu 24.04 LTS	php8.3	8.3.6-0ubuntu0.24.04.13
Ubuntu 22.04 LTS	php8.1	8.1.2-1ubuntu2.28
Ubuntu 20.04 LTS et antérieur	php7.4 et antérieur	Correction uniquement via Ubuntu Pro

Les distributions réintègrent la correction dans leurs propres paquets. Un serveur Ubuntu avec „ PHP 8.3.6 “ peut donc être patché, bien que le numéro de version semble plus ancien que 8.3.36. Pour Red Hat Enterprise Linux, le conseil de Red Hat s'applique.

Que faire maintenant

• Sur PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 Mettre à jour ou installer les paquets patchés de la distribution.
• Pour ceux qui utilisent le dépôt maintenu de manière facultative rpms.remirepo.net : Selon le projet PHP, il n'y a pas eu de mises à jour le jour de la sortie. Le projet PHP recommande de passer à des paquets de distribution ou de construire à partir du code source.
• Après la mise à jour, redémarrez tous les workers PHP, comme les pools PHP-FPM et Apache.
• Ne pas oublier PHP dans les conteneurs Docker et les appareils : reconstruire les images, faire attention à la nouvelle firmware des fabricants pour les appareils.
• Contactez le prestataire d'hébergement si vous ne gérez pas le serveur web vous-même, et demandez une mise en œuvre immédiate.
• PHP 8.1 et plus ancien : le projet PHP ne fournit plus de mises à jour pour cela. Pour PHP 7.4, 8.0 et 8.1, il a fourni des backports minimaux du code source. Selon le BSI, toutes les versions antérieures à 8.2 ont atteint leur fin de vie, PHP 8.2 ne reçoit plus que des mises à jour de sécurité jusqu'à la fin de l'année. Les systèmes affectés devraient être migrés vers une version prise en charge.
• Rechercher des signes d'attaque à partir du 17 octobre 2026.

Là où une mise à jour immédiate n'est pas possible, le RUS-CERT et le BSI recommandent de déconnecter les systèmes affectés d'Internet ou de limiter leur accessibilité jusqu'à ce que les mises à jour soient installées.

Comment reconnaître une attaque ?

Il n'existe pas selon les découvreurs un seul critère qui détecte de manière fiable chaque attaque. Comme indices pour une enquête, ils mentionnent :

• cookies PHPSESSID anormaux ou défectueux dans les réponses du serveur,
• demandes multipart inhabituelles, suivies d’erreurs de mémoire („ memory limit “) ou de réponses HTTP-500 répétées,
• plantages inexplicables ou redémarrages de travailleurs PHP.

Amazon conseille de commencer les investigations non pas à partir de la publication, mais au moins à partir du 17 octobre 2026. En l'absence de telles traces, un système n'est pas exempté : une lecture de la mémoire peut laisser peu de traces dans les journaux d'application. L'BSI n'a jusqu'à présent pas publié d'indicateurs de compromission contraignants. Quiconque trouve des signes d'exploitation doit supposer que les identifiants, tokens et clés du processus PHP peuvent être affectés, et les échanger. Les prestataires de services spécialisés en réponse aux incidents peuvent aider à l'enquête ; l'BSI tient à jour une liste de fournisseurs qualifiés.

Mesures de transition si la mise à jour n'est pas encore possible

Le projet PHP mentionne des mesures pour compliquer certains vecteurs d'attaque. Il souligne expressément que seul la mise à jour constitue une solution complète ; RUS-CERT et l'BSI avertissent également que les mesures peuvent être contournées. Selon l'BSI, toutes les mesures doivent être mises en œuvre conjointement pour rendre une exploitation significativement plus difficile.

• Contre CVE-2026-109618 : memory_limit=-1 le définir de sorte que les applications ne puissent pas écraser la valeur (par exemple via php_admin_value dans le pool FPM ou dans la configuration Apache), et post_max_size maintenir bas (8M sans téléchargements de fichiers, sinon 32M). De plus, définir des limites de taille et de nombre pour les requêtes sur le serveur web ou le proxy.
• Si l'application n'a pas besoin de formulaires Multipart, le projet PHP conseille de bloquer ces requêtes dès le frontend, avant qu'elles n'atteignent PHP.
• Contre CVE-2026-109619 : session.upload_progress.enabled=0 dans la php.ini ou le définir dans le pool FPM et redémarrer tous les workers ; ini_set() et .user.ini ne sont pas suffisants. Sous PHP 8.5, en plus fatal_error_backtraces=0. Ceux qui n'ont pas besoin de Session Upload Progress devraient également désactiver la fonction selon le projet PHP après la mise à jour.
• Si la performance n'est pas un enjeu, le projet PHP mentionne pm.max_requests=1 comme une autre option : chaque worker FPM ne traite alors qu'une seule requête, et un état obsolète ne peut pas passer à la requête suivante.
• Vérifier les journaux d'erreurs avec error_reporting=E_ALL pour les avertissements avant le démarrage du script, les erreurs fatales et „ Maximum execution time exceeded “, et corriger les erreurs trouvées. Un journal sans anomalie n'est cependant pas une preuve qu'un système est sécurisé, selon le projet PHP.
• Firewalls applicatifs : des fournisseurs comme Cloudflare ont publié des règles contre des voies d'attaque connues. Seule la mise à jour ou la déconnexion d'Internet offre une protection complète selon l'BSI.
• Indépendamment de cela, l'BSI recommande d'utiliser SELinux ou AppArmor pour limiter les conséquences d'une exécution de code réussie.

Contexte DACH et européen

Pour les entités dans le champ d'application de la directive NIS-2 : Si une exploitation de ces vulnérabilités entraîne un incident de sécurité majeur, les obligations de notification selon l'Art. 23 de la directive NIS-2 s'appliquent, en Allemagne selon le § 32 BSIG. En Autriche et en Suisse, les obligations de notification nationales respectives s'appliquent. L'BSI a publié un avis de sécurité informatique (BITS-H 2026-297981-1132) avec une criticité Orange concernant ces vulnérabilités ; celui-ci est librement diffusé en tant que TLP:CLEAR.

Comment LocateRisk s'attaque aux actifs exposés

LocateRisk prend en charge la gestion de la surface d'attaque externe en rendant visibles les systèmes accessibles de l'extérieur et les logiciels utilisés. Cet incident peut aider à identifier les serveurs web accessibles publiquement et les installations PHP dans l'inventaire des actifs, même celles qui ne figurent dans aucune liste interne, et à prioriser l'ordre des mises à jour.

LocateRisk ne remplace pas la gestion des correctifs et ne dit rien sur la version PHP vulnérable qui pourrait fonctionner sur un système détecté. Pour cela, il est nécessaire de comparer la version utilisée avec l'avis PHP ou l'état des paquets de la distribution.

Pour les applications web externalisées ou les portails clients, la gestion des risques fournisseurs peut aider à documenter de manière compréhensible les retours des prestataires concernant l'état des correctifs.

Suis-je concerné ?

Sont concernés : PHP avant 8.2.35, 8.3.36, 8.4.27 et 8.5.12 ainsi que toute version PHP antérieure ; la vulnérabilité est corrigée dans 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ou dans les paquets corrigés des distributions. Quiconque souhaite savoir si PHP est visible dans sa propre infrastructure accessible de l'extérieur peut consulter le Vérification rapide CVE à consulter à la fin de cet article : il présente les systèmes exposés et les logiciels identifiables depuis l'extérieur.

Il n'est pas toujours possible de déterminer la version effectivement installée à partir d'éléments externes — il est essentiel de la comparer avec l'avis de sécurité du fabricant.

Sources et informations complémentaires

• PHP / php.net: Alerte de sécurité : vulnérabilités critiques d'exécution de code à distance, mettez à jour maintenant
• PHP / GitHub : GHSA-w8hw-w9fx-j79w : RCE via corruption OOM (CVE-2026-109618)
• PHP / GitHub : GHSA-6wmf-4rv5-p3rp : RCE via état global obsolète (CVE-2026-109619)
• Wiz, OpenAI, Calif: PHP2Shell – page de recherche des découvreurs
• BSI : BSI-IT-Sicherheitshinweis 2026-297981-1132 : PHP : des vulnérabilités critiques menacent les applications web dans le monde entier
• Amazon Threat Intelligence : exploitation de PHP2Shell avant la divulgation publique dans MadPot
• RUS-CERT Université de Stuttgart : Vulnérabilités critiques dans PHP (CVE-2026-109618 et CVE-2026-109619)
• NCSC-NL : php2shell – liste des produits concernés
• Debian : Security Tracker CVE-2026-109618
• Ubuntu : USN-8948-1 : vulnérabilités PHP
• Red Hat : CVE-2026-109618
• Unit 42 : CVE-2026-109618 et CVE-2026-109619
• CERT-EU: Security Advisory 2026-018: Vulnérabilités critiques dans PHP

Date : 22 octobre 2026. Cet article est destiné à des fins d'information générale et ne constitue pas un conseil juridique, de sécurité ou d'action dans des cas particuliers. La situation de sécurité et la disponibilité des correctifs peuvent avoir changé depuis la publication ; l'avis du fabricant lié est toujours déterminant. Malgré des recherches minutieuses, nous déclinerons toute responsabilité quant à l'actualité, l'exactitude et l'exhaustivité.

---