En bref : qui veut mettre à jour ses dépendances a besoin d'un processus pour trois mondes de paquets : paquets Composer dans le code PHP, modules npm dans le build du front-end, et extensions ou thèmes dans le CMS. Il faut pour cela un rythme fixe, une personne responsable, des tests avant le déploiement et un plan pour les paquets sans mise à jour. Cela n'aide pas contre PHP2Shell, car cette faille se trouve dans PHP lui-même, mais contre les nombreuses failles du code tiers.
Trois mondes de paquets, un angle mort
Dans la semaine suivant le 21 octobre 2026, tout tournait autour de l'interpréteur PHP. De nombreuses équipes ont alors constaté qu'elles ne connaissaient pas précisément les versions de leurs propres composants. Le site fonctionne, l'agence s'en occupe, l'extension se signale d'elle-même quand il y a du nouveau : voilà, en gros, les hypothèses, jusqu'à ce que quelqu'un vérifie.
Un projet PHP typique se compose aujourd'hui de bien plus de code tiers que de code propre. L'OWASP Top 10 range les composants vulnérables et obsolètes dans une catégorie de risque à part. Le problème est rarement l'absence d'outil, mais l'absence de routine : les mises à jour se font quand quelqu'un a le temps, et les alertes de sécurité atterrissent dans une boîte aux lettres que personne ne lit.
Quelles dépendances mettre à jour, et où ?
Chaque monde de paquets a ses propres outils et ses propres pièges. Le tableau suivant aide à ne rien oublier.
| Monde de paquets | Afficher l'existant | Rechercher les failles | Piège typique |
|---|---|---|---|
| Composer (bibliothèques PHP) | composer show |
composer audit |
paquets indirects que personne ne connaît |
| npm (build du front-end) | npm ls |
npm audit |
une mise à jour sans reconstruction n'atteint jamais le serveur |
| Extensions et thèmes CMS | interface d'administration ou CLI | avis des éditeurs, services de sécurité | extensions abandonnées, extensions payantes sans canal de mise à jour |
| PHP et extensions | gestion des paquets | suivi de sécurité de la distribution | la version affichée dit peu de choses sur les backports |
La dernière ligne ne fait, à proprement parler, pas partie des dépendances de l'application, mais elle est souvent oubliée dans le même élan. Il en va de même pour les scripts intégrés directement depuis des serveurs tiers, par exemple des bibliothèques issues d'un CDN, des widgets de chat ou du code de suivi. Ils n'apparaissent dans aucun fichier de verrouillage, mais s'exécutent dans le navigateur de vos visiteurs. Ajoutez-les à la liste et vérifiez que des versions fixes sont intégrées plutôt que « toujours la dernière ». Les détails sur composer audit, le fichier de verrouillage et l'intégration au build figurent dans le guide Rechercher les failles dans les dépendances Composer. Le fonctionnement général de Composer est expliqué dans Composer : le gestionnaire de paquets de PHP.
Le cycle de maintenance en six étapes
Un processus durable n'a pas besoin d'être compliqué. Cet ordre a fait ses preuves :
- Consigner l'existant : pour chaque projet, une liste des dépendances directes avec version, origine et finalité. Les fichiers de verrouillage (
composer.lock,package-lock.json) ont leur place dans le dépôt. - Collecter les alertes : les outils de contrôle s'exécutent à chaque build et, en plus, régulièrement sur l'état déployé, même sans modification du code.
- Évaluer : le paquet concerné est-il utilisé en production, la fonction concernée est-elle accessible, existe-t-il une version corrigée ?
- Mettre à jour et tester en préproduction : d'abord les mises à jour de sécurité au sein de la même version majeure, les sauts vers de nouvelles versions majeures étant planifiés comme un projet à part.
- Déployer avec retour arrière : l'état précédent reste disponible sous forme de paquet ou de release, sauvegarde de la base de données avant la mise à jour.
- Documenter : ce qui a été mis à jour et quand, ce qui ne l'a volontairement pas été et pourquoi.
Faites attention aux indications de version dans composer.json et package.json. Des contraintes trop étroites empêchent d'installer des correctifs de sécurité. Des contraintes trop larges font au contraire entrer sans contrôle de nouvelles versions majeures dans le projet. Il est recommandé d'autoriser les mises à jour au sein de la version majeure et de planifier délibérément le saut vers la suivante.
Pour les extensions du CMS, les mises à jour disponibles peuvent souvent aussi être affichées en ligne de commande, avec WP-CLI par exemple pour WordPress :
# Afficher les mises à jour disponibles, sans rien modifier
wp plugin list --update=available
wp theme list --update=available
# Paquets front-end : versions obsolètes et failles connues
npm outdated
npm audit --omit=dev
Les mises à jour automatiques d'extensions directement sur le système de production sont pratiques, mais risquées si personne ne vérifie ensuite. Ne les activez que si une sauvegarde avant chaque exécution et un contrôle après sont garantis.
S'il n'y a pas de mise à jour
Toutes les alertes ne se règlent pas d'un clic. L'aide-mémoire OWASP sur la gestion des dépendances vulnérables distingue plusieurs cas, qui se transposent bien au quotidien :
- Correctif disponible : l'appliquer en préproduction, tester, déployer. Si quelque chose casse, adapter son propre code plutôt que de laisser la mise à jour de côté.
- Correctif annoncé mais pas encore là : mettre en œuvre le contournement de l'éditeur, désactiver ou isoler si possible la fonction concernée, consigner la décision.
- Aucun correctif à attendre : chercher un paquet de remplacement ou rétroporter soi-même la correction, avec un test qui distingue la faille avant et après le correctif.
Pour les extensions de CMS, un quatrième cas est fréquent : l'extension est abandonnée. Seuls le remplacement ou la suppression aident alors. Il en va de même pour les extensions de sources douteuses, par exemple des copies « gratuites » d'extensions payantes. Elles ne reçoivent pas de mises à jour par le canal officiel et contiennent assez souvent elles-mêmes du code malveillant. Des indications pour les exploitants de WordPress sont réunies dans WordPress et PHP2Shell.
Clarifier les responsabilités avant la prochaine alerte
La raison la plus fréquente de paquets obsolètes n'est pas un obstacle technique, mais une question restée ouverte : qui s'en charge ? Dans les projets construits par une agence et exploités en interne, personne ne se sent souvent responsable. Définissez pour chaque projet qui reçoit les alertes, qui les évalue et qui valide, et mettez-le par écrit.
Prévoyez aussi du temps. Une date de maintenance fixe chaque mois, où les dépendances sont examinées et mises à jour, évite que les mises à jour ne s'accumulent pendant des années. Plus un projet reste longtemps sans mise à jour, plus le saut suivant devient grand et risqué. La façon dont les mises à jour de PHP et des paquets s'intègrent dans un processus global est décrite dans La gestion des correctifs comme processus plutôt que comme pompier de service.
Comment PHP SOS aide-t-il concrètement ?
- Nous recensons toutes les dépendances de vos projets issues de Composer, npm et du CMS, et marquons les paquets obsolètes, vulnérables et abandonnés.
- Nous mettons en place des contrôles automatiques et définissons qui évalue quelle alerte.
- Nous mettons à jour en préproduction, testons les parcours essentiels et déployons avec retour arrière.
- Dans le cadre d'un contrat de maintenance de sécurité, nous assurons durablement le cycle mensuel, mises à jour de PHP comprises.
Conclusion : des dépendances à jour ne sont pas un projet, mais une routine. Qui règle proprement une fois pour toutes l'existant, le rythme et les responsabilités n'aura, à la prochaine grande alerte, plus qu'à vérifier, et non à chercher d'abord.
Questions fréquentes
À quelle fréquence faut-il mettre à jour les dépendances ?
Les mises à jour de sécurité dès que possible après évaluation, les mises à jour de routine selon un rythme fixe, par exemple mensuel. Plus important que la fréquence exacte : que la date soit fixée et que quelqu'un en soit responsable.
Une extension à jour protège-t-elle contre PHP2Shell ?
Non. PHP2Shell se trouve dans l'interpréteur PHP lui-même. Seule une mise à jour de PHP avec redémarrage de tous les processus PHP y remédie. Des extensions et paquets à jour restent importants, car ils corrigent leurs propres failles.
Que faire d'une extension qui n'est plus maintenue ?
La remplacer ou la supprimer. Une extension abandonnée ne reçoit plus de corrections, même si elle fonctionne encore aujourd'hui. Jusqu'au remplacement, vous devriez vérifier si la fonction est réellement nécessaire et documenter la décision.
Le front-end avec npm doit-il aussi être mis à jour sur le serveur ?
Souvent, les paquets npm n'existent que dans le build et arrivent sur le serveur sous forme de fichiers finis. Une faille dans un paquet peut malgré tout se trouver dans le JavaScript diffusé. Après une mise à jour, il faut donc reconstruire et redéployer.