Une faille mémoire discrète, mais dangereuse, a été intégrée silencieusement à Firefox pendant six mois — affectant plus de 180 millions d’utilisateurs — avant d’être découverte par des chercheurs en sécurité.
La vulnérabilité permettait à des attaquants de corrompre la mémoire et d’exécuter potentiellement du code arbitraire via des charges utiles WebAssembly malformées.
« Le système d’IA autonome d’Aisle a découvert cette vulnérabilité subtile liée à une condition aux limites lors de notre analyse approfondie de la sécurité de WebAssembly, révélant des risques importants pour la sécurité mémoire d’environ 180 millions d’utilisateurs de Firefox », a déclaré Stanislav Fort, fondateur et directeur scientifique d’AISLE.
Il a ajouté : « Mozilla a rapidement déployé un correctif. Les navigateurs modernes comptent parmi les plateformes les plus sûres et les plus rigoureusement conçues qui soient, et cette découverte souligne l’importance d’une recherche en sécurité continue, pilotée par l’IA, pour les protéger partout dans le monde. »
L’erreur de code dissimulée qui a exposé les utilisateurs de Firefox
Au cœur de la vulnérabilité (CVE-2025-13016) se trouve une subtile erreur d’arithmétique des pointeurs dans l’implémentation du ramasse-miettes (GC) de WebAssembly de Firefox, plus précisément dans la classe StableWasmArrayObjectElements, où des types de pointeurs incompatibles provoquaient une copie incorrecte des données de tableau intégrées.
Le code vulnérable utilisait des pointeurs adressés par octet (uint8_t*) pour calculer la quantité de données à copier, mais effectuait la copie dans un tampon typé uint16_t.
Lorsque le modèle était instancié pour des valeurs de 16 bits, std::copy() interprétait la plage basée sur les octets comme un nombre d’éléments typés, et non comme un nombre d’octets.
Résultat : un tampon destiné à contenir N éléments de 16 bits en recevait 2N, ce qui entraînait un dépassement de la mémoire de la pile et la corruption des structures de données adjacentes.
Le problème était aggravé par une seconde faille : l’opération de copie ne lisait pas au bon emplacement mémoire.
Au lieu d’utiliser le pointeur dédié à la zone de données du tableau, le code récupérait les données depuis inlineStorage(), un emplacement qui commence par les métadonnées internes de l’objet.
Les premiers octets copiés dans le tampon ne correspondaient donc pas du tout au contenu du tableau : il s’agissait d’informations structurelles sur l’objet WebAssembly lui-même. Cela introduit une imprévisibilité supplémentaire et accroît le risque que la mémoire corrompue puisse être exploitée lors d’une attaque.
Les conditions nécessaires pour exploiter cette faille de Firefox
Tous les chemins d’exécution de Firefox ne font pas appel à la routine défectueuse, ce qui explique pourquoi la vulnérabilité est restée indétectée si longtemps.
Le problème ne se déclenche que lorsque Firefox emprunte un chemin de repli plus lent, autorisant le ramasse-miettes, utilisé pour traiter les tableaux WebAssembly — plus précisément lors de la conversion de ces tableaux en chaînes de caractères.
Dans une séquence classique, le code WebAssembly manipule d’abord un tableau, par exemple un tableau char16_t.
Firefox tente ensuite de convertir ce tableau en chaîne à l’aide d’une opération rapide conçue pour éviter le ramasse-miettes.
Cependant, lorsque certaines conditions — le plus souvent une pression mémoire — font échouer ce chemin rapide, le navigateur bascule vers une routine de repli autorisant le ramasse-miettes.
C’est dans ce chemin de repli que Firefox invoque le constructeur StableWasmArrayObjectElements vulnérable, qui exécute l’opération de copie défectueuse et finit par provoquer un dépassement de la pile, corrompant la mémoire adjacente.
Dans un scénario d’attaque concret, un adversaire pourrait concevoir délibérément un module WebAssembly malveillant afin de manipuler cette séquence à son avantage.
En créant des tableaux de tailles précises, en plaçant volontairement le navigateur sous pression mémoire pour forcer le déclenchement du ramasse-miettes et en répétant le processus de conversion du tableau en chaîne, un attaquant pourrait faire basculer Firefox de manière fiable vers le chemin de repli vulnérable.
Cela crée un environnement contrôlé dans lequel la corruption mémoire qui en résulte peut être dirigée vers une cible choisie sur la pile.
Stratégies d’atténuation de la vulnérabilité de Firefox
Les organisations peuvent réduire leur exposition à la vulnérabilité en appliquant les derniers correctifs de Firefox et en mettant en place des mesures supplémentaires de défense en profondeur pour limiter l’accès des attaquants, contenir les risques d’exploitation et renforcer la sécurité du navigateur.
- Donnez la priorité au déploiement de Firefox 145 ou version ultérieure (ou ESR 140,5+) sur tous les systèmes et vérifiez la conformité des versions à l’échelle de l’organisation.
- Appliquez les politiques de gestion des navigateurs en entreprise afin de limiter les fonctionnalités à haut risque, de renforcer les contrôles du bac à sable et de verrouiller les configurations de sécurité critiques.
- Désactivez temporairement WebAssembly dans les environnements où l’application immédiate des correctifs est impossible, en particulier sur les terminaux fortement exposés.
- Surveillez les journaux du navigateur, les signaux EDR et les données d’analyse des plantages afin de détecter les erreurs mémoire liées à WebAssembly ou tout comportement inhabituel des processus Firefox.
- Déployez des défenses au niveau du réseau — telles que le filtrage DNS, les passerelles web sécurisées et les outils d’évaluation de la réputation des domaines — pour bloquer les contenus web malveillants ou suspects.
- Déployez l’isolation du navigateur ou segmentez les activités de navigation à haut risque afin de contenir les menaces provenant d’utilisateurs qui accèdent régulièrement à des sites non fiables.
- Renforcez les défenses des terminaux et des systèmes d’exploitation en appliquant des paramètres d’atténuation des exploits, le bac à sable des applications et des contrôles d’accès stricts fondés sur le principe du moindre privilège.
Ensemble, ces mesures contribuent à renforcer la cyberrésilience globale.
Les principales leçons de sécurité à tirer de CVE-2025-13016
Cette vulnérabilité souligne les risques croissants qui apparaissent à mesure que les navigateurs adoptent des technologies bas niveau toujours plus complexes, comme le ramasse-miettes de WebAssembly.
Même des erreurs mineures dans des langages présentant des risques pour la sécurité mémoire, comme le C++, peuvent produire des failles de gravité élevée capables d’échapper aux revues de code traditionnelles et aux tests de régression — comme l’illustre cette faille, intégrée avec son propre test, mais restée indétectée pendant six mois.
Cet incident met également en évidence l’importance des outils d’analyse autonomes pour identifier les problèmes subtils de mémoire que les processus classiques d’assurance qualité manquent souvent.
À mesure que WebAssembly s’intègre plus profondément aux applications web modernes, les éditeurs de navigateurs comme les entreprises devront investir dans des protections plus robustes pour prévenir et détecter les erreurs mémoire de bas niveau.
La durée pendant laquelle cette vulnérabilité est restée inaperçue montre pourquoi il est essentiel de maintenir un programme mature de gestion des correctifs pour se défendre contre les risques liés aux navigateurs.