Browser Extension Supply Chain Security in 2026: PolinRider’s Chrome Extension, the Cyberhaven Wave & Complete Developer Audit GuideSécurité Supply Chain des Extensions Navigateur en 2026 : l’Extension Chrome PolinRider, la Vague Cyberhaven & Guide Complet d’Audit pour Développeurs

Your browser and your code editor share something increasingly dangerous in common: both rely on a plugin ecosystem that updates silently, runs with elevated privileges, and is managed by marketplaces that cannot review every update in real time. In 2026, attackers have made browser and IDE extensions a primary supply chain attack surface — targeting developer credentials, source code, and cloud tokens with campaigns ranging from North Korean state actors to organized financially motivated groups.

Votre navigateur et votre éditeur de code partagent quelque chose de plus en plus dangereux : tous deux reposent sur un écosystème de plugins qui se met à jour silencieusement, s’exécute avec des privilèges élevés, et est géré par des marketplaces incapables d’examiner chaque mise à jour en temps réel. En 2026, les attaquants ont fait des extensions navigateur et IDE une surface d’attaque supply chain de premier plan — visant les credentials de développeurs, le code source et les tokens cloud avec des campagnes allant des acteurs étatiques nord-coréens aux groupes financièrement motivés.

This guide covers every major 2024–2026 incident in detail, explains how these attacks work, and provides a practical audit and hardening checklist for both Chrome extensions and VS Code extensions that any developer or engineering team can apply today.

Ce guide couvre en détail chaque incident majeur de 2024–2026, explique le fonctionnement de ces attaques, et fournit une checklist pratique d’audit et de durcissement pour les extensions Chrome et VS Code qu’un développeur ou une équipe peut appliquer dès aujourd’hui.

The 2024–2026 Incident Timeline: Chrome & IDE Extensions Under Attack

La Chronologie des Incidents 2024–2026 : Extensions Chrome & IDE Sous Attaque

Extension supply chain attacks did not start in 2026 — but the frequency, scale, and sophistication of these attacks has accelerated sharply. Here is every major incident you need to understand.

Les attaques supply chain sur les extensions n’ont pas commencé en 2026 — mais la fréquence, l’échelle et la sophistication de ces attaques se sont fortement accélérées. Voici chaque incident majeur à comprendre.

December 2024: The Cyberhaven Wave — 36 Extensions, 2.6 Million Users

Décembre 2024 : La Vague Cyberhaven — 36 Extensions, 2,6 Millions d’Utilisateurs

On December 24, 2024, attackers compromised a Cyberhaven employee’s credentials through a targeted phishing campaign and used the access to publish a malicious version of the Cyberhaven Chrome extension directly to the Chrome Web Store. The malicious extension was live from December 25 to December 26 — precisely when security teams were out of office. It exfiltrated session cookies and authenticated sessions from targeted websites.

Le 24 décembre 2024, des attaquants ont compromis les credentials d’un employé de Cyberhaven via une campagne de phishing ciblée et ont utilisé cet accès pour publier une version malveillante de l’extension Chrome Cyberhaven directement sur le Chrome Web Store. L’extension malveillante était active du 25 au 26 décembre — précisément pendant les congés des équipes de sécurité. Elle exfiltrait les cookies de session et les sessions authentifiées.

Further investigation revealed this was not an isolated incident: the same threat actor had compromised at least 35 additional Chrome extensions during 2024, affecting a total of 2.6 million users. The attack pattern was consistent — phishing developer accounts, publishing a poisoned update through the legitimate Chrome Web Store pipeline, and exfiltrating credentials before detection. The actor’s infrastructure showed campaign activity stretching back through 2023, suggesting months of planning before the December push.

Une enquête plus approfondie a révélé qu’il ne s’agissait pas d’un incident isolé : le même acteur malveillant avait compromis au moins 35 extensions Chrome supplémentaires durant 2024, affectant 2,6 millions d’utilisateurs au total. Le schéma d’attaque était cohérent — phishing des comptes de développeurs, publication d’une mise à jour empoisonnée via le pipeline légitime du Chrome Web Store, et exfiltration des credentials avant détection. L’infrastructure de l’acteur montrait une activité de campagne remontant à 2023, suggérant des mois de planification avant l’offensive de décembre.

