En bref : chez les fournisseurs cloud et PaaS, le fournisseur ne corrige pas automatiquement. S'il gère l'environnement d'exécution PHP, il le met à jour, mais souvent seulement avec le prochain déploiement. Si vous construisez vous-même des images ou des builds, ou exploitez vous-même la plateforme, vous devez reconstruire et déployer. Ce qui fait foi, c'est toujours l'environnement d'exécution que votre site sert en ce moment.
Mise à jour PHP sur PaaS : à qui appartient l'environnement d'exécution ?
Les services de plateforme, dans le jargon PaaS (Platform as a Service), déchargent les entreprises de l'exploitation des serveurs. Vous téléversez du code, la plateforme le construit et l'exploite. Avec PHP2Shell, il en naît une incertitude typique : qui doit en réalité mettre PHP à jour ?
Vercel le résume dans son bulletin sur PHP2Shell : la mise à jour de l'environnement de développement local, du code de l'application ou des extensions ne suffit pas. Ce qui est déterminant, c'est l'environnement d'exécution PHP du déploiement qui répond réellement aux requêtes. Qu'il soit corrigé dépend de qui le fournit et de la date de son dernier build.
Quatre modèles d'exploitation en comparaison
Les désignations des fournisseurs diffèrent. Pour la question des correctifs, la plupart des offres peuvent être rattachées à l'un de ces modèles :
| Modèle | Qui met PHP à jour ? | Ce que vous devez faire |
|---|---|---|
| Environnement d'exécution géré par le fournisseur | Fournisseur | Obtenir une confirmation, redéployer le cas échéant pour que le nouvel environnement s'applique |
| Environnement d'exécution fondé sur un build (buildpack) | Le fournisseur met à disposition une nouvelle version, votre build la fige | Déclencher un nouveau build, vérifier la version dans le journal du build |
| Image de conteneur propre | Vous | Reconstruire l'image avec le PHP corrigé et la déployer |
| Plateforme exploitée en propre | Vous, pour la plateforme et les applications | Corriger la plateforme, puis chaque application séparément |
De nombreuses entreprises utilisent plusieurs modèles à la fois, par exemple un environnement géré pour le site web et des conteneurs propres pour des outils internes. Chaque application a donc besoin de sa propre réponse.
Un piège se cache dans le mot « géré ». Même si le fournisseur entretient l'environnement d'exécution, une application déjà déployée continue souvent de tourner avec l'état dans lequel elle a été construite. La nouvelle version ne s'applique alors qu'au prochain build ou déploiement. Certaines plateformes maintiennent en outre accessibles, sous des adresses propres, d'anciens déploiements ou des environnements de prévisualisation. Ne demandez donc pas seulement si le fournisseur a corrigé, mais aussi à partir de quand vos instances en cours utilisent le correctif et ce qu'il advient des anciens déploiements.
Ce que disent Vercel et Coolify sur PHP2Shell
Deux fournisseurs ont rendu leurs indications publiques. Elles sont instructives, car elles nomment clairement les limites de leurs propres mesures de protection.
Vercel a, selon son propre bulletin, activé avant la publication des règles de protection dans son pare-feu d'applications web (WAF), un filtre pour les requêtes web. Elles s'appliquent automatiquement aux fonctions PHP sur Vercel et aux requêtes que Vercel transmet à des serveurs PHP externes. En même temps, Vercel demande de mettre immédiatement à jour l'environnement d'exécution PHP vers une version corrigée. Les déploiements de conteneurs doivent être reconstruits avec une image de base PHP mise à jour, puis déployés. Les requêtes qui contournent Vercel et vont directement à un serveur PHP externe ne sont pas couvertes par le WAF.
Coolify, une plateforme que l'on peut exploiter soi-même, était selon son propre avis lui-même concerné : toutes les branches de la version 4. Comme premiers états corrigés, Coolify cite 4.0.1, 4.1.3, 4.2.1, 4.3.24 et 4.4.7 et recommande 4.4.7. L'ajout est important : la mise à jour de Coolify ne met pas à jour les applications PHP que vous exploitez avec. Leurs environnements d'exécution ou leurs images, vous devez les mettre à jour séparément et les reconstruire ou les déployer. Cela vaut selon Coolify aussi pour les clients de Coolify Cloud et aussi derrière Cloudflare, car les règles de Cloudflare ne contrôlent que le trafic qui passe par Cloudflare.
Ce que les règles de Cloudflare apportent, l'article Règles de protection Cloudflare contre PHP2Shell le replace dans son contexte.
Comment vérifier l'environnement d'exécution servi
Les étapes suivantes fonctionnent quel que soit le fournisseur. Elles visent une preuve, non une impression.
- Lister tous les environnements : production, préproduction, déploiements de prévisualisation et services d'arrière-plan comme les workers de file d'attente. Chaque environnement peut avoir un environnement d'exécution différent.
- Lire la version de l'environnement d'exécution pour chaque environnement : dans la console du fournisseur, dans le journal du build ou dans le fichier de configuration du projet.
- Vérifier la date du dernier déploiement : si elle est antérieure au 21/10/2026, c'est très probablement l'ancien environnement qui tourne encore, sauf si le fournisseur confirme expressément autre chose.
- Regarder dans l'instance en cours : si la plateforme offre une console, la commande suivante montre la version de l'instance.
- Inclure les serveurs PHP externes : les serveurs vers lesquels la plateforme transmet des requêtes ont besoin de leur propre mise à jour et ne devraient pas être directement accessibles depuis Internet.
# Dans la console de l'instance en cours (si le fournisseur la propose)
php -v
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;'
On attend 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou un rétroportage confirmé par le fournisseur. Notez que la ligne de commande d'une instance n'utilise pas toujours le même environnement d'exécution que le processus web. Ne créez pas de fichier phpinfo accessible publiquement pour la vérification. La façon d'interpréter correctement le numéro de version et l'état des rétroportages est décrite dans Vérifier la version de PHP et l'état des correctifs.
Un nouveau déploiement ne supprime aucun logiciel malveillant qui s'est introduit auparavant dans des stockages persistants comme les volumes de téléversement ou la base de données. Ces zones, vous les vérifiez séparément.
Consigner la responsabilité par écrit
PHP2Shell montre à quel point la frontière entre la plateforme et le client est souvent floue. Notez pour chaque application qui fournit l'environnement d'exécution, qui reconstruit lors des avis de sécurité et comment le fournisseur annonce les correctifs. S'y ajoutent aussi qui a accès à la console de la plateforme en cas d'urgence, et qui peut déclencher un nouveau build en dehors des heures de bureau.
Pour votre propre documentation, un court tableau par application suffit : plateforme, modèle d'exploitation, branche PHP, date du dernier build, responsable. Qui a cette liste sous la main lors du prochain avis économise les jours que beaucoup d'équipes ont passés à chercher après le 21 octobre. Pour les applications en conteneurs, il faut ajouter qui entretient l'image de base ; le contexte est expliqué dans PHP dans les conteneurs.
Pour les serveurs gérés sans caractère PaaS, des questions similaires se posent, que nous avons résumées sous Serveur managé : clarifier la responsabilité.
Comment PHP SOS aide-t-il concrètement ?
- Rattacher : nous rattachons chacune de vos applications à un modèle d'exploitation et clarifions qui fournit l'environnement d'exécution PHP.
- Prouver : nous vérifions l'environnement d'exécution, la date du build et le déploiement pour chaque environnement et documentons le résultat.
- Reconstruire et déployer : via le service de correctifs PHP, nous mettons à jour images et builds et les déployons de façon contrôlée.
- Combler les lacunes : nous vérifions si des serveurs PHP externes sont directement accessibles et restreignons l'accès.
Questions fréquentes
Mon fournisseur PaaS corrige-t-il PHP automatiquement ?
Cela dépend du modèle. Si le fournisseur gère l'environnement d'exécution, il le met à jour, mais souvent seulement pour les nouveaux déploiements. Si vous construisez vous-même des images ou des builds, vous devez reconstruire et redéployer. Faites-vous confirmer l'état pour votre application.
Le WAF de mon fournisseur de plateforme suffit-il contre PHP2Shell ?
Non. Vercel et Coolify écrivent expressément que les règles de protection ne remplacent pas la mise à jour de l'environnement d'exécution PHP. Elles n'agissent en outre que sur le trafic qui passe par la plateforme.
Dois-je redéployer après le correctif ?
Souvent oui. Vercel mentionne, pour les déploiements de conteneurs, la reconstruction avec une image de base PHP mise à jour et un nouveau déploiement. Sur les plateformes fondées sur des builds, l'environnement d'exécution est figé au moment du build ; seul un nouveau build reprend le correctif.
J'utilise Coolify. La mise à jour de Coolify suffit-elle ?
Non. Selon l'avis de Coolify, la mise à jour ne met à jour que Coolify lui-même. Les environnements d'exécution PHP ou les images de conteneurs de vos applications doivent être mis à jour séparément, puis reconstruits ou redéployés.