Faille Chromium exposée par Google
ce que l’on sait vraiment en septembre 2026.

La vulnérabilité concerne Background Fetch, une API expérimentale de Chromium conçue pour permettre à un site de poursuivre le téléchargement d’un fichier volumineux en arrière-plan. Elle s’appuie sur les Service Workers, des scripts exécutés par le navigateur indépendamment de la page web visible.

Le scénario décrit par la chercheuse indépendante Lyra Rebane consiste à enregistrer un Service Worker lors de la visite d’un site, puis à lancer et relancer des tâches Background Fetch de façon à maintenir ce worker actif. Le site peut ainsi conserver une capacité d’exécution JavaScript en arrière-plan alors que l’utilisateur ne voit plus la page qui l’a déclenchée.

Selon le navigateur et son comportement, cette activité peut persister ou reprendre après la fermeture du navigateur, voire après un redémarrage. C’est précisément cette persistance inhabituelle qui rend le problème préoccupant : une visite peut suffire à inscrire le navigateur dans une infrastructure contrôlée à distance sans installer un programme classique.

Il faut néanmoins corriger une formulation importante du premier article. Ce mécanisme n’équivaut pas, à lui seul, à une exécution de code arbitraire sur le système d’exploitation. Le JavaScript reste soumis aux capacités et aux restrictions du navigateur. Il ne donne pas automatiquement accès aux fichiers personnels, aux mots de passe enregistrés ou à l’ensemble de la machine.

Cette distinction est essentielle en cybersécurité. Comme pour les failles Microsoft Defender, le niveau de risque dépend de ce que la vulnérabilité autorise réellement et de son éventuelle combinaison avec d’autres failles.

Lyra Rebane a signalé le problème à l’équipe Chromium en décembre 2022. Les éléments rendus publics en mai 2026 montrent que le ticket avait été reconnu comme valide et traité comme un sujet de sécurité sérieux.

L’article initial parlait de « 29 mois sans correctif ». Ce chiffre, repris par plusieurs publications de mai, ne correspond pas à la chronologie calendaire : de décembre 2022 à mai 2026, il s’est écoulé environ 41 à 42 mois. Les sources anglophones les plus détaillées parlent d’ailleurs de 42 mois.

Une partie du problème avait fait l’objet de modifications intermédiaires, notamment autour de l’interface visible des téléchargements, sans supprimer le mécanisme de persistance décrit par la chercheuse. C’est ce décalage qui explique qu’un ticket ait pu donner l’impression d’être résolu alors que le comportement exploitable restait reproductible.

Le cas illustre une difficulté classique des grands projets logiciels : une vulnérabilité peut toucher plusieurs composants, dépendre d’une API conçue pour un usage légitime et ne pas se réduire à une seule ligne de code à corriger.

Pour comparer avec une faille ayant un périmètre différent, notre analyse de YellowKey et BitLocker montre pourquoi il faut toujours distinguer la technique d’exploitation, les prérequis et les conséquences concrètes.

Le 20 mai 2026, les restrictions qui protégeaient le ticket Chromium ont été levées alors que le problème n’était pas corrigé. Le rapport, les explications techniques et un code de démonstration sont devenus accessibles publiquement.

Google a rapidement restreint de nouveau l’accès au ticket, mais trop tard pour empêcher sa copie. Des archives et des articles de sécurité avaient déjà enregistré les informations. C’est cette séquence qui a transformé un bug connu de manière privée en vulnérabilité documentée publiquement.

La publication d’un proof of concept ne signifie pas qu’une campagne criminelle à grande échelle existe déjà. Elle réduit cependant la barrière technique pour reproduire le comportement. Rebane a expliqué que l’utilisation du code était relativement simple, tout en précisant que l’exploitation de dizaines de milliers de navigateurs demanderait une infrastructure supplémentaire.

Nous n’avons trouvé aucune preuve publique permettant d’affirmer qu’un botnet massif exploite actuellement cette faille. Il faut donc distinguer trois niveaux : le code de démonstration est public, l’exploitation est techniquement plausible, mais l’existence d’une campagne généralisée n’est pas confirmée.

Cette distinction entre possibilité technique et attaque observée est également centrale dans notre article sur la cyberattaque GitHub via une extension VS Code.

Le principal risque est l’utilisation du navigateur comme relais. Un attaquant pourrait maintenir une connexion et demander à un ensemble de navigateurs compromis d’effectuer certaines requêtes réseau. À grande échelle, cette capacité peut servir de proxy distribué ou participer à des attaques par déni de service.

Le navigateur pourrait aussi être utilisé pour consulter des ressources ou générer du trafic sous l’adresse IP de la victime. Pour l’utilisateur, le danger n’est donc pas seulement une baisse de performances : son accès Internet peut devenir un maillon d’une activité qu’il n’a jamais autorisée.

Ars Technica décrit ce scénario comme une forme de porte dérobée limitée : les capacités restent celles du navigateur. L’intérêt offensif augmente fortement si cette persistance est combinée ultérieurement à une autre vulnérabilité permettant de sortir du bac à sable ou d’obtenir des droits supplémentaires.

Le premier article évoquait directement « espionnage » et « vol de données ». Ces termes doivent être encadrés. La vulnérabilité peut permettre une surveillance de certaines activités du navigateur et une utilisation abusive de ses capacités réseau, mais les sources disponibles ne démontrent pas un accès direct et général aux mots de passe, cookies protégés ou fichiers locaux.

