# Le délai entre le correctif et l'attaque

> Le délai entre correctif et attaque expliqué : les phases de PHP2Shell, comment mesurer votre propre fenêtre et avec quelles mesures la raccourcir.

Source : https://phpsos.de/fr/blog/zeitfenster-patch-angriff/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** avec PHP2Shell, le délai entre correctif et attaque a été négatif : selon des articles de presse, une première tentative d'attaque a eu lieu dès le 17 octobre 2026, quatre jours avant les mises à jour. Pour les exploitants, la question n'est donc pas « De combien de temps dispose-t-on ? » mais « Pendant combien de temps mon serveur est-il ouvert ? ». Cette fenêtre personnelle ne se termine que lorsque la mise à jour est installée et tous les processus PHP redémarrés.

## Le point de départ : des attaques avant le correctif

Longtemps, une hypothèse commode a prévalu : entre la mise à jour de sécurité et les premières attaques s'écoulent quelques jours, assez pour la prochaine fenêtre de maintenance. PHP2Shell a réfuté cette hypothèse. Selon des articles de presse citant Amazon, une première tentative d'attaque a déjà été observée le 17 octobre. Cloudflare a lui aussi fait état d'attaques précoces. Les correctifs sont arrivés le 21 octobre à 14h00 UTC.

Cet article explique comment naissent de telles fenêtres et comment raccourcir la vôtre. La suite exacte des dates figure dans la [chronologie de PHP2Shell](https://phpsos.de/fr/ratgeber/php2shell-chronologie/).

## Le délai entre correctif et attaque en phases

Autour d'une faille de sécurité, on peut distinguer plusieurs phases. Avec PHP2Shell, elles se présentaient ainsi :

| Phase | En général | Avec PHP2Shell |
|---|---|---|
| Avant la divulgation | la faille n'est connue que des découvreurs et de l'éditeur | développement de la correction sous embargo |
| Premières attaques sans correctif | des attaquants exploitent la faille avant qu'une mise à jour n'existe | selon des articles de presse, première tentative le 17.10. |
| Pré-annonce | l'éditeur annonce la mise à jour | 20.10., php.net annonce la version |
| Correctif disponible | la mise à jour et l'avis de sécurité paraissent | 21.10., 14h00 UTC |
| Analyse du correctif | chercheurs et attaquants analysent les modifications | watchTowr a reproduit CVE-2026-109618 selon ses propres indications |
| Exploitation à grande échelle | campagnes automatisées contre des serveurs non corrigés | attendue par le BSI ; attaques réussies confirmées à grande échelle non connues dans un premier temps |
| Votre correctif | mise à jour et redémarrage sur vos serveurs | individuel |

La dernière ligne est la seule que vous pouvez influencer. Tout ce qui précède est déterminé par d'autres.

## Pourquoi le correctif lui-même augmente la pression

Une mise à jour de sécurité ferme la faille, mais la rend aussi visible. Les modifications du code source dans les projets open source comme PHP sont publiques. Qui compare les différences entre l'ancienne et la nouvelle version apprend où se trouvait l'erreur. Ce n'est pas un reproche au projet PHP, mais le cas normal des logiciels ouverts et le fondement qui permet aux distributions de construire des rétroportages.

Pour les exploitants, il en découle que chaque jour après le correctif, le nombre de ceux qui savent comment fonctionne la faille augmente. En même temps, le nombre de serveurs non corrigés diminue. Les restants deviennent ainsi les cibles évidentes. La manière dont PHP livre les mises à jour de sécurité dans le cadre de la maintenance de ses versions est expliquée dans l'article sur le [cycle de publication de PHP](https://phpsos.de/fr/php/release-zyklus/).

> **Agir immédiatement:**
> Si votre serveur était accessible entre le 17 octobre et votre correctif, une recherche de traces s'impose. Sauvegardez les journaux à partir du 20 octobre avant qu'ils ne soient perdus par la rotation.

## Mesurer votre propre fenêtre

Votre fenêtre personnelle commence au plus tard avec la publication des correctifs et se termine avec le redémarrage du dernier processus PHP. Consignez pour chaque serveur :

- **Connaissance :** quand quelqu'un dans l'entreprise a-t-il appris l'existence de la faille ?
- **Disponibilité :** quand le paquet de votre distribution ou de votre hébergeur était-il disponible ?
- **Installation :** quand a-t-il été installé ?
- **Redémarrage :** quand n'y avait-il plus d'anciens processus PHP en cours ?

Le redémarrage est justement souvent oublié. Une mise à jour installée n'agit que lorsque les anciens processus sont arrêtés. La manière de le vérifier est décrite dans [Redémarrer PHP-FPM et tous les processus PHP](https://phpsos.de/fr/php2shell/php-fpm-neustart/). Un regard sur les heures de démarrage montre si des processus d'avant la mise à jour tournent encore :

```bash
# Afficher l'heure de démarrage de tous les processus PHP
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
```

Si l'heure de démarrage précède l'installation de la mise à jour, la fenêtre est encore ouverte.

### Pourquoi votre fenêtre dépend de la source des paquets

La rapidité avec laquelle vous pouvez corriger ne dépend pas seulement de vous, mais aussi de la provenance de votre PHP. Selon des rapports, des distributions ont livré des rétroportages parfois dès le 21 octobre. Qui obtient PHP d'un dépôt tiers dépend de son rythme. Qui utilise des conteneurs doit reconstruire et déployer les images, une simple mise à jour dans le conteneur en cours d'exécution ne suffit pas. Et en hébergement mutualisé, c'est l'hébergeur qui détermine le moment.

Si vous connaissez la source des paquets de chaque serveur, vous savez aussi à quel endroit votre fenêtre reste ouverte le plus longtemps. C'est précisément là que la préparation est la plus rentable, par exemple par un accord avec l'hébergeur ou une procédure testée pour les nouvelles images de conteneurs.

## Comment raccourcir la fenêtre la prochaine fois

1. **S'abonner aux avis :** recevoir directement les avis de sécurité de php.net et de votre distribution, et non seulement par la presse.
2. **Définir la responsabilité :** pour chaque serveur, une personne responsable avec un suppléant.
3. **Utiliser l'automatisation là où elle convient :** les mises à jour de sécurité de la distribution peuvent être installées automatiquement. Ce qui plaide pour et contre est décrit dans [Mises à jour de sécurité automatiques](https://phpsos.de/fr/blog/automatische-sicherheitsupdates/).
4. **Planifier le redémarrage :** le redémarrage des services PHP fait partie intégrante de la procédure, non du suivi.
5. **Préparer la voie de secours :** page d'urgence et décision sur une mise hors ligne temporaire si une mise à jour n'est pas possible immédiatement.
6. **Tenir une preuve :** consigner les moments d'installation et de redémarrage afin de pouvoir justifier votre fenêtre ultérieurement.

Un processus durable qui regroupe ces points est décrit dans l'article sur le [processus de gestion des correctifs](https://phpsos.de/fr/blog/patch-management-prozess/).

## Comment PHP SOS aide-t-il concrètement ?

- **Correctif et redémarrage :** nous installons la mise à jour et nous assurons qu'aucun ancien processus PHP ne tourne plus.
- **Justifier la fenêtre :** nous documentons l'installation et le redémarrage de chaque serveur avec l'horodatage.
- **Recherche de traces :** pour la période pendant laquelle votre serveur était ouvert, nous sauvegardons les journaux et recherchons des anomalies.
- **Processus pour l'avenir :** nous mettons en place avec vous des circuits d'alerte, des responsabilités et des procédures de mise à jour.

Plus d'informations sous [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/).

## Conclusion

Avec PHP2Shell, il n'y a eu aucun délai de grâce. Le délai entre correctif et attaque est aujourd'hui souvent nul, voire négatif, pour les failles critiques. Ce que vous pouvez piloter, c'est votre propre fenêtre : elle se termine avec le redémarrage, et elle peut être raccourcie de quelques jours à quelques heures par la préparation.


## Questions fréquentes

**De combien de temps dispose-t-on après une mise à jour de sécurité avant les attaques ?**  
Il n'existe pas de délai fixe. Avec PHP2Shell, une première tentative d'attaque a été observée dès le 17 octobre selon des articles de presse, soit quatre jours avant les correctifs. Pour les failles critiques dans des logiciels répandus, vous devez partir du principe qu'il n'y a pratiquement aucun délai de grâce.

**Qu'est-ce qu'un zero-day ?**  
Une faille attaquée avant qu'une mise à jour soit disponible. L'éditeur a en quelque sorte eu zéro jour pour la corriger. On parle ensuite souvent d'une faille connue ou « N-day », pour laquelle un correctif existe déjà.

**Pourquoi les attaques deviennent-elles souvent plus fréquentes après un correctif ?**  
Avec le correctif, on rend public l'endroit où se trouvait l'erreur. Chercheurs en sécurité et attaquants peuvent analyser les modifications. En même temps, de nombreux serveurs restent non corrigés pendant des jours ou des semaines et constituent ainsi des cibles intéressantes.

**Quand mon serveur est-il réellement protégé ?**  
Lorsque la mise à jour est installée et que tous les processus PHP ont été redémarrés. De nouveaux fichiers seuls n'agissent pas tant que d'anciens processus tournent en mémoire. La fin de votre fenêtre personnelle est donc le redémarrage, non le téléchargement.

## Sources

- [php.net : avis de sécurité](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BleepingComputer: PHP ships emergency patches for critical PHP2Shell flaws](https://bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws)
- [Help Net Security: PHP2Shell vulnerabilities patched](https://helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619)