Comment vérifier si vos applications auto-hébergées utilisent une version vulnérable de PHP

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Conceptual guide: CHECK THE RUNNING PHP. Identify service; Inspect runtime; Verify vendor fix.

Un hôte peut exécuter plusieurs versions de PHP simultanément. La version renvoyée par un shell SSH peut appartenir à un outil en ligne de commande, tandis qu’un site web public utilise un autre environnement d’exécution. Pour évaluer les vulnérabilités PHP d’octobre 2026, associez chaque résultat de version à une application et à un service réels.

Vérifiez l’environnement qui sert l’application, et pas seulement le PHP en ligne de commande de l’hôte. Comparez la branche exacte du moteur d’exécution ou la révision du paquet de la distribution avec l’avis applicable, en tenant compte des rétroportages documentés du fournisseur, puis supprimez toute page de diagnostic temporaire après la vérification.

1. Identifier les applications utilisant PHP

Dressez la liste des applications, des méthodes d’installation et des voies d’accès externes. Consultez la documentation de l’application ou les métadonnées du paquet pour déterminer si elle utilise PHP. Incluez les services auxiliaires, tels que les processus cron et les files d’attente, lorsqu’ils utilisent la même image d’application.

Ne déduisez pas l’utilisation de PHP de la marque du NAS. Un appareil exécutant plusieurs applications nécessite une évaluation service par service.

2. Inspecter un déploiement Compose

docker compose ps
docker compose images
docker compose exec -T app php -v
docker compose exec -T app php --ini

Exécutez ces commandes depuis le répertoire du projet Compose concerné ; remplacez app par le nom du service qui contient PHP. Elles identifient les conteneurs actuels et interrogent le binaire à l’intérieur de ce service. Si PHP s’exécute dans un service distinct nommé php ou fpm, inspectez plutôt ce service.

L’absence d’un exécutable php ne prouve pas que l’application est sécurisée. Les images minimales, les chemins binaires alternatifs ou les services d’exécution distincts peuvent nécessiter la méthode d’inspection du responsable de la maintenance. N’installez pas de paquets dans un conteneur de production simplement pour vérifier une version.

3. Inspecter le PHP installé sur l’hôte

command -v php
php -v
php --ini

Ces commandes décrivent le PHP du shell. Examinez ensuite la configuration de votre serveur web et votre gestionnaire de services pour identifier le pool PHP-FPM, le module Apache ou tout autre gestionnaire qui sert le site. Vérifiez la version du paquet de ce composant et l’avis de sécurité du fournisseur. PHP précise que les emplacements et le comportement de la configuration varient selon l’interface du serveur.

Si un tableau de bord fournit des informations privées sur l’environnement d’exécution du service web concerné, elles peuvent compléter l’inventaire. Ne laissez pas en ligne une page publique phpinfo() ; elle peut révéler des détails sans rapport avec la vérification.

4. Comparer les éléments aux avis de sécurité

Pour l’incident du 21 octobre, les versions de sécurité en amont sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Une version ultérieure prise en charge de la même branche peut inclure ces correctifs. Si une distribution rétroporte les correctifs de sécurité, fiez-vous à la révision de son paquet et à son avis de sécurité, plutôt que d’accepter ou de rejeter un paquet en vous fondant uniquement sur le numéro qui semble correspondre à la version en amont.

Consignez le résultat dans l’un de ces trois états : correctif confirmé, vulnérabilité confirmée ou situation non résolue dans l’attente de preuves du fournisseur. Pour les logiciels en fin de vie, prévoyez une mise à niveau vers une version prise en charge ou un correctif explicite fourni par un fournisseur assurant la maintenance. Tout résultat non résolu doit rester visible dans votre liste de maintenance.

5. Confirmer le résultat de la mise à jour

Répétez les mêmes vérifications après le déploiement, notamment pour les processus de travail et conteneurs distincts. Notez l’identifiant de l’image ou la révision du paquet, ainsi que l’état du redémarrage. Testez une requête authentifiée normale et les fonctions réellement utilisées par votre foyer.

Sur un cloud personnel ZimaCube 2, conservez cette trace avec la configuration de l’application et les instructions de sauvegarde. L’objectif est d’obtenir une déclaration vérifiable telle que « cette application utilise cet environnement d’exécution corrigé », plutôt que « le NAS a été mis à jour ». Si vous trouvez un conteneur concerné, suivez le guide de mise à jour indiqué avant de modifier ses volumes de données.

Découvrez le NAS cloud personnel ZimaCube 2 pour la maison pour votre stockage privé et votre installation d’applications auto-hébergées. La sécurité logicielle dépend des services installés, de leur configuration et de la vérification des mises à jour.

Poursuivre la série sur la sécurité de PHP

Sources et périmètre

Vérifié le 22 octobre 2026. Les recommandations de déploiement doivent être adaptées à votre application et à la documentation du fournisseur ; ces articles ne déterminent pas l’exposition d’un produit particulier.