Chaîne zero-day du « patch gap » — des vulnérabilités corrigées dans Chromium et non corrigées dans Chrome, partagées par plusieurs groupes d'espionnage en 1 semaine
Les observations de Volexity ont établi que la chaîne d'attaque BlueMoon, qui enchaîne une sortie du bac à sable V8 de Chrome et un abus de l'ALPC de Windows, était partagée par au moins plusieurs clusters d'origine chinoise. Le correctif était entré dans Chromium, mais n'était pas encore repris dans Chrome stable : nous exposons de façon ordonnée le danger de ce « patch gap ».
Cet article a été traduit par une machine.
Le 15 septembre 2026, Volexity a rapporté que le cluster de menaces présenté comme d'origine chinoise (UTA0560) a utilisé, dans une attaque par courriel ciblé visant plusieurs ONG le 1er septembre, une chaîne d'attaque (appelée BlueMoon) qui enchaîne des vulnérabilités de Google Chrome et de Microsoft Windows. Le lien dans le courriel exploite un XSS réfléchi sur le site d'une université des États-Unis pour conduire vers une infrastructure contrôlée par l'attaquant, où un exploit en 3 étapes se déploie. CVE-2026-85046 obtient une lecture et une écriture arbitraires à l'intérieur du bac à sable V8, CVE-2026-87491 fait sortir du bac à sable du navigateur, et enfin CVE-2026-85880 abuse de l'Advanced Local Procedure Call (ALPC) de Windows pour aboutir à l'injection de code dans le processus Chrome et à l'exécution de code arbitraire. Volexity signale aussi que l'attaquant appliquait un filtre d'exclusion à tout ce qui n'était pas Chrome sur Windows (d'après les comptes rendus de Volexity / The Hacker News).
Analyse (séparée des faits) : ce qui est à relever, c'est le « partage » de la même chaîne d'exploit. Dans les observations de Volexity, autour du moment où UTA0560 a déployé le backdoor de type JavaScript nommé GRIMWEDGE (un point d'appui initial de capacité moyenne, qui reçoit des ordres par eval depuis le C2), JungleBamboo (APT31) a aussi déployé le chargeur SUPERSTOMP avec la même chaîne, puis a fini par installer l'extension Chrome de vol d'informations LONGTALE, qui se fait passer pour l'extension légitime Google Gemini. Les titres de la presse rapportent que « 4 groupes d'espionnage ont utilisé le même kit en 1 semaine » (The Hacker News), et la possibilité est suggérée que des développeurs aient reconstruit l'exploit à partir des différences de source de Chromium et l'aient fourni à plusieurs clusters. Une structure dans laquelle les exploits circulent comme un « produit » signifie que la généralisation de la surface d'attaque est rapide.
Le point le plus intéressant sur le plan technique est le patch gap. Les correctifs des 2 vulnérabilités de Chrome (CVE-2026-85046 / CVE-2026-87491) avaient été livrés en commit en amont dans le code open source de Chromium, mais n'étaient pas encore inclus dans la version stable de Chrome. Pour un logiciel dont l'historique des commits est public, le risque de reconstruire du code d'attaque à partir du diff de correctif est toujours présent ; cette affaire est toutefois un exemple réel où un état, distinct à la fois d'un N-day ordinaire et d'un zero-day — « corrigé en amont, non corrigé en aval » — a été utilisé dans une attaque réelle. Le fait que le cycle de version majeure de Chrome ait été de 4 semaines jusqu'à récemment (il est maintenant de 2 semaines) peut aussi être tenu pour l'un des facteurs qui rendaient la fenêtre plus facile à viser pour les attaquants, mais on ne peut pas l'affirmer. Volexity indique que, plus les LLM accélèrent la recherche de vulnérabilités et le développement d'exploits, plus le danger du patch gap augmente.
Implications pour la défense : (1) Le premier point de contact de l'attaque ciblée était un « XSS réfléchi sur un site légitime ». Avant la défense de périmètre, il devient important de ne pas laisser le XSS de son propre site servir de tremplin à la chaîne. (2) Face à une chaîne qui traverse à la fois le navigateur et le système d'exploitation, l'isolation du navigateur (isolation des sites, bac à sable forcé) et la détection sur le point de terminaison ont toutes deux un sens. (3) Le patch gap ne se prévient pas par « la rapidité d'application des correctifs ». C'est un domaine où, pour la première fois, ont un effet les équipes qui suivent les commits en amont, et l'attention, côté éditeur, au risque de publier un correctif avant la version. (4) Face à une usurpation d'extension comme LONGTALE, l'inventaire des extensions installées est une mesure réaliste. Les faits du présent article reposent sur le rapport de Volexity et sur les comptes rendus de The Hacker News et de BleepingComputer ; la partie analyse est rédigée séparément des faits.