Early 2025: DarkSpectre and the 3.2 Million User Campaign

Début 2025 : DarkSpectre et la Campagne 3,2 Millions d’Utilisateurs

In February 2025, GitLab Security published a tech note identifying malicious browser extensions impacting at least 3.2 million users. Researchers also tracked the DarkSpectre campaign, attributed to a Chinese threat actor, which harvested corporate meeting data from 2.2 million Chrome and Edge users through compromised productivity extensions. These extensions appeared legitimate — some had been in use for years — before attackers either compromised the developer account or purchased the extension outright and pushed a weaponized update.

En février 2025, GitLab Security a publié une note technique identifiant des extensions malveillantes impactant au moins 3,2 millions d’utilisateurs. Les chercheurs ont également suivi la campagne DarkSpectre, attribuée à un acteur menaçant chinois, qui a volé des données de réunions d’entreprise à 2,2 millions d’utilisateurs Chrome et Edge via des extensions de productivité compromises. Ces extensions semblaient légitimes — certaines étaient utilisées depuis des années — avant que les attaquants ne compromettent le compte du développeur ou n’achètent directement l’extension pour y injecter une mise à jour weaponisée.

January 2026: 30 More Extensions, 260,000 Users Affected

Janvier 2026 : 30 Extensions Supplémentaires, 260 000 Utilisateurs Touchés

In January 2026, security researchers discovered 30 Chrome extensions stealing credentials from over 260,000 users. A new attack pattern emerged alongside classic developer account compromise: ownership transfers. The QuickLens extension changed hands in February 2026, and a malicious update that stripped security headers from web responses landed within days of the transfer. Attackers are now buying clean, popular extensions with established user bases — a model that bypasses the scrutiny applied to new submissions.

En janvier 2026, des chercheurs ont découvert 30 extensions Chrome volant les credentials de plus de 260 000 utilisateurs. Un nouveau schéma d’attaque a émergé aux côtés de la compromission classique des comptes de développeurs : les transferts de propriété. L’extension QuickLens a changé de mains en février 2026, et une mise à jour malveillante supprimant les en-têtes de sécurité des réponses web est arrivée dans les jours suivant le transfert. Les attaquants achètent désormais des extensions propres et populaires avec des bases d’utilisateurs établies — un modèle qui contourne le niveau de scrutin appliqué aux nouvelles soumissions.

July 2026: PolinRider Adds a Chrome Extension to the Attack Surface

Juillet 2026 : PolinRider Ajoute une Extension Chrome à la Surface d’Attaque

When Socket disclosed North Korea’s PolinRider campaign on July 3–6, 2026, the most notable detail was not the 61 malicious Go modules or the 19 npm packages — it was the single Chrome extension included among the 108 malicious artifacts. PolinRider represents Contagious Interview’s expansion beyond traditional package registries into browser and IDE extension marketplaces. The Chrome extension used the same payload architecture as the rest of the campaign: an obfuscated JavaScript loader contacting blockchain RPC infrastructure (TRON, Aptos, BNB Smart Chain) to fetch an encrypted second-stage payload that decrypts to DEV#POPPER RAT and OmniStealer, targeting developer credentials, cryptocurrency wallets, and cloud tokens.

Quand Socket a divulgué la campagne nord-coréenne PolinRider du 3 au 6 juillet 2026, le détail le plus notable n’était pas les 61 modules Go malveillants ni les 19 packages npm — c’était la seule extension Chrome incluse parmi les 108 artefacts malveillants. PolinRider représente l’expansion de Contagious Interview au-delà des registres de packages traditionnels vers les marketplaces d’extensions navigateur et IDE. L’extension Chrome utilisait la même architecture de payload que le reste de la campagne : un loader JavaScript obfusqué contactant l’infrastructure RPC blockchain (TRON, Aptos, BNB Smart Chain) pour récupérer un payload chiffré en deux étapes qui se déchiffre en DEV#POPPER RAT et OmniStealer, ciblant les credentials de développeurs, les portefeuilles crypto et les tokens cloud.

