Le groupe d’extorsion FulcrumSec a transformé un jeton GitHub codé en dur en violation de 1,3 To chez Novo Nordisk

Comment la violation s’est produite

La méthode de FulcrumSec, que le groupe aurait lui-même surnommée le « Hardcoded Horrorshow », repose sur une classe de vulnérabilité que les équipes de sécurité signalent depuis des années comme à la fois hautement évitable et obstinément persistante : des identifiants intégrés directement dans du code livré aux utilisateurs finaux. Selon les informations sur l’incident, FulcrumSec a trouvé un jeton d’accès personnel pour l’environnement Azure DevOps de Novo Nordisk niché dans un bundle JavaScript sur l’un des sites publics de l’entreprise, aux côtés d’identifiants supplémentaires trouvés dans du code côté client sur un second site.

Ce jeton étant un jeton d’accès personnel GitHub valide, FulcrumSec a pu l’utiliser directement pour accéder à des centaines de dépôts privés de Novo Nordisk — pas de phishing, pas de déploiement de logiciel malveillant, pas d’exploitation d’une vulnérabilité logicielle au sens traditionnel. L’identifiant lui-même constituait toute la surface d’attaque. Le JavaScript côté client est, par définition, téléchargé et exécutable par quiconque visite la page, ce qui signifie que tout secret qui y est intégré devient effectivement public dès la mise en ligne de la page, que quelqu’un le remarque immédiatement ou non.

Ampleur et chronologie

FulcrumSec a commencé à faire pression sur Novo Nordisk en juin 2026 et, selon les informations sur les opérations du groupe, a passé environ deux mois à l’intérieur des réseaux de l’entreprise avant d’extraire les données. Le groupe a finalement récupéré environ 1,3 téraoctet de matériel, incluant de la recherche pharmaceutique, des informations d’essais cliniques et des modèles d’IA internes — le type de propriété intellectuelle dont la perte entraîne des conséquences bien au-delà d’une violation typique de données clients pour une entreprise pharmaceutique en plein développement de médicaments.

Lorsque Novo Nordisk a refusé une demande d’extorsion de 25 millions de dollars, FulcrumSec a publié plus d’un téraoctet des données volées et a commencé à explorer une vente privée des actifs restants, selon les mêmes sources. Le modèle économique du groupe — rançonner des données sensibles plutôt que chiffrer des systèmes — évite la perturbation opérationnelle que causent les rançongiciels traditionnels et mise entièrement sur la sensibilité de ce qui a été volé pour forcer le paiement.

Pourquoi cela continue de se produire

Les identifiants codés en dur figurent parmi les classes de vulnérabilité les plus constamment citées dans la recherche en sécurité d’entreprise, précisément parce que le mode d’échec est si simple : un développeur intègre un jeton, une clé ou un mot de passe directement dans le code source — souvent par commodité pendant les tests ou parce qu’un processus de build n’était pas configuré pour injecter les secrets à l’exécution — et cela finit soit en production, soit dans un dépôt public. Contrairement à une faille zero-day, il ne s’agit pas d’une technique d’attaque sophistiquée ; c’est plus proche de laisser une clé de rechange sous le paillasson avec un panneau qui la désigne.

Le cas Novo Nordisk est instructif car l’exposition se trouvait dans du code côté client accessible publiquement — l’emplacement le plus visible et le plus scannable qu’un secret puisse occuper. Des outils automatisés de détection de secrets existent précisément pour intercepter ce schéma avant qu’il n’atteigne la production, et le fait qu’un jeton donnant accès à des centaines de dépôts privés soit resté non détecté dans un bundle JavaScript public révèle une faille dans cette discipline de scan, et non l’échec d’une défense exotique quelconque.

Ce que les équipes de sécurité doivent en retenir

Les leçons pratiques ici ne sont pas glamour mais concrètes. D’abord, les secrets n’ont leur place en aucune circonstance dans du code côté client — les jetons d’accès, clés API et identifiants doivent être émis et utilisés côté serveur, le code côté client appelant à la place des points de terminaison backend authentifiés. Ensuite, la détection automatisée de secrets devrait s’exécuter en continu à la fois sur les dépôts source et sur les artefacts déployés et compilés (le bundle JavaScript réellement livré), car un scan du seul code source peut manquer des secrets introduits pendant une étape de build ou d’assemblage. Enfin, les jetons d’accès devraient avoir une portée aussi restreinte que possible et être renouvelés selon un calendrier, afin qu’un identifiant unique divulgué n’accorde pas un accès large et permanent à des centaines de dépôts comme cela s’est manifestement produit ici.

Le cas FulcrumSec-Novo Nordisk souligne aussi un point spécifique aux secteurs comme la pharmacie : la valeur de ce qui est volé lorsque des identifiants sont exposés n’est pas générique. Les données de pipeline de médicaments et les informations d’essais cliniques portent un poids concurrentiel et réglementaire qu’une base de données clients classique n’a pas, ce qui relève les enjeux d’une bonne hygiène des identifiants bien au-delà de ce que le budget de sécurité de base d’une entreprise pourrait autrement prioriser.

Questions Fréquemment Posées

Sources et lectures complémentaires

• Novo Nordisk hack: FulcrumSec claims $25M extortion attempt — Yahoo Finance
• Novo Nordisk Data Breach Tied to Stolen GitHub Access Tokens — BankInfoSecurity