Questions et réponses

Toutes les versions antérieures à 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les chercheurs ont trouvé du code concerné jusqu’à PHP 5.4, et presque toutes les versions intermédiaires sont touchées par au moins l’une des deux CVE.

PHP 8.1, 8.0, 7.x et 5.x sont en fin de vie et ne reçoivent pas de nouvelle version. L’équipe PHP a publié des rétroportages source minimaux pour 7.4, 8.0 et 8.1 à l’intention de ceux qui compilent PHP eux-mêmes ; les éditeurs d’OS à support étendu livrent leurs propres paquets corrigés.

Non. Ce n’étaient que les cibles de démonstration. Le bug est dans l’interpréteur PHP : tout site sur un PHP vulnérable — Laravel, Symfony, Magento, Moodle, Nextcloud, MediaWiki, développements maison, même un script « Hello World » — est exposé.

Non. Les attaques démontrées fonctionnent avant authentification et avec de simples requêtes HTTP. Aucune connexion, extension ou point d’accès particulier n’est nécessaire.

Les deux. Apache avec mod_php est le plus clairement exploitable (RCE confirmée pour les deux CVE avec les limites par défaut). Sur PHP-FPM, la RCE via le chemin des sessions a été confirmée, et le chemin OOM est vulnérable d’après l’analyse. FrankenPHP et LiteSpeed LSAPI sont jugés probablement exposés.

Les avis portent sur le traitement des requêtes web. Les scripts CLI ne sont pas atteints par des requêtes HTTP en usage normal, mais ils viennent du même paquet et sont donc mis à jour de toute façon. Les workers de longue durée qui servent des requêtes (Octane, RoadRunner, Swoole, mode worker de FrankenPHP) doivent être traités comme exposés au web.

Pas forcément. Debian, Ubuntu, RHEL et SUSE rétroportent les correctifs de sécurité sans changer la version amont (par exemple 8.3.6-0ubuntu0.24.04.x). Cherchez CVE-2026-109618 dans le changelog du paquet — le guide de mise à jour donne les commandes exactes.

Installez une version corrigée de PHP (ou le paquet corrigé de votre éditeur) sur chaque environnement, puis redémarrez PHP-FPM, Apache et tous les processus PHP de longue durée. C’est la seule correction complète. Les mises à jour applicatives et les changements de configuration ne la remplacent pas.

Choisissez un build PHP corrigé et faites confirmer le redémarrage des workers. Pour PHP 8.1 ou antérieur, demandez un rétroportage couvrant les deux CVE ; la branche seule ne prouve pas la correction.

Vérifiez si votre éditeur d’OS (RHEL, Ubuntu Pro / ESM, Debian LTS, CloudLinux) fournit un paquet corrigé — les éditeurs LTS ont reçu les correctifs en avance. Si vous compilez PHP vous-même, appliquez le rétroportage source de l’équipe PHP pour 7.4, 8.0 ou 8.1. En attendant, appliquez les atténuations temporaires, gardez un WAF devant et planifiez la migration vers 8.4 ou 8.5.

En partie. Cloudflare, Akamai, Imperva et d’autres ont publié des règles ou des recommandations, et Cloudflare couvre aussi son offre Free. Mais la couverture dépend du fournisseur et du chemin d’attaque, et les attaquants modifient déjà leurs charges pour les contourner. Voyez le WAF comme du temps gagné pour corriger, pas comme la correction.

Ce sont des versions correctives au sein de la même branche : la compatibilité des applications n’est normalement pas affectée. Un changement de comportement : la nouvelle limite mémoire stricte termine immédiatement le processus, si bien que les fonctions d’arrêt ne s’exécutent pas dans ce cas. Testez les chemins gourmands en mémoire.

Tout ce qui se trouve dans la mémoire du worker PHP : mots de passe de base de données, clés d’API, cookies de session, données de requêtes d’autres utilisateurs, ainsi que des certificats ou clés chargés par PHP. Ce chemin ne nécessite pas d’exécution de code : il est donc plus discret.

Cloudflare a signalé de premières attaques le 21 octobre 2026, avec des charges modifiées pour contourner les règles, et watchTowr a fait état d’exploitation dans ses honeypots. Aucune compromission confirmée n’avait été publiée. L’embargo a fuité avant la publication : partez du principe que des attaquants compétents disposent d’exploits fonctionnels.

Pas avec certitude. Les signaux utiles sont des erreurs fatales de limite mémoire après des requêtes multipart, des rafales de HTTP 500, des segfaults de workers et des cookies PHPSESSID anormalement longs ou encodés en pourcentage. Leur absence ne prouve pas que vous êtes protégé, et les journaux applicatifs peuvent ne rien montrer puisque le bug s’exécute sous l’application.

Préservez les journaux, corrigez ou isolez l’hôte (le reconstruire depuis une image saine est l’idéal), renouvelez tous les secrets que PHP pouvait voir en mémoire, invalidez les sessions et vérifiez à quoi ces identifiants donnent accès.

php2shell est le nom du script d’exploitation combiné utilisé par les chercheurs pour démontrer une exécution de code à distance sans authentification sur WordPress, Drupal et Joomla. Le nom est aussi devenu celui des travaux de recherche.

Wiz Research, OpenAI Codex Security et Calif, qui ont signalé les failles indépendamment entre août et septembre 2026, pendant que l’équipe sécurité de PHP développait le correctif. Selon Wiz, des modèles d’IA ont aidé à la découverte, au développement des exploits et à la validation du correctif.

Les identifiants CVE ont fuité avant la publication avec un score erroné de 10.0. Le score CVSS 4.0 officiel des deux CVE est 9.2.