Un attaquant a accédé aux variables d'environnement de clients de l'outil pour développeurs Trigger.dev

Le 1er novembre, un dimanche, Eric Allam, directeur technique de Trigger.dev, publie un court message sur le blog de l'entreprise. Il y écrit qu'un attaquant a obtenu un accès non autorisé aux variables d'environnement d'une partie des organisations clientes. Trigger.dev permet aux développeurs de faire tourner en arrière-plan les tâches longues de leurs applications. Ces variables d'environnement contiennent souvent les secrets les plus sensibles d'un projet : clés d'API, mots de passe de bases de données, jetons d'accès au cloud.

Selon l'entreprise, la faille utilisée a été bloquée. Les propriétaires des comptes touchés ont reçu un e-mail détaillant les mesures à prendre. L'annonce s'arrête là : elle ne dit ni comment l'attaquant est entré, ni combien d'organisations sont concernées, ni depuis quand.

Au moins neuf plateformes de développeurs déjà touchées en octobre

L'histoire a un air de déjà-vu. Fin octobre, l'hébergeur Railway avait prévenu que les clés d'API de ses clients avaient pu être lues. Peu après, des pirates utilisaient des clés d'IA confiées par des développeurs à un autre hébergeur, Northflank. Le scénario est chaque fois le même : plutôt que d'attaquer les entreprises une par une, les attaquants visent la plateforme où elles stockent leurs secrets. La société de sécurité Wiz recense au moins neuf plateformes de développeurs touchées en octobre, mais n'a trouvé aucune faille commune reliant ces attaques.

Que faire si vous utilisez Trigger.dev ?

Le message de l'entreprise ne liste aucune mesure publique. Si vous n'avez pas reçu d'e-mail, cela devrait signifier que votre organisation ne fait pas partie de celles exposées. La prudence reste de mise tant que la faille n'est pas expliquée.

• Cherchez l'e-mail de Trigger.dev dans la boîte du propriétaire du compte, spams compris, et suivez ses consignes.
• Renouvelez les secrets stockés dans vos variables d'environnement en commençant par les plus puissants : clés d'IA, clés du cloud, accès aux bases de données. Révoquez ensuite les anciens.
• Surveillez la consommation de vos services d'IA et de cloud : une facture qui s'emballe est souvent le premier signe d'une clé volée.
• Suivez la page d'état de Trigger.dev, où l'entreprise promet de publier ses mises à jour.

Pour l'instant, Trigger.dev n'a donné ni le nombre d'organisations touchées ni le mode d'intrusion. C'est pourtant ce qui permettra à ses clients de mesurer leur risque réel.

Mise à jour du 14 novembre 2026

Le 6 novembre, Trigger.dev, la plateforme qui exécute les tâches de fond des applications, a publié son rapport sur l'incident du 1er novembre. Selon l'entreprise, 0,66 % de ses clients sont touchés. L'attaquant a obtenu les clés d'API « racines » de certains environnements clients. Ces clés donnent un accès complet aux réglages, y compris aux variables d'environnement. Dans certains environnements, il a aussi consulté la liste des exécutions, des déploiements et des tâches planifiées : identifiants, noms de tâches, métadonnées, erreurs de déploiement.

Le mode d'intrusion reste secret. Trigger.dev dit ne pas pouvoir le décrire pour l'instant, afin de protéger l'enquête, et promet de le faire plus tard. Elle n'a trouvé aucun signe d'accès à d'autres données, à ses bases de production ou aux comptes des clients. Elle ne dit pas si les secrets exposés ont servi. L'entreprise a révoqué les clés d'API des clients touchés, fait appel à des spécialistes de la réponse aux incidents et prévenu les forces de l'ordre. Les installations auto-hébergées ne sont pas concernées.

Les clients touchés doivent régénérer leurs clés Trigger.dev. Ils doivent aussi renouveler puis révoquer tous les identifiants stockés dans les environnements concernés, à considérer « comme compromis ». Les secrets de signature des webhooks n'ont pas été exposés.