En bref : une semaine après la première tentative d'attaque observée, PHP2Shell est surtout une question de mise en œuvre : des correctifs pour PHP 8.2 à 8.5 existent depuis le 21 octobre, les grandes distributions ont suivi, le BSI (office fédéral allemand de la sécurité des technologies de l'information) alerte au niveau orange. Des tentatives d'attaque ont été observées, le BSI n'a pas signalé dans un premier temps d'attaques réussies confirmées à grande échelle. Restent ouverts : les anciennes versions, les serveurs non redémarrés et la question de ce qui s'est passé avant le correctif.
La situation en trois phrases
PHP2Shell, ce sont deux failles critiques dans l'interpréteur PHP lui-même, CVE-2026-109618 et CVE-2026-109619, évaluées chacune CVSS v4.0 9,2. Elles permettent l'exécution de code à distance sans authentification, c'est-à-dire le cas que les professionnels de la sécurité redoutent le plus. Sont concernés PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed ; l'équipe PHP voit le risque le plus élevé avec mod_php.
Cet aperçu classe l'état au 25 octobre 2026 par acteurs. Le déroulement jour par jour figure dans la chronologie de PHP2Shell, ici il s'agit du tableau d'ensemble.
Ce qui est établi après une semaine
Les indications du projet PHP sont sûres : les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 du 21 octobre ferment les deux failles. Pour PHP 7.4, 8.0 et 8.1, il n'existe que des rétroportages minimaux du code source, aucune version officielle. php.net souligne qu'il n'existe pas de mesures transitoires complètes et que la mise à jour est la seule voie sûre.
Le 23 octobre est venu s'ajouter un avis sur CVE-2026-115560. Il ne concerne qu'une configuration de session inhabituelle ; comme remède, php.net indique session.upload_progress.enabled=0 jusqu'à la prochaine version corrective régulière.
Les grandes distributions ont également pris position. Nous avons vérifié les avis officiels :
| Fournisseur | État selon l'avis officiel |
|---|---|
| Ubuntu | USN-8948-1 pour 22.04, 24.04, 26.04 et 26.10 ; USN-8948-2 pour 14.04 à 20.04 via Ubuntu Pro |
| Debian | paquets corrigés pour bookworm (php8.2, DLA-4848-1) et trixie (php8.4, DSA-6574-1) |
| Red Hat | bulletin RHSB-2026-013 pour RHEL 7 à 10 ; certaines mises à jour disponibles, d'autres en cours |
Red Hat classe CVE-2026-109618 « Important » selon sa propre évaluation et le justifie par une plus grande complexité d'attaque. C'est une autre méthode d'évaluation que celle du projet PHP et aucune raison de reporter la mise à jour.
Comment les autorités évaluent la situation
Le BSI a déclaré le niveau d'alerte 3 / orange. Il recommande la mise à jour immédiate et, si elle n'est pas possible tout de suite, de mettre temporairement hors réseau les serveurs web concernés. Le BSI s'attendait à une exploitation rapide et à grande échelle. Ce que signifie ce classement est expliqué sur la page Ce que le BSI recommande pour PHP2Shell.
Selon des rapports, CERT-EU juge possible que les versions à partir de PHP 5 soient concernées et conseille d'isoler les applications accessibles publiquement si elles ne peuvent pas être corrigées rapidement. CERT-Bund et la société de sécurité Huntress ont également lancé des alertes.
La recommandation de couper au besoin a été visiblement appliquée. Selon des articles de presse, la ville de Mayence a mis son portail web central hors réseau par précaution ; les services sont restés joignables par téléphone et e-mail. En Hesse, selon hessenschau, des sites du gouvernement du Land, du BKA (office fédéral allemand de la police criminelle) ainsi que des villes de Cassel et de Wiesbaden ont été temporairement hors ligne. La chancellerie d'État n'a signalé aucune attaque, les sites étaient de nouveau accessibles le soir. D'autres communes, établissements d'enseignement supérieur et cliniques ont agi de même selon des rapports.
Ce que l'on sait des attaques
Ici, la séparation entre observation et confirmation est particulièrement importante.
- Observé : selon des articles de presse, une première tentative d'attaque a eu lieu le 17 octobre, observée par Amazon. Cloudflare et Patchstack ont fait état de tentatives d'attaque ; Cloudflare a en outre vu des schémas d'attaque modifiés.
- Reproduit : watchTowr a reproduit CVE-2026-109618, selon des rapports et selon ses propres indications.
- Non confirmé : le BSI n'a pas signalé dans un premier temps d'exploitations réussies confirmées à grande échelle. Au moment de son communiqué, Huntress ne voyait aucune attaque dans les environnements de ses partenaires.
- Inconnu : il n'existe pas d'indicateurs de compromission publiés et confirmés. Qui veut vérifier si un serveur est concerné doit surveiller des schémas de comportement.
Deux chiffres circulent sur l'ampleur. Les chercheurs d'Unit 42 chez Palo Alto Networks sont arrivés à plus de 22,6 millions d'instances potentiellement vulnérables accessibles depuis le réseau. CybelAngel cite environ 2,24 millions d'hôtes PHP accessibles, dont, selon sa propre analyse, 59 pour cent sur des versions sans correctif officiel à venir. Les deux mesurent des choses différentes et ne sont pas directement comparables. L'article Bien interpréter les chiffres en propose une mise en contexte.
Ce qui reste ouvert
Trois questions détermineront les prochaines semaines :
- Anciennes versions : une grande partie des installations PHP accessibles tourne, selon les analyses citées, sur des branches sans correctif officiel. Savoir si des offres commerciales de support à long terme couvrent PHP2Shell doit à chaque fois être confirmé par écrit auprès du fournisseur.
- Mises à jour incomplètes : les nouveaux paquets n'agissent que lorsque tous les processus PHP sont redémarrés. Red Hat souligne expressément qu'un simple rechargement ne suffit pas.
- La période avant le correctif : entre le 17 et le 21 octobre, des serveurs étaient vulnérables alors que des tentatives d'attaque étaient déjà en cours. Un correctif ne prouve pas que rien ne s'est passé pendant cette période.
Conservez les journaux du serveur web et de PHP à partir du 20 octobre, comme le recommande la presse spécialisée. Sans journaux, la plus importante question ouverte pour votre serveur ne pourra plus être tranchée ultérieurement.
Ce que les exploitants devraient vérifier maintenant
Pour votre propre évaluation de la situation, quatre points de contrôle par serveur suffisent : PHP est-il à un niveau corrigé ou à un rétroportage confirmé ? Tous les processus tournent-ils depuis la mise à jour ? session.upload_progress.enabled est-il désactivé côté serveur tant que l'avis sur CVE-2026-115560 est en attente ? Y a-t-il des anomalies depuis le 17 octobre ?
Pour le dernier point, la page Suis-je déjà compromis ? aide. Un processus du serveur web qui lance un shell, de nouveaux fichiers PHP dans les dossiers d'envoi, des tâches cron ou des clés SSH inconnues sont des signaux d'alerte qui justifient un examen plus approfondi.
Comment PHP SOS aide-t-il concrètement ?
- Nous évaluons le niveau de correctif de chaque serveur à partir du niveau des paquets, du changelog et des heures de démarrage des processus.
- Là où aucun correctif n'est disponible, nous appliquons les mesures transitoires de php.net et clarifions la voie vers la version prise en charge.
- Nous sauvegardons les journaux à partir du 20 octobre et recherchons des traces de la période précédant le correctif.
- Avec l'assistance immédiate PHP2Shell, nous regroupons ces étapes pour les entreprises qui ont besoin rapidement de clarté.
Questions fréquentes
PHP2Shell est-elle déjà activement exploitée ?
Cloudflare et Patchstack ont fait état de tentatives d'attaque. Le BSI n'a pas signalé dans un premier temps d'attaques réussies confirmées à grande échelle. Au moment de son communiqué, Huntress ne voyait aucune attaque dans les environnements de ses partenaires.
Le danger est-il écarté après les correctifs ?
Non. Les correctifs ne protègent que les serveurs qui les ont installés et ont redémarré tous les processus PHP. Les systèmes sous PHP 8.1 et plus ancien restent vulnérables sans rétroportage confirmé, et un correctif ne supprime pas un logiciel malveillant introduit auparavant.
Pourquoi des sites d'autorités étaient-ils hors ligne ?
Selon des articles de presse, la ville de Mayence et plusieurs services en Hesse, entre autres, ont mis leurs sites hors ligne par précaution. Cela correspond à la recommandation du BSI pour les serveurs qui ne peuvent pas être mis à jour immédiatement. Une mise hors ligne ne signifie pas qu'une attaque a eu lieu.
Existe-t-il des indicateurs pour reconnaître une attaque PHP2Shell ?
Aucun indicateur de compromission (IoC) publié et confirmé n'existe à ce jour. La détection repose sur l'analyse du comportement, par exemple des processus PHP qui lancent un shell ou de nouveaux fichiers PHP dans les dossiers d'envoi (uploads).