Qui a changé la recette ?

Une extension Claude Code altérée sur la marketplace de Cursor et un script fournisseur détourné sur Polymarket, à quelques heures d’intervalle.

Le 29 octobre, deux choses ont mal tourné à quelques heures d’intervalle, dans deux endroits très différents.

Le matin, la marketplace d’extensions de Cursor a commencé à distribuer une copie altérée de l’extension Claude Code. Presque chaque octet était le vrai code d’Anthropic, avec en plus un petit loader qui installait une porte dérobée SSH.

L’après-midi, un script de mesure des performances que Polymarket chargeait depuis son fournisseur, DebugBear, a été remplacé. Au lieu de mesurer la vitesse des pages, il utilisait les sessions des traders connectés pour vendre leurs positions et déplacer leurs fonds. Les analystes ont retracé environ 2,57 millions de dollars jusqu’au wallet de l’attaquant.

Personne n’a installé quoi que ce soit d’étrange. Les développeurs ont accepté la mise à jour d’une extension familière. Les traders ont ouvert le site qu’ils utilisent toujours. L’étiquette était la bonne. C’est la recette qui avait changé.

Ce numéro pose donc la question : que veut dire « source de confiance » quand quelqu’un d’autre peut modifier ce qu’elle distribue ? L’analyse approfondie examine ce qu’une marketplace devrait vérifier au-delà du nom de l’éditeur, et la recherche technique explique comment le drainer de Polymarket a réutilisé le propre client de trading de la page.

Dans ce numéro

🌡️ Niveau de menace : Alerte élevée
⚡ Actualités : le FBI attribue le vol chez Binance à la Corée du Nord, des versions de LiteLLM et de l’OVHcloud CLI remplacées, Storm-0940 cible des tenants Microsoft 365 via un fournisseur de sauvegarde
🔎 Analyse approfondie : L’éditeur était légitime. La mise à jour avait été altérée.
🎣 Est-ce du phishing ?
🔬 Recherche technique : Il mesurait la vitesse des pages. Puis il a vendu vos positions.
🛠️ Outil de la semaine : osquery
👏 Personnalité de la semaine : Paul McCarty
📅 Événement de la semaine : Open Source SecurityCon 2026
📚 Livre de la semaine : Software Supply Chain Security
😅 Le mème
❓ Une question avant de partir

C’est parti.

🌡️Niveau de menace

⚡Section 01 : Actualités

Crypto, format géant

Le FBI attribue à la Corée du Nord le vol de 6,3 milliards de dollars chez Binance

Binance a confirmé un vol d’environ 6,3 milliards de dollars, le plus important vol de cryptomonnaies jamais enregistré. Les sociétés d’analyse blockchain TRM Labs et Chainalysis l’ont attribué à TraderTraitor, un groupe nord-coréen, et le 31 octobre le FBI l’a confirmé, en désignant les mêmes acteurs que ceux du piratage de Bybit, 1,5 milliard de dollars, en 2025.

Les premiers rapports mettaient en cause un seul ordinateur portable compromis. Binance a depuis indiqué que son enquête avait trouvé d’autres points d’intrusion, et le point d’entrée reste flou. Binance affirme avoir remplacé environ 90 % des fonds volés avec l’argent de l’entreprise, et Tether dit avoir gelé environ 1,57 milliard de dollars d’actifs liés au vol.

Selon le FBI, la plupart des actifs volés sont en cours de conversion en ether, et il s’attend à ce que le reste transite par des plateformes DeFi et des services d’échange instantané.

Pourquoi c’est important : Le précédent record, Bybit, a été établi par le même groupe il y a moins de deux ans. Ce vol est environ quatre fois plus important. TraderTraitor n’est pas une bande opportuniste qui a eu de la chance une fois. C’est une unité étatique qui continue de s’introduire dans les entreprises qui détiennent le plus d’argent.