VS Code Extensions: A Wider and Less-Guarded Attack Surface

Extensions VS Code : Une Surface d’Attaque Plus Large et Moins Protégée

Chrome extensions operate in a sandboxed browser context with declared permissions. VS Code extensions are fundamentally different and more dangerous from a supply chain perspective: they are not sandboxed. When you install a VS Code extension, it runs with the same operating system privileges as VS Code itself. It can read every file in your open workspace — including .env.local, .env.production, and any credential file. It can access environment variables set in your shell session. It can spawn child processes, make outbound network requests, and write files — all silently, without any visible permission prompt.

Les extensions Chrome fonctionnent dans un contexte navigateur isolé avec des permissions déclarées. Les extensions VS Code sont fondamentalement différentes et plus dangereuses d’un point de vue supply chain : elles ne sont pas isolées. Quand vous installez une extension VS Code, elle s’exécute avec les mêmes privilèges OS que VS Code lui-même. Elle peut lire chaque fichier de votre workspace ouvert — y compris .env.local, .env.production et tout fichier de credentials. Elle peut accéder aux variables d’environnement définies dans votre session shell. Elle peut également lancer des processus fils, établir des connexions réseau sortantes et écrire des fichiers — le tout silencieusement, sans aucune invite de permission visible.

The Nx Console Breach: 18 Minutes, 3,800 GitHub Repositories

La Brèche Nx Console : 18 Minutes, 3 800 Dépôts GitHub

In May 2026, a compromised version of the Nx Console VS Code extension was live on the official VS Code marketplace for just 18 minutes. During that window, one GitHub employee installed it. The result: 3,800 internal GitHub repositories were exfiltrated, along with GitHub tokens, npm tokens, AWS credentials, and cloud credential stores. Eighteen minutes. One install. 3,800 repos. The timeline illustrates how the VS Code marketplace’s inability to review updates before publication creates an extreme risk window.

En mai 2026, une version compromise de l’extension VS Code Nx Console était active sur le marketplace officiel VS Code pendant seulement 18 minutes. Durant cette fenêtre, un employé GitHub l’a installée. Résultat : 3 800 dépôts GitHub internes ont été exfiltrés, ainsi que des tokens GitHub, des tokens npm, des credentials AWS et des magasins de credentials cloud. Dix-huit minutes. Une installation. 3 800 dépôts.

GlassWorm: 73 Sleeper Extensions in the VS Code Marketplace

GlassWorm : 73 Extensions Dormantes dans le Marketplace VS Code

Dark Reading reported the ongoing GlassWorm campaign, which has deployed 73 so-called “sleeper” extensions in the VS Code marketplace beginning in April 2026. A sleeper extension is published clean to build organic downloads and trust ratings, then weaponized with a malicious update weeks or months later. This defeats the review heuristic of checking install counts and ratings: a sleeper with 50,000 installs and a 4.8-star rating is exactly the kind of extension a developer trusts — which is precisely the point.

Dark Reading a signalé la campagne GlassWorm en cours, qui a déployé 73 extensions « dormantes » dans le marketplace VS Code dès avril 2026. Une extension dormante est publiée propre pour accumuler des téléchargements organiques et des notes de confiance, puis weaponisée avec une mise à jour malveillante des semaines ou des mois plus tard. Cela contourne l’heuristique de référence basée sur les comptages d’installation et les notes : une extension dormante avec 50 000 installations et une note 4,8 étoiles est exactement le type d’extension à laquelle un développeur fait confiance — et c’est précisément le but.

550+ Secrets Embedded in VS Code Extensions

550+ Secrets Intégrés dans des Extensions VS Code

