Mettre à jour Symfony chaque mois : la routine qui évite la migration de crise

Le 4 novembre 2026, dix failles le même jour

Ce jour-là, le blog de Symfony a publié dix avis de sécurité. Ils touchent des composants que presque toutes les applications chargent : HttpFoundation, HttpKernel, le pare-feu de sécurité, le client HTTP, le Serializer, le parseur YAML, Filesystem. Deux exemples suffisent à mesurer l'enjeu.

• Des liens qui pointent chez un attaquant. Quand le contrôleur frontal est dans un sous-dossier, par exemple quand un fichier .htaccess à la racine du projet renvoie tout vers public/, un lien piégé peut faire générer à l'application des URL vers un autre domaine. Le formulaire de connexion envoie alors l'identifiant et le mot de passe de l'utilisateur à ce domaine. C'est souvent le montage choisi quand l'hébergeur ne laisse pas pointer le site sur public/. Les configurations recommandées par la documentation de Symfony ne sont pas touchées.
• Un compte refusé qui se connecte quand même. Une application qui refuse les comptes expirés dans la méthode checkPostAuth() de son contrôle d'utilisateur les refusait bien au formulaire de connexion, mais pas à la connexion faite par le code, celle qui suit une réinitialisation de mot de passe ou la validation d'un e-mail.

La correction est la même pour les dix : Symfony 5.4.56, 6.4.50, 7.4.23 ou 8.1.11, selon votre branche. Ce sont des versions correctives, pas des montées de version.

Une branche n'apparaît pas dans cette liste : celle qui n'est plus maintenue. Une application en 7.3 (fin de maintenance en janvier 2026) ou en 8.0 (juillet 2026) n'a reçu aucun correctif. Pour elle, la réponse est de passer à la 7.4 ou à la 8.1 : une version mineure, sans rupture, mais un vrai changement de version, à faire pendant qu'on sait que la faille est publique.

Une version corrective ne casse rien, par contrat

Symfony publie une version corrective environ chaque mois. Elle ne contient que des corrections de bugs, et la documentation officielle recommande de l'installer « dès que possible », parce qu'elle peut corriger des failles de sécurité. Une version mineure arrive tous les six mois, en mai et en novembre, et ne casse rien non plus : c'est la promesse de compatibilité du framework.

Première commande : voir où vous en êtes.

$ composer outdated "symfony/*" --patch-only

Elle liste les paquets Symfony qui ont une version corrective plus récente que celle installée. Puis on l'installe :

$ composer update "symfony/*"

Si votre composer.json fixe la branche (7.4.* sur chaque paquet symfony/*, et la même valeur dans extra.symfony.require), cette commande reste sur la 7.4 et prend la dernière version corrective. La précaution est dans les contraintes : un paquet déclaré sans borne, ou en dev-master, peut monter d'une version majeure au passage. Ensuite, comme pour tout changement : les tests, puis le déploiement.

Savoir qu'une faille vous concerne : composer audit

Lire le blog de Symfony ne suffit pas : vos autres dépendances ont aussi leurs failles, et elles ne sont pas annoncées au même endroit.

$ composer audit

Cette commande compare les paquets installés aux avis de sécurité publiés, et rend un code d'erreur dès qu'elle en trouve un. C'est ce détail qui la rend utile : placée dans l'intégration continue ou le script de déploiement, elle fait échouer le build le jour où une faille est publiée sur une de vos dépendances. La documentation de Symfony la recommande pour cet usage, plutôt que symfony check:security, parce qu'elle interroge aussi la base d'avis de GitHub.

Depuis Composer 2.9 (novembre 2025), composer update refuse par défaut d'installer une version visée par un avis de sécurité. C'est un garde-fou utile, mais il n'agit qu'au moment d'une mise à jour : une application qu'on ne met plus à jour garde ses versions vulnérables dans son composer.lock, et composer install les réinstalle sans rien dire. Seul composer audit les signale.

La routine, telle que je la tiens

• Chaque mois : composer audit, composer outdated --patch-only, les mises à jour correctives, les tests, le déploiement. Un quart d'heure quand rien ne coince.
• Le jour d'un avis de sécurité : la même chose, sans attendre le mois suivant, si composer audit dit que l'application est concernée.
• Tous les six mois : la version mineure, en suivant les dépréciations qu'elle annonce, pour que la prochaine version majeure reste un palier et pas un chantier.
• Et PHP : ses versions correctives suivent celles de la distribution du serveur, et sa branche a sa propre date de fin. Celle de PHP 8.2 tombe le 31 décembre 2026.

Sur mes propres applications, composer audit fait partie du build : une faille publiée sur une dépendance le fait échouer avant tout déploiement. En août 2026, c'est ce contrôle, et pas une relecture, qui a attrapé deux failles publiées sur Guzzle, une bibliothèque HTTP très répandue.

Si votre application PHP n'utilise pas Composer

Beaucoup d'applications PHP écrites en interne n'ont pas de composer.json : leurs bibliothèques ont été copiées dans un dossier il y a des années, et personne ne sait plus dans quelle version. Elles n'ont aucune des lignes de défense ci-dessus. Aucun outil ne leur dira qu'une faille est publiée sur ce qu'elles embarquent.

Le premier travail, dans ce cas, n'est pas une mise à jour : c'est l'inventaire. Quelles bibliothèques, dans quelle version, et lesquelles existent sous Composer. Une fois qu'elles y sont, le composer audit du mois suivant dit enfin quelque chose.

Ce qui coûte, c'est le mois sauté

Une version corrective appliquée chaque mois ne coûte presque rien. Ce qui coûte, c'est l'accumulation : douze mois sans mise à jour, et le correctif urgent arrive sur une branche qui n'est plus maintenue, avec des dépendances qui ont pris deux versions majeures entre-temps. Le jour d'un avis de sécurité, on ne fait plus une mise à jour, on fait une migration, et dans l'urgence.

Ce travail régulier, c'est exactement ce que couvre une maintenance Symfony assurée par celui qui code : quelqu'un dont c'est le travail de lancer ces commandes chaque mois, de lire ce qu'elles disent, et de vous prévenir avant que ça devienne un chantier.