Regardez ce qui pouvait être bloqué et ce qui ne le pouvait pas. Tether a gelé 1,57 milliard de dollars parce que Tether peut geler les jetons qu’il émet. L’ether n’a pas d’émetteur à appeler. Chaque heure que les attaquants passent à convertir les jetons volés en actifs que personne ne peut geler réduit ce qui peut être récupéré, et c’est pourquoi la conversion est déjà en cours.

L’évolution du récit sur le point d’entrée compte aussi. « Un seul ordinateur portable compromis » était une explication nette, et elle était fausse, ou du moins incomplète. Les premières explications des grandes fuites le sont souvent. Tant que le chemin complet n’est pas connu, personne ne peut dire quels contrôles ont échoué.

Si vous travaillez dans la crypto ou la fintech, ou à proximité, traitez le mode opératoire documenté de TraderTraitor comme une menace directe : faux recruteurs, tests de code à faire chez soi et paquets malveillants visant les ingénieurs. Gardez l’infrastructure de signature hors des ordinateurs portables que les ingénieurs utilisent au quotidien, et établissez des contacts avec les émetteurs de stablecoins avant d’avoir besoin d’un gel, pas après.

Empêcher le vol est la première ligne de défense. Une fois les jetons convertis en ether, la fenêtre de la seconde se referme.

Attribution du FBI (BleepingComputer) · Attribution de TRM Labs et Chainalysis · Point sur l’enquête de Binance (ITPro)

Des versions réchauffées

Des versions de LiteLLM et de l’OVHcloud CLI remplacées par des voleurs de secrets

Le 21 octobre, des builds malveillants de LiteLLM version 1.107.0 ont été publiés sur PyPI, ainsi que des images de conteneur compromises, après que des attaquants ont mis la main sur des jetons OAuth de GitHub CLI. LiteLLM est une passerelle très utilisée entre les applications et les fournisseurs de modèles d’IA. La fenêtre d’exposition sur PyPI a duré environ deux heures. L’analyse de Microsoft a montré que le payload s’exécutait via des hooks de démarrage Python, si bien qu’une machine qui avait seulement installé le paquet pouvait laisser fuiter des secrets sans jamais l’importer.

Deux jours plus tôt, le 19 octobre, un attaquant a utilisé un compte de contributeur détourné pour remplacer les téléchargements de cinq versions de l’OVHcloud CLI (v0.11.0 à v0.15.0) sur GitHub par des builds voleurs de secrets, pendant jusqu’à 94 minutes. L’attaquant n’a jamais touché au pipeline de build d’OVHcloud. L’immuabilité des releases était désactivée, donc les fichiers pouvaient simplement être remplacés. OVHcloud les a supprimés, a publié une v0.16.0 saine sous forme de release immuable et a activé le paramètre.

Pourquoi c’est important : Dans les deux cas, l’attaque a eu lieu à la dernière étape : la version que les gens téléchargent. L’attaquant d’OVHcloud n’a pas du tout touché au pipeline de build, et les builds de LiteLLM ont été publiés avec des jetons volés. Ni la revue du code source ni la sécurisation de la CI n’auraient permis de détecter l’une ou l’autre.

Les fenêtres courtes sont moins rassurantes qu’il n’y paraît. Deux heures et 94 minutes, c’est court pour un humain, mais les pipelines CI qui récupèrent la dernière version tournent en permanence. Et avec LiteLLM, l’installation suffisait. Chaque runner de build et chaque ordinateur portable qui a récupéré la 1.107.0 a livré tous les secrets qu’il détenait, y compris les clés d’API qu’une passerelle IA existe justement pour gérer.

Le cas d’OVHcloud montre aussi combien de temps les attaquants savent attendre. Comme l’a découvert Paul McCarty (plus de détails dans la Personnalité de la semaine de ce numéro), le compte utilisé pour remplacer les versions était compromis depuis sept mois. Les identifiants volés des développeurs n’expirent pas simplement parce que personne ne s’en est encore servi.

