Attaque sur openapi-react-query-codegen (28 août 2026) : votre SaaS, ERP ou projet IA est‑il exposé ?

Contexte rapide — le 28 août 2026, des versions malveillantes du package npm @7nohe/openapi-react-query-codegen ont été publiées et distribuées via une chaîne d'approvisionnement compromise. Le paquet, utilisé pour générer automatiquement des clients TypeScript et des hooks React Query à partir de spécifications OpenAPI, est largement adopté par des équipes produit et dev. Plusieurs équipes de recherche ont confirmé la compromission et décrit un payload visant à voler des identifiants cloud/CI et à se propager. Socket (analyse). ([socket.dev](https://socket.dev/blog/openapi-react-query-codegen-npm-compromise?utm_source=openai))

Qu’est‑ce qui s’est passé (en une phrase)

Le 28 août 2026, dix versions malveillantes du package npm @7nohe/openapi-react-query-codegen ont été publiées après qu’un workflow de publication GitHub ait été abusé ; ces versions exécutent du code pendant l’installation pour collecter des secrets et tenter de se propager dans d’autres registres et projets. Endor Labs (synthèse). ([endorlabs.com](https://www.endorlabs.com/learn/trojanized-7nohe-openapi-react-query-codegen-adds-pypi-to-a-self-replicating-npm-worm?utm_source=openai))

Pourquoi ça compte pour vous (synthèse pour dirigeants)

• Surface d’impact directe : toute équipe qui a des workflows de build/install côté développeur ou CI qui installent des dépendances npm (apps web, backends Node, projets SSR) peut être exposée.
• Risques indirects : vol de tokens cloud/GitHub/CI, réutilisation de ces accès pour compromettre environnements de production, pipelines CI/CD, ou republier des paquets malveillants vers d’autres registres (PyPI, RubyGems).
• Impact business : fuite de données clients, interruption de service, coût d’investigation et de remédiation, risque de mise en conformité et réputation.

À quels piliers Novane cela touche

• Web / SaaS — dépendances front et back intégrées dans builds et conteneurs.
• Logiciels métiers / ERP‑CRM — éditeurs et intégrateurs qui génèrent des clients API ou automatisent des builds peuvent propager l’impact en entreprise.
• IA / agents — outils de dev et pipelines ML/IA qui installent packages peuvent voir leurs clés d’accès ou modèles compromis et exfiltrés. ([endorlabs.com](https://www.endorlabs.com/learn/trojanized-7nohe-openapi-react-query-codegen-adds-pypi-to-a-self-replicating-npm-worm?utm_source=openai))

Détails pratiques (ce que disent les chercheurs)

Les analyses montrent que la publication malveillante n'était pas forcément le résultat d’un vol direct de credentials npm : l’attaquant a abusé d’un workflow GitHub déclenché par un commentaire (issue_comment) qui exécutait le code d’un fork non‑vérifié, permettant de publier sous l’identité du projet et de produire des attestations de provenance apparemment valides. Le payload utilise des hooks d’installation pour exécuter du code au moment de l’install (preinstall) et cible des secrets en mémoire et des tokens CI. Socket, analyses tierces. ([socket.dev](https://socket.dev/blog/openapi-react-query-codegen-npm-compromise?utm_source=openai))

Risques concrets pour un dirigeant (priorisés)

1. Exfiltration de credentials — tokens cloud/GitHub/Vault permettant mouvement latéral vers production.
2. Compromission de la chaîne de déploiement — CI/CD ou images conteneur corrompues embarquent la backdoor.
3. Propagation silencieuse — le malware peut republier dans d’autres registres, touchant des équipes non liées.
4. Conformité et réputation — obligations de notification, perte de confiance clients/partenaires.

Que décider maintenant (plan décisionnel pour CEO/CTO/CPO)

Voici une feuille de route courte, hiérarchisée par impact et rapidité d’exécution.

Immédiat (24–72 heures)

• Demander au CTO/lead dev un état des lieux : lister les dépôts et pipelines qui installent @7nohe/openapi-react-query-codegen ou utilisent des builds automatisés qui installent des dépendances npm durant CI.
• Bloquer temporairement les versions affectées via votre solution de gestion des dépendances (allowlist/blocklist) et pinning vers versions connues saines. Communiquer la démarche aux équipes produit. Socket. ([socket.dev](https://socket.dev/blog/openapi-react-query-codegen-npm-compromise?utm_source=openai))
• Inspecter les logs CI pour signes d’exfiltration : échanges OIDC, requêtes réseau suspectes pendant les étapes d’installation.

Courte terme (1–2 semaines)

• Auditer les tokens/credentials utilisés dans CI : révoquer et rotater les tokens exposés (GitHub Actions, cloud providers, Vault), surtout si des builds l’ont installés récemment.
• Déployer règles de durcissement GitHub Actions : désactiver triggers non vérifiés (issue_comment publishing), exiger vérification d’auteur/maintainer pour les workflows de publication.
• Mettre en place ou renforcer un scanner interne des dépendances et des IOCs connus ; partager feeds de menaces liés à Mini Shai‑Hulud. ([endorlabs.com](https://www.endorlabs.com/learn/trojanized-7nohe-openapi-react-query-codegen-adds-pypi-to-a-self-replicating-npm-worm?utm_source=openai))

Moyen terme (1–3 mois)

• Introduire trusted publishing et provenance stricte (OIDC limité, attestation) dans vos pipelines : limiter les permissions et auditer les objets signés.
• Standardiser le pinning des dépendances critiques, caching interne, et utiliser des miroirs contrôlés pour les builds de production.
• Former les équipes dev/DevOps au risque supply‑chain (workflows GitHub, hooks d’installation, CI secrets in memory). Des guides officiels existent pour durcir la supply chain. NCSC - guidance. ([ncsc.gov.uk](https://www.ncsc.gov.uk/sites/default/files/2026-06/Software-supply-chain-attacks-check-your-dependencies.pdf?utm_source=openai))

Checklist rapide à transmettre à vos équipes techniques

• Identifier tout usage de @7nohe/openapi-react-query-codegen dans repos et pipelines.
• Pin/rollback aux versions saines connues ou supprimer usage temporairement.
• Révoquer et régénérer tokens CI/GitHub/Cloud si un build suspect a eu lieu.
• Activer alerting sur nouvelles publications de paquets critiques et intégrer feed d’IOCs.
• Vérifier workflows GitHub : désactiver publications depuis triggers non autorisés.

Coût et arbitrages

La décision la plus coûteuse à court terme est généralement la rotation complète des clés et la revue exhaustive des artefacts de build. Pourtant, laisser des tokens exposés entraîne un coût potentiel beaucoup plus élevé (incident, rançon, interruption). Priorisez la rotation sur les identifiants les plus sensibles (prod, deploy, vault) et les actions bloquantes au niveau CI.

Pourquoi ne pas tout couper immédiatement

Un arrêt total des builds freine le produit. La meilleure pratique est une réponse ciblée : bloquer les versions affectées, activer contrôles compensatoires, puis procéder à une rotation critique coordonnée.

Conclusion

La compromission du package @7nohe/openapi-react-query-codegen le 28 août 2026 illustre que la menace supply‑chain est devenue opérationnelle et systémique : un incident sur un petit composant peut mettre en péril tout un SaaS, un backoffice ERP, ou des pipelines IA. Agissez vite sur l’identification, le blocage et la rotation des secrets, durcissez les workflows de publication, puis planifiez des mesures de long terme pour limiter la dépendance aux registres publics. Analyse Socket, Endor Labs, et les recommandations du NCSC sont de bons points de départ. ([socket.dev](https://socket.dev/blog/openapi-react-query-codegen-npm-compromise?utm_source=openai))

Besoin d’aide pour un audit rapide, durcir vos pipelines ou chiffrer l’impact ? Obtenez un audit ou un devis avec notre équipe Novane : services SaaS, ERP/CRM, intégration IA — ou obtenir un devis.

Mini FAQ

• Mon application utilise‑t‑elle forcément le package compromise ? Si votre pipeline installait automatiquement des dépendances npm pendant le build ou que vos devs ont exécuté un npm install récemment sur des branches contenant des générations OpenAPI, il faut vérifier. Commencez par une recherche dans le code et les logs CI.
• Faut‑il révoquer toutes les clés cloud ? Priorisez : révoquez d’abord les clés liées à CI, déploiement, Vault et les accès production si un build suspect a eu lieu. Étendez si des signes d’accès non autorisé apparaissent.
• Que faire si j’utilise un mirror privé ou un proxy de registre ? Vérifiez que le mirror n’a pas pullé les versions affectées ; configurez des politiques de verrouillage et de validation des signatures pour les packages critiques.
• Combien de temps la remédiation prend‑elle ? Détection et blocage peuvent se faire en 24–72 heures ; rotation de secrets et audits complets prennent généralement plusieurs jours à semaines selon la taille de l’organisation.
• Comment prévenir à long terme ? Limiter les permissions OIDC, durcir workflows GitHub, pinning de dépendances, miroirs internes, et scanner les packages avec feeds d’IOCs. Consultez la guidance officielle. ([ncsc.gov.uk](https://www.ncsc.gov.uk/sites/default/files/2026-06/Software-supply-chain-attacks-check-your-dependencies.pdf?utm_source=openai))