# Assistance immédiate PHP2Shell : aide face à la faille de sécurité PHP

> Aide face à la faille PHP2Shell : nous vérifions vos serveurs, appliquons les correctifs, redémarrons tous les workers et documentons l'état atteint.

Source : https://phpsos.de/fr/leistungen/php2shell-soforthilfe/  
É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 :** PHP2Shell désigne deux failles critiques dans PHP lui-même, par lesquelles des attaquants peuvent exécuter du code malveillant sans authentification. Si vous avez besoin d'une aide rapide face à cette faille de sécurité PHP, nous prenons en charge à distance l'inventaire, le correctif ou une mesure transitoire, le redémarrage de tous les processus PHP et une première recherche de traces. À la fin, vous recevez une attestation écrite de l'état atteint.

## Aide face à la faille de sécurité PHP : pourquoi il faut agir maintenant

Le 21 octobre 2026 à 16 h, heure allemande, le projet PHP a publié des correctifs pour CVE-2026-109618 et CVE-2026-109619. Les deux failles sont évaluées à 9.2 selon CVSS v4.0 et permettent l'exécution de code malveillant à distance, sans que personne n'ait besoin de s'authentifier. Les modes d'exécution courants sont concernés : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed.

Le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) a émis le niveau d'alerte 3 (orange). Il recommande la mise à jour immédiate et, si celle-ci n'est pas possible sur-le-champ, de déconnecter temporairement les serveurs web du réseau. Palo Alto Networks (Unit 42) a dénombré plus de 22,6 millions d'instances exposées et potentiellement vulnérables. Selon le BSI, aucune attaque réussie à grande échelle n'était d'abord confirmée, mais Cloudflare a déjà signalé des tentatives d'attaque.