Épinglez les dépendances par hash, et pas seulement par version, et attendez quelques jours avant d’adopter les toutes nouvelles versions quand c’est possible. Si vous maintenez un projet, activez les releases immuables et utilisez des jetons de publication à courte durée de vie. Si vous avez installé l’un de ces outils pendant sa fenêtre, renouvelez tous les secrets auxquels la machine avait accès, depuis une machine saine.

Un dépôt sain vous dit ce que les mainteneurs ont écrit. Il ne vous dit pas ce que vous avez téléchargé.

Compromission de LiteLLM (SecurityWeek) · Compromission de l’OVHcloud CLI (SecurityWeek) · Lien avec GlassWorm (Dark Reading)

Sauvegardes, accès en supplément

Storm-0940 a utilisé l’accès applicatif d’un fournisseur de sauvegarde pour cibler 2 250 tenants Microsoft 365

ConnectWise a révélé le 16 octobre une intrusion dans son service Cloud Backup (anciennement SkyKick). Le 21 octobre, Microsoft a attribué l’activité qui a suivi à Storm-0940, un groupe aligné sur la Chine.

Cloud Backup permet aux prestataires de services informatiques de sauvegarder les données Microsoft 365 de leurs clients, donc ses applications disposaient déjà d’un consentement dans ces tenants. Les attaquants ont utilisé les identités de ces applications pour tenter de se connecter à plus de 2 250 tenants. Microsoft indique que la plupart des tentatives ont échoué, mais que le groupe a obtenu une persistance privilégiée dans un certain nombre d’organisations, parfois moins de trois heures après les avoir ciblées pour la première fois. La Chine a démenti ces accusations.

Pourquoi c’est important : Aucun utilisateur n’a été victime de phishing et aucune demande MFA n’a été contournée, car aucune n’était en jeu. Les applications se connectent avec leurs propres secrets ou certificats, et dans beaucoup de tenants, les politiques de connexion et les alertes sont conçues autour des personnes. Les connexions des applications échappent souvent aux deux.

L’accès lui-même était le butin. Une application de sauvegarde doit lire les e-mails, les fichiers et les sites de tout le tenant, c’est exactement l’accès que recherche un attaquant. Un seul consentement, accordé une fois par un administrateur, peut tout couvrir.

« La plupart des tentatives ont échoué » n’est pas très rassurant non plus. Le modèle des prestataires de services fait qu’un seul fournisseur se connecte à des milliers de tenants, donc même un faible taux de réussite finit par compter. Et moins de trois heures entre la première tentative et la persistance laisse peu de temps pour réagir.

La persistance est ce qui survit au correctif. Une fois l’accès privilégié obtenu, les attaquants pouvaient ajouter leurs propres identifiants, applications ou attributions de rôles. Supprimer l’application du fournisseur ne supprime rien de tout cela.

Vérifiez quelles applications tierces disposent d’un consentement dans votre tenant et quelles autorisations elles ont. Consultez les journaux de connexion des applications et recherchez les identifiants, applications ou attributions de rôles ajoutés depuis la mi-octobre. Si un prestataire gère votre tenant, demandez-lui directement s’il utilisait Cloud Backup.

Révoquer l’accès du fournisseur est l’étape facile. La question utile, c’est ce qui a été ajouté pendant qu’il était là.

Attribution par Microsoft (Dark Reading)

🔎Section 02 : Analyse approfondie

L’éditeur était légitime. La mise à jour avait été altérée.

Les développeurs qui ont installé l’extension Claude Code depuis la marketplace de Cursor le 29 octobre ont fait ce qu’on leur dit de faire. Ils ont utilisé le store intégré à leur éditeur, choisi une extension d’un éditeur bien connu et accepté la mise à jour. Pendant environ 11 heures, cela suffisait pour récupérer une porte dérobée SSH.

L’éditeur était réel. Le store aussi. Ce qui a changé, c’est le paquet entre les deux, et le paquet altéré a atteint les utilisateurs malgré les contrôles de distribution en place.

Ce qui s’est passé