In a supply chain risk study of VS Code marketplaces, Wiz Security found over 550 validated secrets distributed across more than 500 extensions from hundreds of distinct publishers. These included AI provider credentials from OpenAI, Gemini, Anthropic, XAI, DeepSeek, HuggingFace, and Perplexity — embedded directly in the extension code, often as hardcoded API keys left over from development. These secrets can be extracted by anyone who downloads and inspects the extension package, and in some cases the keys remain valid and privileged. PolinRider’s VS Code TaskJacker variant specifically targets the config files of AI coding agents (.claude, .cursor, .gemini) to steal these credentials.

Dans une étude sur les risques supply chain des marketplaces VS Code, Wiz Security a trouvé plus de 550 secrets validés distribués dans plus de 500 extensions provenant de centaines d’éditeurs distincts. Cela incluait des credentials de fournisseurs IA d’OpenAI, Gemini, Anthropic, XAI, DeepSeek, HuggingFace et Perplexity — intégrés directement dans le code de l’extension, souvent comme des clés API hardcodées issues du développement. Ces secrets peuvent être extraits par quiconque télécharge et inspecte le package d’extension, et dans certains cas les clés sont encore valides et privilégiées.

How Browser Extension Supply Chain Attacks Work: The 4 Attack Vectors

Comment Fonctionnent les Attaques Supply Chain sur les Extensions : Les 4 Vecteurs d’Attaque

Understanding the mechanics helps you prioritize your defenses. There are four primary vectors attackers use to compromise browser and IDE extensions in 2026:

Comprendre les mécanismes aide à prioriser les défenses. Il existe quatre vecteurs principaux utilisés par les attaquants pour compromettre les extensions navigateur et IDE en 2026 :

1. Developer account phishing (most common). Attackers send highly targeted phishing emails to extension maintainers, often impersonating Chrome Web Store policy notices or OAuth grant requests. Once the developer account is compromised, the attacker pushes a malicious update through the legitimate publication pipeline. The update inherits the extension’s existing reputation and user base. This was the vector in Cyberhaven (December 2024) and the 36-extension wave.

1. Phishing du compte de développeur (le plus courant). Les attaquants envoient des emails de phishing très ciblés aux mainteneurs d’extensions, se faisant souvent passer pour des avis de politique du Chrome Web Store ou des demandes d’autorisation OAuth. Une fois le compte compromis, l’attaquant pousse une mise à jour malveillante via le pipeline de publication légitime. La mise à jour hérite de la réputation et de la base d’utilisateurs existantes de l’extension. C’était le vecteur utilisé dans Cyberhaven (décembre 2024) et la vague des 36 extensions.

2. Extension acquisition (emerging threat). Attackers purchase established extensions from developers who want to exit. Once the ownership transfer is recorded, they push a malicious update. The QuickLens February 2026 case followed this pattern. This vector is particularly dangerous because it uses legitimate marketplace mechanisms and requires no account compromise. Marketplace due diligence on ownership changes is minimal.

2. Acquisition d’extension (menace émergente). Les attaquants achètent des extensions établies à des développeurs qui souhaitent en sortir. Une fois le transfert de propriété enregistré, ils poussent une mise à jour malveillante. Le cas QuickLens de février 2026 a suivi ce schéma. Ce vecteur est particulièrement dangereux car il utilise des mécanismes légitimes du marketplace et ne nécessite aucune compromission de compte.

3. Sleeper extension seeding (sophisticated, long-term). Attackers publish a benign extension under a convincing developer identity. They invest weeks or months into acquiring organic downloads and positive reviews. Then they push a weaponized update. GlassWorm uses this model at scale in the VS Code marketplace with 73 planted extensions. Detection is extremely difficult: the extension passes all automated checks at submission time.

3. Ensemencement d’extension dormante (sophistiqué, long terme). Les attaquants publient une extension bénigne sous une identité de développeur convaincante. Ils investissent des semaines ou des mois pour acquérir des téléchargements organiques et des avis positifs. Puis ils poussent une mise à jour weaponisée. GlassWorm utilise ce modèle à grande échelle dans le marketplace VS Code avec 73 extensions plantées. La détection est extrêmement difficile.