Pour la direction et les dirigeants, cela signifie : tout serveur PHP accessible publiquement est un candidat tant que le contraire n'est pas prouvé. Vous trouverez une explication compréhensible de la faille sous [Qu'est-ce que PHP2Shell ?](https://phpsos.de/fr/php2shell/was-ist-php2shell/).

## À qui s'adresse l'assistance immédiate PHP2Shell ?

Aux entreprises, agences et organismes publics qui exploitent des applications PHP et qui ne peuvent ou ne veulent pas traiter seuls la situation avec la profondeur nécessaire. Cela concerne les serveurs root et vServers en propre autant que les serveurs avec Plesk ou cPanel, les environnements de conteneurs et les serveurs gérés dont la répartition des responsabilités est floue.

Même avec un hébergeur, un soutien est souvent nécessaire. De nombreux fournisseurs appliquent des backports ; Plesk continue alors par exemple d'afficher 8.2.34 alors que l'état des paquets est corrigé. Inversement, un nouveau numéro de version peut s'afficher alors que d'anciens processus PHP tournent encore en mémoire. Les états considérés comme corrigés figurent sous [Quelles versions de PHP sont concernées ?](https://phpsos.de/fr/php2shell/betroffene-php-versionen/).

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

1. **Inventaire :** nous recensons toutes les installations PHP, les modes d'exécution et les versions sur vos serveurs, y compris l'état des paquets et les processus en cours. Le résultat est une liste indiquant quels systèmes sont concernés, corrigés ou incertains.
2. **Correctif ou mesure transitoire :** lorsque c'est possible, nous installons les versions corrigées (8.5.12, 8.4.27, 8.3.36, 8.2.35) ou les paquets de votre distribution. Si ce n'est pas possible immédiatement, nous appliquons les mesures transitoires indiquées par php.net et disons ouvertement qu'elles n'offrent pas une protection complète.
3. **Redémarrage et contrôle :** nous redémarrons tous les workers et processus PHP, puis vérifions qu'aucun ancien processus ne tourne plus. De nouveaux fichiers seuls ne referment pas la faille.
4. **Première recherche de traces :** nous sauvegardons les journaux du serveur à partir du 20 octobre et recherchons des anomalies comme de nouveaux fichiers PHP, des tâches cron inconnues ou des processus inhabituels. Comme il n'existe pas d'indicateurs de compromission (IOC) publiés et confirmés, cette vérification repose sur l'analyse comportementale.
5. **Attestation et étapes suivantes :** vous recevez un rapport écrit. En cas de soupçon de compromission, nous recommandons les suites appropriées, par exemple le [retrait de logiciels malveillants](https://phpsos.de/fr/leistungen/malware-entfernung/) ou une enquête forensique.

> **Important:**
> Un correctif ne supprime aucun logiciel malveillant déjà introduit et ne prouve pas que rien ne s'est produit auparavant. C'est pourquoi l'assistance immédiate comprend toujours un examen de la période écoulée depuis le 17 octobre 2026.

## Ce que vous recevez de notre part

- un aperçu de tous les serveurs vérifiés avec la version de PHP, l'état des paquets, le mode d'exécution et l'état du correctif
- la documentation des mises à jour installées ou des mesures transitoires mises en place
- la preuve que tous les processus PHP ont été redémarrés
- une appréciation de la recherche de traces, distinguant ce qui est établi, probable et inconnu
- une liste de points ouverts, par exemple des systèmes sous PHP 8.1 ou une version antérieure

Vous pouvez transmettre ce rapport à la direction, aux délégués à la protection des données ou aux assureurs. Il ne remplace pas l'appréciation juridique.

## Ce dont nous avons besoin de votre part

- **Accès :** un accès SSH ou au panneau d'administration avec des droits suffisants, ou bien l'autorisation de nous laisser obtenir des informations auprès de votre hébergeur
- **Interlocuteur :** une personne habilitée à décider, par exemple d'une brève mise hors ligne ou d'un redémarrage
- **Vue d'ensemble :** quels sites web, boutiques et applications fonctionnent sur quels serveurs
- **Fenêtre de maintenance :** vos consignes sur le moment où les redémarrages sont autorisés
- **Sauvegardes :** l'indication de l'endroit où se trouvent les sauvegardes récentes

Pour les administrateurs qui souhaitent d'abord vérifier eux-mêmes, un coup d'œil sans danger à l'état du système suffit souvent :

```bash
php -v
# Debian/Ubuntu : paquets PHP installés avec leur version
dpkg -l | grep -i php
# processus PHP en cours et leur heure de démarrage
ps -eo pid,lstart,cmd | grep -i php
```

## Ce que nous ne promettons pas

Nous ne promettons ni une sécurité absolue ni l'affirmation que votre serveur n'a jamais été attaqué si les éléments de preuve ne le permettent pas. Nous travaillons sur l'incident jusqu'à ce qu'il soit clos et documenté. Qu'il existe ou non une obligation de notification au titre du RGPD, ou que votre assurance doive être informée, vous le clarifiez avec votre délégué à la protection des données, votre avocat ou votre assureur. Nous fournissons pour cela les faits techniques.

Si vous n'avez besoin que de la mise à jour avec attestation, notre [service de correctifs PHP](https://phpsos.de/fr/leistungen/php-patch-service/) convient. S'il existe déjà des signes d'une attaque, l'[aide d'urgence en cas de site web piraté](https://phpsos.de/fr/leistungen/website-gehackt-notfallhilfe/) est le bon point de départ.


## Questions fréquentes

**Est-il suffisant que mon hébergeur ait mis à jour PHP ?**  
Cela peut suffire si l'hébergeur confirme l'état des paquets par écrit et que tous les processus PHP ont été redémarrés. Le numéro de version affiché ne prouve rien à lui seul, car les distributions appliquent des backports. Quant à savoir si le serveur a déjà été attaqué auparavant, un correctif n'y répond de toute façon pas.

**Mon site web doit-il être mis hors ligne pour l'assistance immédiate ?**  
Pas nécessairement. Le BSI recommande de déconnecter temporairement les serveurs web du réseau lorsque la mise à jour n'est pas possible immédiatement. Nous décidons ensemble, après l'inventaire, si c'est nécessaire dans votre cas.

**Une mise à jour de WordPress ou de Shopware protège-t-elle contre PHP2Shell ?**  
Non. PHP2Shell se trouve dans PHP lui-même, pas dans le CMS. Une mise à jour du CMS reste judicieuse, mais elle ne referme pas cette faille.

**Que se passe-t-il avec PHP 8.1 ou une version antérieure ?**  
Pour ces versions, le projet PHP ne publie plus de mises à jour officielles, seulement des backports minimaux du code source pour 7.4, 8.0 et 8.1. Nous sécurisons le serveur à titre transitoire et planifions avec vous le passage à une version prise en charge.

## Sources

- [php.net : avis de sécurité](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI : office fédéral allemand de la sécurité des technologies de l'information](https://www.bsi.bund.de/)
- [TechTarget : PHP2Shell, 22 millions de serveurs exposés](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)