Cursor a indiqué qu’un acteur malveillant « a utilisé un accès à la marketplace de Cursor pour publier une extension altérée ciblant les utilisateurs de Cursor ». Les builds altérés, versions 2.1.312 et 2.1.313 pour Windows et macOS, étaient disponibles d’environ 2 h 27 à 13 h 35, heure du Pacifique, et ont atteint au plus 5 000 utilisateurs. Cursor les a supprimés, a temporairement suspendu toute sa marketplace d’extensions, audité les accès et renouvelé les clés.

Anthropic a indiqué que les versions de ses canaux officiels ne sont pas affectées, que la 2.1.313 n’a jamais été publiée sur Open VSX, sur le Microsoft Visual Studio Marketplace ni sur aucun de ses hébergements officiels, et que l’incident n’était « pas une compromission des systèmes d’Anthropic ni des ordinateurs portables de ses employés ». Elle a publié une 2.1.314 saine. Aucune des deux entreprises n’a dit comment l’attaquant a obtenu l’accès de publication.

Ce que faisait le build altéré

D’après l’analyse de StepSecurity, l’attaquant a pris le build sain 2.1.312 d’Anthropic et a ajouté un loader de 7 386 octets au début de son extension.js. Le reste du fichier correspondait à l’original. Le loader n’était pas obfusqué et s’exécutait sous Node.js standard dès le chargement de l’extension, sans qu’aucune conversation avec Claude soit nécessaire.

En six étapes, il collectait les informations de l’hôte et les noms des variables d’environnement correspondant à des motifs comme KEY, TOKEN et AWS, ajoutait une clé SSH nommée svc-telemetry à ~/.ssh/authorized_keys, activait SSH, ouvrait un tunnel inverse vers 134.209.82.225, mettait en place une persistance (un LaunchAgent nommé com.apple.sysmond sur macOS, une tâche planifiée SysMon sur Windows) et rendait compte de son état au serveur de l’attaquant.

Supprimer l’extension ne supprime rien de tout cela.

Ce qu’une marketplace doit vérifier au-delà du nom de l’éditeur

Une fiche vous dit qui a écrit le code d’origine. Elle ne vous dit pas qui a construit ou envoyé ce paquet précis. Le cas Cursor met en évidence trois vérifications que le nom seul ne peut pas remplacer. Deux d’entre elles ne vérifient que les numéros de version et auraient détecté la fausse 2.1.313. Seule la troisième vérifie le contenu, et c’est elle qui aurait aussi détecté la 2.1.312 altérée, qui portait un vrai numéro de version.

1. Cette version existe-t-elle à la source ? La version 2.1.313 n’a jamais été publiée sur aucun des canaux officiels d’Anthropic. Un store qui distribue une copie de l’extension de quelqu’un d’autre peut refuser toute version que l’éditeur n’a jamais livrée. Cela détecte la 2.1.313, mais pas une copie altérée de la 2.1.312, une version qui existe bel et bien.

2. Le paquet est-il cohérent avec lui-même ? Le bundle « 2.1.313 » indiquait toujours version:”2.1.312” en interne. Seul le manifeste reconditionné portait le numéro supérieur, et cela suffisait pour que les éditeurs de code le traitent comme une mise à jour. Une incohérence entre le manifeste et le code qu’il contient est peu coûteuse à détecter et constitue un signe fort de reconditionnement. Là encore, cela n’aide que si l’attaquant augmente le numéro de version.

3. Est-ce bien l’artefact réel de l’éditeur ? C’est la vérification qui couvre les deux versions. La 2.1.312 altérée ne différait de la vraie 2.1.312 d’Anthropic que par un seul bloc en tête d’un fichier, qui lançait ssh, écrivait dans authorized_keys et créait des éléments de démarrage. Comparer le hash de chaque paquet à celui de la release de l’éditeur, et comparer chaque mise à jour à la version précédente pour repérer une nouvelle exécution de processus, des tunnels réseau ou de la persistance, revient à regarder ce qu’est le paquet plutôt que son nom.

Les signatures de l’éditeur sont le moyen le plus propre d’effectuer cette troisième vérification, mais seulement si la signature provient de l’éditeur. Si un store re-signe ou réhéberge lui-même un paquet, une signature valide prouve seulement que c’est le store qui l’a distribué.

