En bref : la chronologie de PHP2Shell comprend pour l'instant quatre dates documentées : une première tentative d'attaque observée le 17 octobre, l'annonce préalable de php.net le 20 octobre, les correctifs le 21 octobre à 16 h, heure allemande, et un nouvel avis sur CVE-2026-115560 le 23 octobre 2026. Pour les exploitants, cela signifie : appliquer le correctif, redémarrer tous les processus PHP et sauvegarder les journaux au plus tard à partir du 20 octobre.
Pourquoi une chronologie PHP2Shell importe aux exploitants
Pour une faille de cette gravité, il ne suffit pas de savoir si votre serveur est corrigé aujourd'hui. La durée pendant laquelle il est resté vulnérable auparavant est tout aussi décisive. Cette fenêtre détermine quels journaux vous sauvegardez, quels fichiers vous contrôlez et si vous pouvez, à bon droit, exclure une compromission.
PHP2Shell concerne PHP lui-même, pas un CMS en particulier. Deux failles critiques, CVE-2026-109618 et CVE-2026-109619, permettent l'exécution de code malveillant à distance sans authentification. Toutes deux sont évaluées à 9.2 selon CVSS v4.0. Vous trouverez une introduction claire sous Qu'est-ce que PHP2Shell ?.
La chronologie suivante ne contient que des dates documentées au 25 octobre 2026. Lorsqu'une information repose sur des articles de presse, cela est indiqué.
| Date | Événement | Source |
|---|---|---|
| 17 octobre 2026 | Première tentative d'attaque observée (Amazon) | Articles de presse |
| 20 octobre 2026 | Annonce préalable par php.net | php.net |
| 21 octobre 2026, 14 h 00 UTC | Publication des correctifs (16 h, heure allemande) | php.net |
| 23 octobre 2026 | Avis sur CVE-2026-115560 | php.net |
| 25 octobre 2026 | Date de cet aperçu | – |
17 octobre : la première tentative d'attaque observée
Selon des articles de presse, une première tentative d'attaque a été observée le 17 octobre 2026, signalée par Amazon. C'était quatre jours avant les correctifs. Il y a donc eu une période pendant laquelle des attaques étaient déjà tentées, alors qu'aucune mise à jour n'existait encore.
On ne sait pas si, ni combien, d'attaques ont réussi pendant cette phase. Ce qui compte, c'est la conséquence pour votre propre contrôle : un serveur corrigé aujourd'hui peut avoir été compromis auparavant. Un correctif ne supprime aucun logiciel malveillant déjà introduit et ne prouve pas que rien ne s'est produit avant.
20 et 21 octobre : annonce préalable et correctifs
Le 20 octobre 2026, le projet PHP a annoncé les mises à jour de sécurité sur php.net. Le 21 octobre 2026 à 14 h 00 UTC, soit 16 h, heure allemande, les versions corrigées ont suivi.
| Branche | Dernier état vulnérable | Corrigée dans |
|---|---|---|
| PHP 8.5 | 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.34 | 8.2.35 |
Pour PHP 8.1 et antérieur, il n'existe plus de mises à jour officielles, seulement des backports minimaux du code source pour 7.4, 8.0 et 8.1. Selon la presse spécialisée, presque toutes les versions jusqu'à PHP 5.4 sont concernées. Les modes d'exécution concernés sont PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L'équipe PHP voit le risque le plus élevé avec mod_php, où un exploit a été démontré avant même l'exécution du code applicatif.
Les distributions et les hébergeurs intègrent parfois des backports. Plesk peut alors continuer d'afficher 8.2.34 alors que le serveur est corrigé. Ce qui compte, c'est l'état des paquets et la confirmation du fournisseur, pas le numéro de version affiché. La façon de le vérifier proprement figure sous Vérifier correctement la version de PHP et l'état du correctif.
23 octobre : avis sur CVE-2026-115560
Le 23 octobre 2026, le projet PHP a publié un nouvel avis, cette fois sur CVE-2026-115560. Une exploitation n'est possible, selon cet avis, que dans une configuration inhabituelle : le serialize_handler php_binary ou php_serialize figure dans la configuration, l'application le repasse sur php par ini_set() avant session_start(), et le suivi de progression de l'envoi de session est actif.
Le contournement est simple et devrait être appliqué, que vous connaissiez ou non cette configuration chez vous :
; dans php.ini, dans le pool FPM ou dans la configuration du serveur
; pas par ini_set() ni .user.ini
session.upload_progress.enabled = 0
Redémarrez ensuite tous les workers PHP. L'avis complet doit suivre avec la prochaine version corrective régulière. D'ici là, ce réglage reste la solution transitoire recommandée.
Situation au 25 octobre : état des lieux et questions ouvertes
Le BSI (office fédéral allemand de la sécurité des technologies de l'information) a déclenché le niveau d'alerte 3 / orange. Il recommande la mise à jour immédiate et, si elle n'est pas possible tout de suite, de déconnecter temporairement les serveurs web du réseau. Le BSI s'attendait à une exploitation rapide et à grande échelle ; selon lui, aucune attaque réussie à grande échelle n'était d'abord confirmée. L'évaluation du BSI est résumée sur la page Ce que le BSI recommande pour PHP2Shell.
Cloudflare a signalé des tentatives d'attaque observées et a déployé des règles de protection, mais prévient que des règles fondées sur les seules données de la requête ne suffisent pas. Palo Alto Networks (Unit 42) a dénombré plus de 22,6 millions d'instances exposées et potentiellement vulnérables. Aucun indicateur de compromission confirmé n'a été publié ; la détection repose sur l'analyse du comportement.
Certains fournisseurs ont mis des sites hors ligne par précaution. Cela ne signifie pas automatiquement que ces sites ont été piratés. La principale question ouverte, à la date de cet aperçu, est de savoir combien de serveurs ont réellement été compromis avant le correctif.
Ce que la chronologie signifie pour vos journaux et vos contrôles
Les dates font apparaître trois périodes : avant le 17 octobre, entre le 17 octobre et le moment de votre propre correctif et redémarrage, puis après. La période intermédiaire est la période critique. Plus elle a duré chez vous, plus le contrôle doit être approfondi.
La presse spécialisée conseille de conserver les journaux du serveur à partir du 20 octobre 2026. Sauvegardez aussi les journaux plus anciens disponibles avant que la rotation automatique ne les supprime.
Un moyen simple de sauvegarder les journaux sans les modifier et de consigner l'état :
# Sauvegarder les journaux en une fois (adapter les chemins à votre système)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Somme de contrôle pour la preuve ultérieure
sha256sum /root/logs-sicherung-*.tar.gz
# Pendant combien de temps le système conserve-t-il les journaux ?
grep -R "rotate" /etc/logrotate.d/
Notez en outre à quel moment exact la mise à jour a été installée et à quel moment les processus PHP ont été redémarrés. Les nouveaux fichiers ne protègent pas tant que d'anciens processus tournent en mémoire. L'article Analyser les journaux du serveur web après une attaque explique comment exploiter les journaux sauvegardés.
Comment PHP SOS aide-t-il concrètement ?
- Nous déterminons avec vous la fenêtre de vulnérabilité réelle de votre serveur : état des paquets, moment du correctif, redémarrage de tous les workers.
- Nous sauvegardons les journaux et l'état du système de façon traçable avant que quoi que ce soit ne soit modifié.
- Nous recherchons les anomalies de comportement comme de nouveaux fichiers PHP, des processus étrangers et des connexions sortantes inhabituelles.
- Nous documentons le résultat de façon exploitable par la direction, les délégués à la protection des données et les assureurs.
Notre assistance d'urgence PHP2Shell décrit le déroulement dans le détail.
Questions fréquentes
Quand les correctifs PHP2Shell ont-ils été publiés ?
Le projet PHP a publié les versions corrigées le 21 octobre 2026 à 14 h 00 UTC, soit 16 h, heure allemande. Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
À partir de quelle date dois-je conserver les journaux du serveur ?
La presse spécialisée conseille de conserver les journaux à partir du 20 octobre 2026. Comme une première tentative d'attaque aurait déjà été observée le 17 octobre selon des articles de presse, il est utile de sauvegarder aussi les journaux plus anciens encore disponibles avant que la rotation ne les supprime.
CVE-2026-115560 est-elle aussi dangereuse que les deux premières failles ?
Selon l'avis du 23 octobre 2026, une exploitation n'est possible qu'avec une configuration de session inhabituelle. Le contournement est session.upload_progress.enabled=0 jusqu'à la prochaine version corrective régulière.
Existe-t-il des indicateurs de compromission confirmés pour PHP2Shell ?
Non, au 25 octobre 2026, aucun indicateur de compromission confirmé n'a été publié. La détection repose sur l'analyse du comportement, par exemple des processus inhabituels, de nouveaux fichiers et des connexions suspectes.