4. Malicious new publication (targeted & APT). State-sponsored actors like PolinRider/Contagious Interview publish entirely new malicious extensions masquerading as developer utilities. These are typically seeded into developer-specific channels: fake job offer repositories, Contagious Interview’s technical interview packages, VS Code extension recommendations in malicious GitHub repositories. The PolinRider Chrome extension was distributed alongside its npm and Go packages to developers targeted through fake job campaigns.

4. Nouvelle publication malveillante (ciblée, APT). Des acteurs étatiques comme PolinRider/Contagious Interview publient des extensions malveillantes entièrement nouvelles se faisant passer pour des utilitaires de développeurs. Celles-ci sont typiquement injectées dans des canaux spécifiques aux développeurs : de faux dépôts d’offres d’emploi, les packages d’entretiens techniques de Contagious Interview, des recommandations d’extensions VS Code dans des dépôts GitHub malveillants.

Manifest V3: Security Improvements and What It Does Not Solve

Manifest V3 : Améliorations Sécurité et Ce Qu’il Ne Résout Pas

Manifest V3 (MV3) replaced Manifest V2 as Chrome’s extension platform in 2024. Manifest V2 was disabled in stable Chrome in October 2024, and Chrome 151 removed the last enterprise policy override. An extension still shipping MV2 in mid-2026 is unmaintained — a significant red flag.

Manifest V3 (MV3) a remplacé Manifest V2 comme plateforme d’extensions Chrome en 2024. MV2 a été désactivé dans Chrome stable en octobre 2024, et Chrome 151 a supprimé le dernier remplacement de politique enterprise. Une extension qui livre encore MV2 à mi-2026 n’est pas maintenue — un signal d’alarme important.

MV3 brings genuine security improvements: remote code execution is blocked (extensions can no longer fetch and run arbitrary JavaScript at runtime), the declarativeNetRequest API replaces the open-ended webRequest blocking API, and service workers replace persistent background pages, reducing the extension’s ability to maintain long-running malicious processes. These changes meaningfully constrain certain attack patterns.

MV3 apporte de réelles améliorations sécurité : l’exécution de code distant est bloquée (les extensions ne peuvent plus récupérer et exécuter du JavaScript arbitraire au runtime), l’API declarativeNetRequest remplace l’API webRequest ouverte, et les service workers remplacent les pages d’arrière-plan persistantes. Ces changements contraignent réellement certains schémas d’attaque.

However, MV3 does not stop supply chain attacks. The Cyberhaven attack, the 36-extension wave, and the 2026 campaigns all function under MV3: the malicious code is included in the extension package at publication time, not fetched remotely. An attacker who controls the developer account and publishes a new version can include any code they want — MV3 does not restrict what code can be in the package, only what the code can do at certain runtime boundaries. Supply chain attacks on extensions are fundamentally a trust and identity problem, not a runtime capability problem.

Cependant, MV3 ne stoppe pas les attaques supply chain. L’attaque Cyberhaven, la vague des 36 extensions, et les campagnes 2026 fonctionnent toutes sous MV3 : le code malveillant est inclus dans le package d’extension au moment de la publication, pas récupéré à distance. Un attaquant qui contrôle le compte du développeur et publie une nouvelle version peut inclure n’importe quel code — MV3 ne restreint pas ce que le code peut contenir, seulement ce qu’il peut faire à certaines limites de runtime. Les attaques supply chain sur les extensions sont fondamentalement un problème de confiance et d’identité, pas un problème de capacité de runtime.

How to Audit Your Chrome Extensions: A Practical 7-Point Checklist

Comment Auditer Vos Extensions Chrome : Une Checklist Pratique en 7 Points

Auditing your installed extensions is the most immediate action you can take. Open chrome://extensions and work through the following checks for each extension:

L’audit de vos extensions installées est l’action la plus immédiate que vous pouvez prendre. Ouvrez chrome://extensions et parcourez les vérifications suivantes pour chaque extension :