Deux chronologies concurrentes

L’attaquant n’a eu besoin que de quelques minutes : la mise à jour automatique a livré le loader, qui s’est exécuté au chargement. Les défenseurs ont eu besoin d’environ 11 heures pour retirer les versions, et chaque développeur touché doit encore supprimer la persistance, renouveler chaque identifiant depuis une machine saine et décider s’il faut réinstaller. La mise à jour automatique maintient la plupart des développeurs à jour, donc la désactiver n’est pas la solution. Vérifier ce qu’elle installe, si.

Les quatre priorités

Pour les équipes sécurité : Sachez quels éditeurs de code vos développeurs utilisent et depuis quelle marketplace chacun se fournit. Sur les machines qui ont accès à la production, mettez les extensions sur liste d’autorisation ou épinglez-les, et traitez ces ordinateurs portables comme des appareils ayant accès à la production, avec la surveillance qui va avec. Gardez prêt un playbook d’incident pour les extensions : rechercher la persistance, renouveler les secrets depuis une machine saine, réinstaller en cas de doute.
Pour les opérateurs de marketplace : Vérifiez le contenu de chaque paquet par rapport à la release de l’éditeur avant de le distribuer, pas seulement son numéro de version. Rejetez les versions que l’éditeur n’a jamais livrées et les incohérences de manifeste, et examinez les mises à jour qui ajoutent de nouvelles capacités. Protégez l’accès de publication comme une clé de déploiement en production.
Pour les éditeurs d’extensions : Publiez une liste claire des canaux de distribution officiels, avec des hashs ou des signatures que les stores et les utilisateurs peuvent vérifier. Quand une copie altérée apparaît, indiquez rapidement et clairement où se trouve la vraie, comme l’a fait Anthropic ici.
Pour les développeurs : Après tout incident lié à une extension, comparez les versions installées avec les notes de version ou le journal des modifications de l’éditeur, et vérifiez la marketplace depuis laquelle vous avez réellement installé l’extension. Si votre version n’est pas listée par l’éditeur, considérez la machine comme touchée.

La tension au cœur du problème

Presque tout le code exécuté sur ces machines était celui d’Anthropic. Chaque signal auquel on apprend aux développeurs à se fier, le nom, le store, l’invite de mise à jour familière, allait dans le bon sens.

Tant que les stores ne pourront pas montrer que ce qu’ils distribuent est ce que l’éditeur a réellement publié, « ça vient de la marketplace officielle » décrit d’où vient un paquet. Cela ne vous dit pas ce qu’il est.

🎣Section 03 : Est-ce du phishing ?

Légitime ou phishing ?

🔬Section 04 : Recherche technique

Il mesurait la vitesse des pages. Puis il a vendu vos positions.

Le 29 octobre, le script de mesure des performances que Polymarket chargeait depuis son fournisseur, DebugBear, a été remplacé. Le nouveau fichier ne volait ni mots de passe ni clés. Il trouvait le client de trading déjà en cours d’exécution dans le navigateur de chaque trader connecté et s’en servait pour vider son compte.

Des chercheurs ont récupéré le script, et il s’agissait de JavaScript simple, non obfusqué. Il est donc exceptionnellement facile de voir comment il fonctionnait. Cette analyse s’appuie sur les travaux de ohey.ca, Report URI et Dancho Danchev.

Les faits

Les pages de Polymarket chargeaient le script Real User Monitoring (RUM) de DebugBear depuis cdn.debugbear[.]com sans contrôle d’intégrité. Vers 16 h 54 UTC, le serveur qui répondait pour cette URL a changé : les en-têtes de réponse sont passés de ceux de Google Cloud Storage à des en-têtes de type nginx, et le fichier est devenu un wallet drainer. DebugBear a ensuite indiqué que des attaquants avaient compromis ses enregistrements DNS. Polymarket a retiré le script dans un build à 17 h 59 UTC et est passé en mode annulation seule quelques minutes plus tard.

