FAQ
FAQ PHP2Shell : les questions des exploitants sur la faille PHP
Les réponses suivent les sources publiques liées ci-dessous. Lorsque celles-ci se contredisent, la réponse le dit au lieu de faire une moyenne.
Dernière mise à jour
Qu’est-ce que PHP2Shell ?
Un nom collectif pour CVE-2026-109618 et CVE-2026-109619, deux vulnérabilités critiques du moteur PHP. Selon le projet PHP, elles peuvent permettre une exécution de code à distance sans authentification sur un PHP qui sert des requêtes web. La CISA écrit le surnom « php2shell ».
Quelles versions sont corrigées ?
PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, ou des versions ultérieures de ces branches. Elles sont parues le 21 octobre 2026. PHP 8.1 et antérieures n’ont reçu aucune version officielle. Des rétroportages minimaux du code source existent pour 7.4, 8.0 et 8.1.
Une mise à niveau est-elle la seule solution complète ?
Oui, selon le projet PHP et AWS. Modifier memory_limit, réduire post_max_size, désactiver la progression d’envoi de session et utiliser un pare-feu applicatif web sont des mesures provisoires. Selon PHP, elles ne rendent pas une installation sûre.
mod_php et PHP-FPM sont-ils tous deux affectés ?
PHP cite les deux, ainsi que php-cgi, FrankenPHP et LiteSpeed. Le risque le plus élevé concerne mod_php, avec un exploit démontré sans authentification avant le code applicatif. FPM est également concerné. La PHP Foundation et oss-security pondèrent FPM un peu différemment ; toutes deux disent qu’il faut corriger FPM.
La faille est-elle exploitée ?
Des tentatives : oui, selon AWS, Cloudflare et watchTowr. AWS date une tentative sur honeypot du 17 octobre 2026, quatre jours avant la divulgation. Aucune compromission réussie de systèmes de production réels n’a été confirmée ni par l’alerte de la CISA, ni par l’article de SecurityWeek sur les capteurs de watchTowr, ni par l’article d’AWS (le succès sur de vrais systèmes est incertain), ni par la note client d’Expel au 21 octobre, 20 h 00 UTC.
Les CVE figurent-elles au catalogue Known Exploited Vulnerabilities de la CISA ?
Selon Expel, aucune des deux n’y figurait le 21 octobre 2026 à 20 h 00 UTC. Tanium décrit une mise à jour du catalogue le même jour à 14 h 04 UTC sans les deux. La FAQ de watchTowr du 22 octobre indique toujours : non listées. Consultez le catalogue actuel ; ce site ne l’interroge pas à chaque visite.
Et PHP 8.1 et antérieures, y compris PHP 5 ?
Il n’existe pour elles aucune version officielle du 21 octobre. Wiz, Google Cloud et Cloudflare décrivent des versions affectées de PHP 5.4 jusqu’aux builds 8.5 non corrigés. watchTowr parlait de PHP 5 et plus. Expel note que PHP n’a pas explicitement confirmé 7.3 et antérieures dans les éléments consultés, et conseille néanmoins de traiter PHP non maintenu exposé au web comme à risque. Mettez à jour ou déconnectez.
Un WAF remplace-t-il le correctif ?
Non. La CISA indique qu’un WAF peut offrir une certaine protection jusqu’au correctif. Cloudflare a déployé des règles et conseille tout de même à ses clients de corriger. Selon le projet PHP, seule une mise à jour est complète.
Combien de serveurs sont exposés ?
The Record rapporte une analyse VirusTotal d’environ 5,1 millions d’adresses IP faisant tourner PHP – pas 5,1 millions d’hôtes vulnérables confirmés. Selon ThreatCluster, environ 1,1 million d’entre elles indiquent une version. Wiz et Cloudflare citent séparément la part de PHP parmi les sites web, proche de 70 %. Ce sont des mesures différentes.
Publiez-vous du code d’exploitation ou une preuve de concept ?
Non. Des rapports publics indiquent qu’un code de preuve de concept existe. Expel avertit qu’une partie du code en circulation n’est pas vérifiée et peut être malveillante. Ce site renvoie vers des avis et n’héberge ni charges utiles ni guides d’attaque.
Est-ce un site officiel de PHP, de la NVD ou de la CISA ?
Non. phpvulnerabilities.app est une note indépendante sans lien avec le PHP Group, php.net, la NVD, le NIST ou la CISA. Lisez les avis liés avant d’agir et donnez-leur la priorité en cas de contradiction.
Et si je ne peux pas corriger aujourd’hui ?
La CISA conseille de déconnecter le PHP exposé publiquement jusqu’à la mise à jour, en particulier PHP 8.1 et antérieures. S’il doit fonctionner brièvement, appliquez les réglages incomplets de la page de remédiation, placez un WAF devant et planifiez la mise à niveau en heures plutôt que dans une fenêtre de correctifs de 30 jours. Ce dernier point est la leçon qu’AWS tire de cet événement, pas une promesse que quelques heures suffisent toujours.
Sources
Les liens externes quittent ce site. Nous n’hébergeons aucun code d’exploitation.
- News archive 2026: security advisory, 21 October 2026 — PHP project (php.net)
- Critical vulnerabilities in PHP require immediate patching (21 October 2026) — CISA
- Known Exploited Vulnerabilities catalog — CISA
- Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot — AWS Security Blog
- Cloudflare deploys protections against php2shell vulnerability — Cloudflare
- FAQ: PHP2Shell CVE-2026-109618 and CVE-2026-109619 (published 20 October 2026, updated 22 October 2026) — watchTowr
- Notice: php2shell, critical PHP vulnerabilities (status as of 21 October 2026, 20:00 UTC) — Expel
- PHP2Shell patches land as first exploitation attempts hit sensors — SecurityWeek
- PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet — Wiz Research
- Sizing the PHP exposure window for CVE-2026-109618 and CVE-2026-109619 — ThreatCluster (VirusTotal Internet scanning write-up)
- PHP says AI review of critical bugs first sparked alarm in August, but signs surfaced in 2024 — The Record