Plusieurs entreprises de cybersécurité, dont **Aikido Security**, **Onapsis**, **OX Security**, **SafeDep**, **Socket**, **StepSecurity** et **Wiz** (détenue par **Google**), ont signalé une nouvelle campagne d'attaque de la chaîne d'approvisionnement ciblant les packages npm liés à **SAP** avec un malware de vol d'identifiants. ### Packages affectés La campagne 'Mini Shai-Hulud' a compromis les packages suivants associés à l'écosystème de développement d'applications JavaScript et cloud de **SAP** : * [email protected] * @cap-js/[email protected] * @cap-js/[email protected] * @cap-js/[email protected] **Socket** a déclaré : "Les versions affectées ont introduit un nouveau comportement à l'installation qui ne faisait pas partie de la fonctionnalité attendue de ces packages auparavant. Les versions compromises ont ajouté un script preinstall qui agit comme un amorceur d'exécution, téléchargeant un Bun ZIP spécifique à la plateforme depuis GitHub Releases, l'extrayant et exécutant immédiatement le binaire Bun extrait." L'implémentation suit également les redirections HTTP sans valider la destination et utilise **PowerShell** avec `-ExecutionPolicy Bypass` sur **Windows**, augmentant le risque pour les environnements de développement et CI/CD affectés. ### Attribution et tactiques **Wiz** a noté que les packages malveillants partagent des caractéristiques avec les opérations précédentes de **TeamPCP**, suggérant que le même acteur de menace est à l'origine de la campagne. Les versions suspectes ont été publiées le 29 avril 2026, entre 09h55 UTC et 12h14 UTC. Les packages empoisonnés introduisent un nouveau hook preinstall `package.json` qui exécute `setup.mjs`, agissant comme un chargeur pour le runtime JavaScript Bun afin d'exécuter le voleur d'identifiants et le framework de propagation (`execution.js`). Selon **Aikido**, le malware récolte les identifiants locaux des développeurs, les tokens **GitHub** et npm, les secrets **GitHub** Actions, et les secrets cloud d'**AWS**, **Azure**, **GCP**, et **Kubernetes**. Les données volées sont chiffrées et exfiltrées vers des dépôts **GitHub** publics créés sur le compte de la victime, intitulés "A Mini Shai-Hulud has Appeared." Plus de 1 100 dépôts de ce type ont été identifiés.  La charge utile de 11,6 Mo s'auto-propague via les flux de travail des développeurs et de publication, utilisant les tokens **GitHub** et npm pour injecter un workflow **GitHub** Actions malveillant dans les dépôts victimes, volant les secrets du dépôt et publiant des versions de packages npm empoisonnées. ### Différences clés par rapport aux vagues précédentes de Shai-Hulud * Toutes les données exfiltrées sont chiffrées avec AES-256-GCM, encapsulant la clé à l'aide de RSA-4096 avec une clé publique intégrée dans la charge utile. * Il se désactive sur les systèmes avec une locale russe. * La charge utile s'inscrit dans tous les dépôts **GitHub** accessibles en injectant un fichier `.claude/settings.json` qui abuse du hook SessionStart de **Claude Code** et un fichier `.vscode/tasks.json` avec le paramètre `"runOn": "folderOpen"`, garantissant l'exécution à l'ouverture dans **Microsoft Visual Studio Code (VS Code)** ou **Claude Code**. **StepSecurity** a noté : "C'est l'une des premières attaques de la chaîne d'approvisionnement à cibler les configurations d'agents de codage IA comme vecteur de persistance et de propagation." **Wiz** a également souligné la vérification de la locale russe, précédemment observée dans les compromissions de **Checkmarx** et **Bitwarden**, ajoutant que l'attaque utilise une clé publique RSA partagée liée à **TeamPCP** pour chiffrer les secrets exfiltrés. Les chercheurs de **Wiz** ont souligné : "L'opération **SAP** ajoute la capacité de voler les identifiants de plusieurs navigateurs (**Chrome**, **Safari**, **Edge**, **Brave**, **Chromium**) et d'exfiltrer tous les mots de passe trouvés. Cette fonctionnalité n'était présente dans aucune des opérations précédentes. L'exfiltration basée sur GitHub vers des dépôts à thème Dune était la méthode C2 de secours pour l'opération CLI **Bitwarden**, mais est maintenant l'option principale." ### Analyse de la cause racine L'analyse révèle que les attaquants ont compromis le compte de **RoshniNaveenaS** pour les trois packages `@cap-js`, poussant un workflow modifié vers une branche non principale et utilisant le token OIDC npm extrait pour publier des packages malveillants sans provenance. Pour mbt, la compromission du token npm statique `cloudmtabot` est suspectée. **SafeDep** a déclaré : "L'équipe cds-dbs a migré vers la publication de confiance OIDC npm en novembre 2025. Dans cette configuration, GitHub Actions peut demander un token npm à courte durée de vie sans stocker de secrets à longue durée de vie dans le dépôt. L'attaquant a reproduit cet échange manuellement dans une étape CI et a imprimé le token résultant." Ils ont ajouté : "La faille de configuration critique : la configuration du publisher de confiance OIDC de npm pour @cap-js/sqlite faisait confiance à n'importe quel workflow dans cap-js/cds-dbs, pas seulement au workflow canonical release-please.yml sur la branche principale. Une poussée de branche pouvait échanger un token OIDC au nom du package si le workflow avait la permission id-token: write et la référence d'environnement : npm." ### Remédiation Les mainteneurs des packages ont publié de nouvelles versions sûres qui remplacent les versions compromises : * sqlite : [v2.4.0](https://github.com/cap-js/cds-dbs/releases/tag/sqlite-v2.4.0), [v2.3.0](https://github.com/cap-js/cds-dbs/releases/tag/sqlite-v2.3.0) * postgres : [v2.3.0](https://github.com/cap-js/cds-dbs/releases/tag/postgres-v2.3.0), [v2.2.2](https://github.com/cap-js/cds-dbs/releases/tag/postgres-v2.2.2) * hana : [v2.8.0](https://github.com/cap-js/cds-dbs/releases/tag/hana-v2.8.0), [v2.7.2](https://github.com/cap-js/cds-dbs/releases/tag/hana-v2.7.2) * db-service : [v2.10.1](https://github.com/cap-js/cds-dbs/releases/tag/db-service-v2.10.1) * mbt : [v1.2.49](https://github.com/SAP/cloud-mta-build-tool/releases/tag/v1.2.49) Les chercheurs de **OX Security**, Moshe Siman Tov Bustan et Nir Zadok, ont conclu : "Cette campagne illustre une fois de plus comment GitHub devient l'infrastructure C2 de choix pour l'exfiltration de données. Bloquer github.com n'est pas une option réaliste pour la plupart des équipes de développement, et retracer l'exfiltration vers un acteur de menace spécifique devient presque impossible lorsque GitHub est le mécanisme de livraison."