1. Check the permissions against the stated purpose. Click “Details” and review the permissions list. An extension that claims to improve grammar should not have <all_urls> host access, clipboard write permission, or tabs + scripting combined. Wildcard host permissions with no clear need are the single biggest red flag in 2026.
2. Vérifiez les permissions par rapport à l’objectif déclaré. Cliquez sur « Détails » et passez en revue la liste des permissions. Une extension qui prétend améliorer la grammaire ne devrait pas avoir un accès hôte <all_urls>, une permission d’écriture presse-papiers, ou tabs + scripting combinés.
3. Verify Manifest V3 compliance. Extract the .crx file or use Chrome’s extension source viewer to check manifest.json. The field "manifest_version" should be 3. An MV2 extension in mid-2026 is a maintenance red flag.
4. Vérifiez la conformité Manifest V3. Extrayez le fichier .crx ou utilisez le visualisateur de source d’extension de Chrome pour vérifier manifest.json. Le champ "manifest_version" doit être 3.
5. Check for recent ownership changes. Look at the developer identity in the Chrome Web Store listing. If the developer name changed recently (within the last 6 months) and the extension has not communicated this publicly, treat it as a high-risk signal. The QuickLens attack followed an ownership transfer.
6. Vérifiez les changements de propriété récents. Regardez l’identité du développeur dans la fiche Chrome Web Store. Si le nom du développeur a changé récemment (dans les 6 derniers mois) et que l’extension n’a pas communiqué sur ce sujet, traitez-le comme un signal à haut risque.
7. Review recent update history. Read the update notes for the last 3 versions. A sudden update with vague notes (“bug fixes”, “performance improvements”) shortly after an ownership change or developer account reset is a supply chain attack warning sign.
8. Passez en revue l’historique des mises à jour récentes. Lisez les notes des 3 dernières versions. Une mise à jour soudaine avec des notes vagues peu après un changement de propriété ou une réinitialisation de compte est un signal d’attaque supply chain.
9. Scan the source code if it matters to you. Extensions can be inspected by extracting the CRX or using the extension’s unpacked source. Look for fetch() calls to external URLs, base64-encoded strings, obfuscated variable names, and references to blockchain RPC endpoints (the PolinRider/Miasma attack pattern).
10. Analysez le code source si c’est critique. Les extensions peuvent être inspectées en extrayant le CRX ou en utilisant le source unpacké de l’extension. Cherchez les appels fetch() vers des URL externes, les chaînes encodées en base64, les noms de variables obfusqués, et les références aux endpoints RPC blockchain.
11. Apply the principle of least privilege. If an extension asks for more than it needs, remove it and find an alternative. If you cannot find one, consider whether the extension is worth the risk.
12. Appliquez le principe du moindre privilège. Si une extension demande plus que nécessaire, supprimez-la et trouvez une alternative. Si vous n’en trouvez pas, réfléchissez à si l’extension vaut le risque.
13. Run a scheduled quarterly audit. Extensions update silently. Set a calendar reminder to re-review your installed extensions every three months, focusing on ownership changes, new permissions requests, and unexpected update timestamps.
14. Effectuez un audit trimestriel planifié. Les extensions se mettent à jour silencieusement. Définissez un rappel calendrier pour re-vérifier vos extensions installées tous les trois mois, en vous concentrant sur les changements de propriété, les nouvelles demandes de permissions et les horodatages de mise à jour inattendus.

Hardening Your VS Code Extension Stack: Team Policy Guide

Durcir Votre Stack d’Extensions VS Code : Guide de Politique d’Équipe

VS Code extension security requires both individual developer habits and team-level policy enforcement. Individual hygiene alone is insufficient when a single compromised install during an 18-minute window can exfiltrate thousands of repositories.

La sécurité des extensions VS Code nécessite à la fois des habitudes individuelles de développeur et une application de politique au niveau de l’équipe. L’hygiène individuelle seule est insuffisante lorsqu’une seule installation compromise pendant une fenêtre de 18 minutes peut exfiltrer des milliers de dépôts.

Pin your extension versions. VS Code allows pinning extensions to a specific version in extensions.json (workspace recommendations) and via the --install-extension publisher.extension@version CLI flag. Ken Muse’s guide on pinning VS Code extensions demonstrates a pattern where CI/CD installs a specific known-good version rather than always pulling latest. This limits your exposure window to the version you have reviewed.

