En bref : après PHP2Shell, la version PHP affichée ne prouve à elle seule que peu de choses, car les hébergeurs intègrent souvent les correctifs sous forme de backport. Exigez donc une confirmation écrite de l'hébergeur concernant la mise à jour PHP : état des paquets par branche PHP, moment de l'installation et redémarrage de tous les processus PHP. Vous trouverez ci-dessous un modèle à copier.
Pourquoi une confirmation écrite compte précisément maintenant
Le 21 octobre 2026, le projet PHP a publié les correctifs de deux failles critiques connues sous le nom de PHP2Shell. Toutes deux permettent l'exécution de code malveillant à distance sans authentification. 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 et recommande la mise à jour immédiate.
Si vous exploitez votre site chez un hébergeur, vous ne pouvez souvent pas installer la mise à jour vous-même. En même temps, en tant qu'exploitant, vous portez la responsabilité des données de vos clients. Une confirmation écrite et concrète de l'hébergeur est donc plus qu'une formalité. Elle constitue un élément de votre documentation, par exemple vis-à-vis des délégués à la protection des données, des assureurs ou de la direction.
À cela s'ajoute qu'un correctif ne supprime pas les logiciels malveillants introduits auparavant. Selon des articles de presse, une première tentative d'attaque a déjà été observée le 17 octobre. Le moment exact à partir duquel votre serveur a été protégé est donc important pour savoir si vous devez poursuivre les contrôles.
Pourquoi la version PHP affichée ne suffit pas
Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. De nombreuses distributions et de nombreux hébergeurs reprennent toutefois le correctif sous forme de backport dans leur propre paquet. Une interface comme Plesk affiche alors toujours 8.2.34 alors que le serveur est corrigé.
À l'inverse, un numéro de version correct peut tromper. De nouveaux fichiers seuls ne protègent pas tant que d'anciens processus PHP tournent en mémoire. Le nouvel état n'est actif qu'après le redémarrage de tous les workers. Plus de détails dans l'article Vérifier correctement la version de PHP et l'état du correctif.
| Déclaration de l'hébergeur | Ce qu'elle prouve | Ce qui manque encore |
|---|---|---|
| « Tous les systèmes sont à jour. » | peu de choses | Version ou état des paquets, date, redémarrage |
| « PHP 8.3.36 est installé. » | La version | Date, redémarrage, serveurs concernés |
| « Backport dans le paquet xy, redémarrage le … » | Correctif et activation | le cas échéant, informations sur PHP 8.1 et antérieur |
Les informations à obtenir de l'hébergeur
Demandez des réponses sur ces points, si possible par site web ou par contrat :
- Quelles branches et versions de PHP sont actives pour vos sites, y compris les plus anciennes qui ne tournent que pour certains répertoires ?
- Les correctifs pour CVE-2026-109618 et CVE-2026-109619 sont-ils inclus, sous forme de version officielle ou de backport ?
- Quand la mise à jour a-t-elle été installée, et quand tous les processus PHP (pools FPM, Apache, LiteSpeed) ont-ils été redémarrés ?
session.upload_progress.enabledest-il désactivé en raison de CVE-2026-115560 ?- Quel mode d'exécution utilise votre offre, par exemple PHP-FPM ou Apache avec mod_php ? Avec mod_php, l'équipe PHP voit le risque le plus élevé.
- Quels journaux d'accès et d'erreurs à partir du 20 octobre 2026 sont conservés, et comment pouvez-vous les obtenir ?
Si un site tourne encore sur PHP 8.1 ou antérieur, posez la question séparément. Pour ces branches, il n'existe plus de mises à jour officielles, seulement des backports minimaux du code source pour 7.4, 8.0 et 8.1.
Modèle : demander la confirmation de mise à jour PHP à l'hébergeur
Copiez le texte dans un ticket de support ou un e-mail à votre hébergeur. Complétez les informations entre crochets.
Objet : Demande de confirmation de l'état des correctifs PHP (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Bonjour,
nous exploitons chez vous les sites web / contrats suivants :
[numéro de client, contrat, domaines]
En lien avec les failles de sécurité PHP CVE-2026-109618 et
CVE-2026-109619 (PHP2Shell, correctifs du 21.10.2026) ainsi qu'avec
l'avis relatif à CVE-2026-115560 du 23.10.2026, nous vous prions de
nous confirmer par écrit les points suivants :
1. Quelles versions de PHP ou quels états de paquets sont actifs pour nos sites web ?
2. Contiennent-ils les correctifs (version officielle ou backport) ?
3. Date et heure de l'installation.
4. Date et heure du redémarrage de tous les processus PHP (FPM, Apache,
LiteSpeed ou similaire).
5. session.upload_progress.enabled est-il désactivé côté serveur ?
6. Quel mode d'exécution de PHP est utilisé (p. ex. PHP-FPM, mod_php) ?
7. Les journaux d'accès et d'erreurs sont-ils conservés à partir du 20.10.2026, et
comment pouvons-nous les obtenir ?
8. Si un site web utilise encore PHP 8.1 ou une version plus ancienne : quelle protection
existe à cet endroit, et quelle migration recommandez-vous ?
Nous avons besoin de ces informations pour notre documentation interne.
Merci d'avance et cordialement
[Nom, entreprise, fonction]
Bien évaluer la réponse et la recouper soi-même
Une bonne réponse indique des états, des dates et des heures concrets. Des formulations générales comme « nous avons réagi » ne suffisent pas pour votre dossier. Dans ce cas, demandez aimablement les points manquants.
Si votre offre le permet, vérifiez en outre vous-même. Avec un accès SSH, ces commandes suffisent généralement :
# Version de la ligne de commande (peut différer de la version web)
php -v
# État des paquets sous Debian/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# État des paquets sous RHEL, Alma, Rocky
rpm -qa | grep -i php
# Depuis quand les processus PHP-FPM tournent-ils ?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Si l'heure de démarrage des processus PHP est antérieure à la date d'installation confirmée, le redémarrage n'était pas complet.
Si l'hébergeur ne répond pas ou répond de façon évasive
Si aucune réponse n'arrive ou si les informations décisives manquent, ne considérez pas la situation comme éclaircie. Le BSI recommande de déconnecter temporairement les serveurs web du réseau lorsqu'une mise à jour n'est pas possible immédiatement. Savoir si c'est proportionné pour votre site relève de la direction, idéalement par écrit et avec une date.
Il vaut la peine, en parallèle, de rechercher d'éventuelles traces d'une attaque, car le moment du correctif reste incertain. L'article Suis-je déjà compromis ? donne des repères. Sans accès SSH, la confirmation écrite reste votre preuve la plus importante. Les obligations qui incombent à l'hébergeur et celles qui vous incombent sont expliquées sur la page Hébergement mutualisé : ce que fait l'hébergeur ; pour les serveurs infogérés, consultez Serveur managé : clarifier la responsabilité.
Classez dans un dossier la demande, la réponse et vos propres résultats de contrôle, avec la date. Ce dossier aidera plus tard en cas de questions d'assureurs ou de délégués à la protection des données.
Comment PHP SOS aide-t-il concrètement ?
- Nous rédigeons avec vous la demande à l'hébergeur et évaluons la réponse sur le plan technique.
- Là où un accès existe, nous vérifions nous-mêmes l'état des paquets, le mode d'exécution actif et le redémarrage des processus PHP.
- Si des lacunes subsistent, nous mettons en œuvre des mesures transitoires ou planifions le passage à une version prise en charge.
- Nous consignons le résultat et les horaires dans un justificatif que vous pouvez transmettre en interne.
Le déroulement de la mise à jour avec redémarrage et justificatif est décrit dans notre service de correctifs PHP.
Questions fréquentes
Suffit-il que mon hébergeur écrive que tout est à jour ?
Pour votre documentation, plutôt pas. Demandez des informations concrètes : état des paquets ou version par branche PHP, date de l'installation et date du redémarrage de tous les processus PHP. C'est seulement ainsi que vous pouvez délimiter la fenêtre de vulnérabilité.
Pourquoi mon interface d'hébergement affiche-t-elle encore PHP 8.2.34 ?
Les distributions et les hébergeurs reprennent parfois les correctifs de sécurité sous forme de backport, sans modifier le numéro de version. Plesk peut alors continuer d'afficher 8.2.34 alors que le serveur est corrigé. Seule la confirmation du fournisseur sur l'état des paquets apporte de la clarté.
Que faire si l'hébergeur ne répond pas ?
Documentez votre demande avec la date et relancez après un délai raisonnable. Vérifiez en parallèle si vous pouvez mettre en place vous-même des mesures transitoires, et convenez avec la direction si le site doit être mis hors ligne jusqu'à clarification, comme le BSI (office fédéral allemand de la sécurité des technologies de l'information) le recommande pour les serveurs non corrigés.
Une mise à jour de WordPress ou de la boutique comble-t-elle aussi la faille ?
Non. PHP2Shell se trouve dans PHP lui-même. Une mise à jour du CMS ou du logiciel de boutique ne change rien à l'interpréteur PHP qui tourne sur le serveur.