Mozilla a publié le 21 juillet 2026 l’avis de sécurité MFSA 2026-68 pour Firefox 153. L’éditeur classe l’impact global comme élevé et répertorie plusieurs familles de vulnérabilités : contournement de la politique de même origine, erreurs de gestion mémoire, sorties de bac à sable, élévations de privilèges, problèmes dans WebRTC, JavaScript, WebAssembly, les composants graphiques et certaines fonctions d’accessibilité.
Pour une entreprise, la bonne réponse n’est pas de recopier une liste de CVE dans un tableau. Elle consiste à vérifier que les navigateurs réellement utilisés ont reçu la version corrigée, que les postes hors ligne ou rarement connectés ne sont pas oubliés et que les politiques de mise à jour ne créent pas une fausse impression de conformité.
Pourquoi le navigateur doit être traité comme une application critique
Le navigateur n’est plus un simple outil de consultation. Il ouvre les applications métiers, transporte les sessions d’authentification, donne accès aux messageries, aux outils collaboratifs, aux consoles cloud et à une partie croissante des données de l’entreprise. Une vulnérabilité qui touche l’isolation entre sites, le bac à sable ou le moteur JavaScript concerne donc directement la surface d’attaque du poste de travail.
L’avis de Mozilla cite notamment un contournement de la politique de même origine dans la navigation, plusieurs problèmes de type use-after-free, des possibilités de sortie du bac à sable et des erreurs liées au JIT et à WebAssembly. Il ne faut pas en déduire qu’un incident est en cours dans chaque organisation. L’avis officiel indique ce qui est corrigé et le niveau d’impact ; il ne remplace ni l’analyse d’exposition interne ni les renseignements de menace propres à l’entreprise.
Le premier objectif est plus simple : éviter qu’un navigateur connu comme vulnérable continue d’être utilisé alors qu’une version corrigée existe.
Étape 1 : distinguer inventaire théorique et versions réellement actives
Un outil de gestion de parc peut indiquer que Firefox 153 a été déployé. Cette information ne prouve pas que tous les utilisateurs l’exécutent. Certains postes restent éteints, d’autres sont hors réseau, certains profils utilisent une installation autonome et quelques machines peuvent conserver une version épinglée pour une ancienne application.
L’inventaire utile doit répondre à quatre questions :
- Combien de postes ont lancé Firefox au cours des trente derniers jours ?
- Quelle version exacte a été observée au dernier démarrage de l’application ?
- Quels postes restent sur un canal ESR, et quelle version ESR est attendue ?
- Quelles exceptions empêchent ou retardent l’installation automatique ?
La différence entre « paquet distribué » et « version exécutée » mérite d’être suivie comme un indicateur. Une campagne peut afficher 98 % de réussite tout en laissant plusieurs dizaines de navigateurs réellement actifs sur une branche non corrigée.
Étape 2 : vérifier les politiques de mise à jour
Mozilla documente plusieurs politiques d’entreprise qui influencent directement la correction du parc. AppAutoUpdate autorise l’installation automatique des mises à jour dans Firefox. BackgroundAppUpdate, lorsqu’elle est applicable, permet une installation en arrière-plan. À l’inverse, DisableAppUpdate, ManualAppUpdateOnly ou un épinglage de version peuvent maintenir un poste en retard.
La vérification ne doit pas se limiter au fichier de politique central. Il faut contrôler ce qui est effectivement appliqué sur les terminaux. Sur Firefox, la page about:policies permet de voir les politiques actives et leurs éventuelles erreurs. Pour une flotte gérée, ce contrôle peut être automatisé à partir des outils de configuration et d’inventaire déjà en place.
Trois anomalies reviennent souvent :
- une politique historique désactive encore les mises à jour ;
- un canal ESR et un canal standard sont mélangés dans le même groupe ;
- un épinglage de version a été créé pour résoudre un incident ancien, puis jamais retiré.
Une exception peut être légitime. Elle doit toutefois avoir un propriétaire, une date d’expiration et une mesure compensatoire.
Étape 3 : tester vite, mais sur les bons usages
Reporter une mise à jour pendant plusieurs semaines au nom de la compatibilité déplace le risque sans le supprimer. À l’inverse, déployer sans test sur une application critique peut créer un incident d’exploitation. La solution n’est pas un compromis vague, mais un anneau de validation court.
Constituez un groupe pilote représentatif : authentification forte, visioconférence, outils WebRTC, applications utilisant WebAssembly, extensions d’entreprise, téléchargement de fichiers et impression de documents. Les composants mentionnés dans l’avis Mozilla aident à choisir les scénarios prioritaires, sans transformer chaque CVE en test individuel.
Le test doit être borné dans le temps. Pour une mise à jour classée « élevée », quelques heures ou une journée peuvent suffire selon la taille de l’organisation. Si un problème est détecté, documentez l’application concernée et ouvrez une exception précise. Ne bloquez pas tout le parc sans preuve.
Étape 4 : mesurer la fermeture réelle de l’écart
Après le déploiement, trois chiffres sont plus utiles qu’un statut vert :
- part des navigateurs actifs sur la version cible ;
- nombre de postes vulnérables encore connectés ;
- âge de la plus ancienne exception.
Ajoutez une liste nominative des responsables de traitement, mais évitez de transformer le tableau de bord en inventaire infini. Le décideur doit voir si le risque diminue, stagne ou augmente.
Les postes nomades méritent un contrôle spécifique. Une machine qui ne revient jamais sur le réseau interne peut tout de même accéder aux services cloud. Les mises à jour doivent donc fonctionner hors VPN lorsque la politique de sécurité le permet, ou déclencher une action de conformité avant l’accès aux applications sensibles.
Étape 5 : conserver une preuve simple et réutilisable
Pour cette campagne Firefox, conservez :
- l’avis Mozilla ayant déclenché l’action ;
- la version cible et les canaux concernés ;
- la date de validation du groupe pilote ;
- la courbe de déploiement ;
- la liste des exceptions et leur expiration ;
- la date du contrôle final.
Cette preuve aide lors d’un audit, mais surtout lors de la prochaine alerte. L’équipe ne repart pas de zéro : elle sait où se trouvent les postes difficiles à joindre, quelles applications exigent un test et quelles politiques peuvent bloquer la correction.
Firefox 153 corrige des vulnérabilités dont l’impact est officiellement classé élevé. La décision pratique est immédiate : vérifier les versions exécutées, corriger les politiques qui retardent les mises à jour, tester les usages critiques et suivre les exceptions jusqu’à leur fermeture.