BleepingComputer a retracé environ 2,57 millions de dollars jusqu’au wallet de l’attaquant, et GoPlus Security a compté environ 700 wallets de dépôt touchés. Polymarket a déclaré que « l’un de nos prestataires tiers a été compromis » et qu’il rembourse intégralement les traders touchés.

Comment fonctionnait le drainer

1. Trouver un trader connecté. Le script lisait trois clés que l’application de Polymarket écrit elle-même dans localStorage : polymarket.auth.params (type de connexion et wallet), polymarket.auth.proxyWallet (wallet de dépôt) et poly_clob_api_key_map (identifiants de l’API de trading). Pas de session, pas d’attaque. Il appelait aussi l’endpoint /api/geoblock de Polymarket et ignorait les visiteurs qui n’avaient pas le droit de trader.

2. Emprunter le client de trading de la page. Le script ne contenait aucune clé. Il parcourait plutôt l’arbre interne des composants React, via les propriétés __reactFiber$ que React attache aux éléments du DOM, à la recherche d’un objet doté d’une méthode postOrder et d’une méthode createOrder ou createMarketOrder. Cet objet était le client d’ordres actif de Polymarket, avec le signataire de l’utilisateur. En simplifiant, la recherche ressemblait à ceci :

// Simplified illustration of the technique, not the attacker's exact code
for (const el of document.querySelectorAll("*")) {
  const key = Object.keys(el).find(k => k.startsWith("__reactFiber$"));
  // walk el[key] and its parents, return the first object that has
  // postOrder() and createOrder(), plus a signer
}

Si le client n’était pas encore là, il réessayait 15 fois, à 250 ms d’intervalle, puis rechargeait la page pour forcer l’application à en créer un.

3. Charger sa configuration. Il demandait ses instructions à data.debugbear[.]com/metrics/init. Cet endpoint renvoyait une erreur 404 pendant l’attaque, donc ce sont les valeurs par défaut codées en dur qui se sont appliquées :

return{recipient:N,minimalPerPosition:10,minimalToProcess:10,priorityToken:"POL"}

N est l’adresse Polygon de l’attaquant, 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18. Les comptes valant moins de 10 dollars étaient épargnés.

4. Signaler d’abord le compte. Avant de déplacer quoi que ce soit, il envoyait la valeur du portefeuille, le solde en espèces et chaque position à /metrics/submit, avec les wallets, le type de connexion, l’OS, l’IP et le pays.

5. Le vider, de deux façons. Pour les utilisateurs de wallets de navigateur, il construisait un seul batch EIP-712 qui transférait toutes les positions de plus de 10 dollars à l’attaquant en un seul appel safeBatchTransferFrom, et le soumettait via le propre relayer de Polymarket. Ce batch apparaissait comme une demande de signature dans le wallet, donc ces utilisateurs devaient l’approuver. Les comptes connectés par e-mail suivaient un autre chemin, sans invite du wallet : il vendait les positions avec des ordres fill-and-kill à 97 % du prix, puis à 50 %, puis au tick minimum, et raflait les liquidités.

6. Encaisser. Il convertissait les liquidités en POL via fun.xyz, en utilisant la clé d’API du propre frontend de Polymarket, avec l’attaquant comme destinataire. Chaque transfert était signalé à /metrics/update ou /metrics/handle avec son hash de transaction.

Là où la frontière a cédé

Chaque étape utilisait quelque chose que la page de Polymarket possédait légitimement : ses clés de stockage, son client d’ordres, son relayer, la clé d’API de son prestataire d’échange. Un script tiers s’exécute avec tous les privilèges de la page qui le charge, donc le script de monitoring et l’interface de trading étaient en pratique le même programme.

La Content Security Policy de Polymarket n’a servi à rien, car chaque hôte utilisé par le drainer était déjà autorisé. script-src-elem autorisait cdn.debugbear[.]com, et connect-src autorisait data.debugbear[.]com, *.polymarket.com, *.alchemy.com et *.fun.xyz. Comme l’a résumé Report URI, « rien n’allait être bloqué de toute façon ».