Il n’est donc pas exact de dire qu’une simple visite « infecte le PC » au sens classique. Une page malveillante peut déclencher le mécanisme dans un navigateur vulnérable, ce qui est déjà sérieux, mais l’impact reste borné par le modèle de sécurité du navigateur tant qu’aucune autre faille n’est ajoutée à la chaîne.

Le problème se situe dans Chromium et plus précisément autour de Background Fetch. Les navigateurs qui reprennent cette technologie sont donc les premiers concernés. Chrome, Microsoft Edge, Brave, Opera et d’autres navigateurs Chromium prennent en charge ou ont pris en charge cette API.

Il faut néanmoins éviter l’affirmation absolue « tous les navigateurs Chromium sont vulnérables ». Un navigateur dérivé peut désactiver une API, modifier son comportement, intégrer un correctif propre ou utiliser une version différente du moteur. Le risque doit donc être apprécié version par version.

Firefox n’utilise pas Chromium et ne prend pas en charge Background Fetch dans les données de compatibilité actuelles. Safari ne prend pas non plus en charge cette API. Ils ne sont donc pas concernés par cette vulnérabilité Chromium spécifique.

Cela ne signifie évidemment pas que Firefox ou Safari sont exempts de failles. Changer de navigateur réduit l’exposition à ce mécanisme précis, pas au risque informatique en général.

Pour replacer le sujet dans l’évolution des systèmes, notre article sur Windows 11 et les changements de sa recherche détaille également plusieurs évolutions Microsoft de 2026.

Et pour les usages sur d’autres appareils, notre sélection des meilleures liseuses 2026 permet de distinguer les écosystèmes logiciels qui reposent ou non sur des technologies de navigateur comparables.

Le point le plus important de cette actualisation est paradoxal : au 8 septembre 2026, nous n’avons trouvé dans les communications publiques de Chromium ou de Chrome aucune annonce permettant d’affirmer que la vulnérabilité décrite en mai a reçu un correctif spécifique.

En revanche, l’avenir de Background Fetch a changé. Chromium avait déjà annoncé en novembre 2025 son intention de déprécier cette API, en raison de son adoption extrêmement faible et du coût de maintenance, y compris les problèmes de sécurité. Cette dépréciation constitue une évolution structurelle, mais elle ne doit pas être présentée comme le correctif de la faille de Rebane.

En août 2026, Chromium a également annoncé de nouvelles restrictions Local Network Access pour Background Fetch. Elles imposent des contrôles de permission avant que des requêtes Background Fetch puissent atteindre le réseau local ou l’adresse de boucle locale. Cette mesure ferme une autre surface d’abus réseau, mais la documentation publique ne permet pas de l’assimiler au correctif du problème de persistance exposé en mai.

Autrement dit, le composant est en voie de réduction et de durcissement, mais l’état précis du ticket initial doit rester formulé avec prudence. En l’absence d’un bulletin officiel disant explicitement « cette vulnérabilité est corrigée dans telle version », il serait imprudent de déclarer le dossier clos.

Les grands éditeurs modifient actuellement très vite leurs navigateurs et assistants. Notre comparatif Gemini vs ChatGPT en 2026 et notre analyse de Gemini Intelligence sur Android montrent la même accélération des fonctions connectées au système.

Le premier réflexe reste de maintenir son navigateur à jour. Même si aucune note publique ne permet d’attribuer un correctif précis à cette faille, les mises à jour Chromium corrigent continuellement d’autres vulnérabilités et peuvent modifier les composants impliqués.

Évitez les liens provenant de messages inattendus, les sites de téléchargement douteux et les pages qui vous sont envoyées par des expéditeurs inconnus. Dans ce scénario, l’exposition commence par la visite d’une page contrôlée par l’attaquant.

Un bloqueur de contenus peut réduire certaines voies d’arrivée vers des pages malveillantes, mais il ne constitue pas un correctif. L’article initial recommandait uBlock Origin comme mesure de protection : cette recommandation doit être comprise comme une réduction de surface d’exposition, pas comme une garantie contre Background Fetch.

Un antivirus peut détecter certaines activités annexes, mais le comportement décrit se produit dans le navigateur avec des mécanismes web légitimes détournés. L’absence d’alerte antivirus ne permet donc pas de conclure que le navigateur n’a jamais exécuté ce type de tâche.

Pour un poste professionnel particulièrement sensible, l’utilisation temporaire d’un navigateur qui ne prend pas en charge Background Fetch peut être envisagée pour les usages les plus exposés. Il faut cependant tenir compte des contraintes métier, des extensions et des politiques de sécurité de l’entreprise.

Enfin, il n’existe pas de symptôme simple permettant à un particulier d’identifier cette exploitation. Des ralentissements ou du trafic réseau inhabituel peuvent avoir des dizaines d’autres causes. L’article initial présentait ces signes comme des moyens de détection ; ils ne sont en réalité que des indices très peu spécifiques.

Le bon niveau de réponse consiste donc à appliquer les mises à jour, limiter les visites à risque et suivre les annonces Chromium, sans transformer chaque ralentissement de Chrome en preuve d’une compromission.