Fixez les versions de vos extensions. VS Code permet de fixer les extensions à une version spécifique dans extensions.json (recommandations de workspace) et via le flag CLI --install-extension publisher.extension@version. Cela limite votre fenêtre d’exposition à la version que vous avez vérifiée.

Use workspace extension recommendations, not global installs. Store your team’s approved extensions in .vscode/extensions.json and treat global extension installs with skepticism. Workspace-scoped installs are easier to audit and version-pin.

Utilisez les recommandations d’extensions de workspace, pas les installations globales. Stockez les extensions approuvées de votre équipe dans .vscode/extensions.json et traitez les installations globales d’extensions avec scepticisme. Les installations scopeées au workspace sont plus faciles à auditer et à version-fixer.

Block automatic updates in high-security environments. Add "extensions.autoUpdate": false to your workspace or user settings. Review and manually approve each extension update after checking the changelog and source diff. This adds friction, but friction is the point.

Bloquez les mises à jour automatiques dans les environnements haute sécurité. Ajoutez "extensions.autoUpdate": false à vos paramètres workspace ou utilisateur. Examinez et approuvez manuellement chaque mise à jour d’extension après vérification du changelog et du diff source.

Enforce extensions via policy (enterprise). If your organization uses VS Code with managed devices, enforce an approved extension allowlist via Group Policy or MDM configuration. Block extensions that are not on the approved list. Google Workspace admins can enforce similar controls for Chrome extensions across the fleet.

Appliquez les extensions via une politique (entreprise). Si votre organisation utilise VS Code sur des appareils gérés, appliquez une allowlist d’extensions approuvées via Group Policy ou configuration MDM. Bloquez les extensions qui ne sont pas sur la liste approuvée.

Run a secret scan on installed extensions. Tools like Wiz’s supply chain scanner or Trufflehog can scan VS Code extension directories for embedded secrets. Given that Wiz found 550+ validated secrets across 500+ extensions, there is a material chance that one of your installed extensions carries a live credential you did not know about.

Exécutez un scan de secrets sur les extensions installées. Des outils comme le scanner supply chain de Wiz ou Trufflehog peuvent analyser les répertoires d’extensions VS Code à la recherche de secrets intégrés. Étant donné que Wiz a trouvé 550+ secrets validés dans 500+ extensions, il y a une probabilité réelle qu’une de vos extensions installées contienne un credential live que vous ne connaissiez pas.

Enterprise Chrome Extension Policy: Allowlisting for Engineering Teams

Politique Chrome Enterprise pour les Extensions : Allowlisting pour les Équipes Ingénierie

For organizations using Google Workspace or Chrome Enterprise, the most effective control against browser extension supply chain attacks is enforcing an extension allowlist at the browser policy level. This means only explicitly approved extensions can be installed, and any extension update that changes the permission scope requires re-approval.

Pour les organisations utilisant Google Workspace ou Chrome Enterprise, le contrôle le plus efficace contre les attaques supply chain sur les extensions est l’application d’une allowlist d’extensions au niveau de la politique navigateur. Cela signifie que seules les extensions explicitement approuvées peuvent être installées, et toute mise à jour d’extension qui change le scope de permissions nécessite une re-approbation.

Chrome Enterprise & Education policies allow you to: force-install approved extensions (ExtensionInstallForcelist), block all extensions not on the approved list (ExtensionInstallBlocklist: ["*"] + allowlist), and require re-approval on permission scope changes. Categorize acceptable permissions by role — developers may need broader access than other team members — and audit the allowlist quarterly, specifically checking for ownership transfers and unexpected permission scope creep.

Les politiques Chrome Enterprise permettent de : forcer l’installation des extensions approuvées (ExtensionInstallForcelist), bloquer toutes les extensions hors de la liste approuvée (ExtensionInstallBlocklist: ["*"] + allowlist), et exiger une re-approbation lors de changements de scope de permissions. Catégorisez les permissions acceptables par rôle et auditez l’allowlist trimestriellement.

Frequently Asked Questions

Questions Fréquentes