La page faisait confiance à une URL, pas à un fichier. L’URL n’a jamais changé, donc rien n’a eu à changer du côté de Polymarket pour que l’attaque fonctionne.

La chaîne d’attaque étape par étape

[DebugBear URL now serves drainer] -> [polymarket.com loads it, no SRI]
   -> [Reads localStorage: login, wallet, CLOB keys] -> [Finds React order client + signer]
   -> [Reports portfolio to /metrics/submit] -> [Sells or batch-transfers positions]
   -> [Swaps cash to POL via fun.xyz] -> [Attacker wallet]

Ce que les défenseurs doivent en retenir

Épinglez les scripts tiers avec Subresource Integrity : Le fichier altéré avait un hash différent de celui du fichier sain (0525f046…). Un attribut integrity sur la balise script aurait conduit le navigateur à refuser de l’exécuter. Si le script d’un fournisseur change trop souvent pour être épinglé, hébergez vous-même une copie vérifiée.
Ne confondez pas une liste d’autorisation CSP avec l’intégrité : CSP contrôle d’où le code est chargé, pas ce qu’est ce code. Ajoutez des contrôles basés sur les hashs et un endpoint de signalement, pour qu’un script modifié déclenche une alerte même quand son hôte est autorisé.
Gardez les scripts de monitoring hors des pages qui peuvent déplacer de l’argent : Le RUM et l’analytics ont rarement besoin de s’exécuter là où un utilisateur peut trader ou retirer des fonds. Chargez-les sur les pages marketing, ou dans une iframe sandboxée qui ne peut pas accéder à l’état de l’application.
Exigez une nouvelle action de l’utilisateur pour les opérations à forte valeur : Tout vendre ou déplacer des fonds devrait exiger une confirmation donnée activement par l’utilisateur, idéalement avec un authentificateur résistant au phishing comme une passkey ou une clé de sécurité matérielle, pour que du code déjà présent dans la page ne puisse pas le faire en silence.
Alertez sur les comportements impossibles : Des centaines de comptes liquidés en quelques minutes, c’est un signal. Prévoyez un moyen de suspendre rapidement les actions à forte valeur, comme Polymarket l’a fait avec le mode annulation seule.

🛠️Section 05 : Outil de la semaine

Pouvez-vous rechercher la même porte dérobée sur chaque ordinateur portable de développeur en quelques minutes ?

Quand un incident comme celui de l’extension Cursor survient, la question n’est pas seulement « l’avons-nous installée ? ». C’est « est-ce que quelque chose de ce qu’elle a laissé derrière elle a survécu ? » osquery répond à ce type de question sur de nombreuses machines à la fois.

osquery est un outil open source, créé à l’origine chez Facebook et désormais hébergé par la Linux Foundation, qui expose le système d’exploitation sous forme d’un ensemble de tables de base de données. Au lieu d’écrire un script différent pour chaque OS, vous posez vos questions en SQL : quelles clés SSH sont autorisées, quels LaunchAgents et tâches planifiées existent, quels processus tournent et à quoi ils se connectent.

# Quickstart (macOS)
brew install --cask osquery
osqueryi

-- macOS: look for the LaunchAgent named in the Cursor incident
SELECT label, path, program_arguments FROM launchd WHERE label = 'com.apple.sysmond';

-- Windows: look for the SysMon scheduled task and the Startup folder fallback
SELECT name, action, path, enabled FROM scheduled_tasks WHERE name LIKE '%SysMon%';
SELECT name, path FROM startup_items WHERE name LIKE '%sysmon%';

-- macOS and Linux: list authorized SSH keys for every local user, and look for svc-telemetry
SELECT u.username, k.key_file, k.comment
FROM users u JOIN authorized_keys k USING (uid);

-- Windows: no authorized_keys table, so find the key files and open them
SELECT path, mtime FROM file
WHERE path LIKE 'C:\Users\%\.ssh\authorized_keys'
   OR path = 'C:\ProgramData\ssh\administrators_authorized_keys';

La table authorized_keys n’existe pas sous Windows. Là, la requête ci-dessus ne trouve que les fichiers de clés, donc vérifiez chacun d’eux pour y chercher la clé svc-telemetry, ou récupérez-les depuis votre inventaire de gestion de configuration.

Sachez ce qu’il ne vous dira pas. osquery vous montre ce qui se trouve sur une machine à l’instant présent. Il ne vous dira pas ce qu’un attaquant a déjà fait avec un identifiant volé, et un résultat propre après le nettoyage ne signifie pas que rien n’a été pris. Utilisez-le pour trouver rapidement les machines touchées, puis poursuivez avec le renouvellement des identifiants et, là où le tunnel s’est connecté, une réinstallation.

👏Section 06 : Personnalité de la semaine

Paul McCarty

Cette semaine, nous mettons à l’honneur Paul McCarty, fondateur d’OpenSourceMalware, une base de données ouverte et communautaire de paquets malveillants trouvés dans des registres comme npm, PyPI, RubyGems et Open VSX.

Quand un paquet ou une extension devient malveillant, les défenseurs doivent le savoir vite : quelles versions, quels indicateurs, et si le même attaquant a déjà fait la même chose. OpenSourceMalware met ce renseignement sur les menaces en accès libre, pour que chacun puisse vérifier un paquet suspect au lieu d’attendre le rapport d’un éditeur.

Son travail apparaît dans les actualités de ce numéro. Après la compromission de l’OVHcloud CLI, McCarty a relié l’attaque à la campagne GlassWorm grâce à une adresse de wallet Solana utilisée dans de précédentes opérations GlassWorm, et a découvert que le compte de développeur utilisé pour remplacer les versions était compromis depuis sept mois.

Pour son suivi public des paquets malveillants, là où chaque défenseur peut exploiter les résultats, Paul McCarty est notre Personnalité de la semaine. 👏

📅Section 07 : Événement de la semaine

Open Source SecurityCon 2026

Open Source SecurityCon est un événement d’une journée coorganisé par la Cloud Native Computing Foundation et l’Open Source Security Foundation (OpenSSF), qui se tient en marge de KubeCon + CloudNativeCon North America.

Ses parcours couvrent la sécurité de la chaîne d’approvisionnement, le développement logiciel sécurisé, l’identité et les accès, l’architecture et les politiques, ainsi que les politiques publiques de l’open source. L’OpenSSF et la CNCF hébergent une grande partie des outils qui permettent de vérifier ce que vous installez, notamment TUF, in-toto et Sigstore : c’est donc là que ceux qui construisent la signature des paquets et la vérification des builds échangent leurs expériences.

📍 Salt Lake City, Utah (Salt Palace Convention Center) 📅 9 novembre 2026

📚Section 08 : Livre de la semaine

Tout ce que vous n’avez pas écrit, mais que vous livrez quand même

Software Supply Chain Security: Securing the End-to-End Supply Chain for Software, Firmware, and Hardware de Cassie Crossley traite du code, des composants et des services dont une organisation dépend sans les développer elle-même.

Crossley parcourt toute la chaîne, des composants et outils dont vous dépendez à la façon dont un logiciel est construit, signé, distribué et mis à jour, et montre où les attaquants peuvent intervenir en cours de route. Le livre aborde des contrôles concrets comme les nomenclatures logicielles (SBOM), l’intégrité des builds et le risque fournisseur, et il s’adresse à ceux qui doivent mettre ces contrôles en place, pas seulement en parler.

Pour cartographier le code que vous livrez sans l’avoir écrit, Software Supply Chain Security est un bon point de départ.

😅Section 09 : Le mème

Si l’un des scripts de vos fournisseurs ou l’une des extensions de vos développeurs avait changé ce matin, comment le sauriez-vous ?

C’est tout pour ce numéro. Vérifiez vos extensions, listez vos scripts tiers, et à bientôt pour le prochain numéro.

The Breach Brief, L’équipe Ostorlab