Exploit d’une vulnérabilité de CodeRabbit : d’une simple PR à l’obtention d’un RCE et de droits d’écriture sur 1 million de dépôts

• Une équipe de recherche en sécurité est parvenue à exécuter du code à distance (RCE) sur les serveurs de production de CodeRabbit et à exfiltrer des jetons d’API et des secrets
• Via une PR exploitant Rubocop, il a été possible de dérober des variables d’environnement, avec à la clé un accès à PostgreSQL et des droits de lecture/écriture sur 1 million de dépôts
• La fuite de la clé privée de la GitHub App permettait d’injecter du code malveillant et de modifier le code source dans un très grand nombre de dépôts, publics comme privés
• CodeRabbit a réagi immédiatement dans les heures suivant le signalement et renforcé ses mesures de sécurité
• L’incident souligne la nécessité de prévenir ce type d’attaque via l’isolation en sandbox, le principe du moindre privilège et le blocage réseau lors de l’exécution d’outils externes

---

Introduction

• En janvier 2025, l’équipe de recherche de Kudelski Security a rendu publique une faille de sécurité critique affectant CodeRabbit
• CodeRabbit, largement utilisé pour l’automatisation des revues de PR, présentait des problèmes majeurs : remote code execution (RCE), fuite de variables d’environnement et d’informations sensibles, et obtention de droits de lecture/écriture sur plus d’un million de dépôts
• Cet article propose une analyse détaillée de la vulnérabilité présentée à Black Hat USA, et constitue un cas concret de faille dans un outil de revue de code et ses systèmes d’intégration
• La vulnérabilité signalée a été corrigée rapidement après son signalement

Présentation de CodeRabbit

• CodeRabbit est l’application de revue de code basée sur l’IA la plus installée sur les marketplaces GitHub et GitLab
• L’outil passe en revue 1 million de dépôts et 5 millions de pull requests sur ces deux plateformes
• À chaque création ou mise à jour de PR, le moteur IA analyse le code et génère automatiquement des commentaires et des suggestions
• Résumé de code, détection de failles de sécurité, propositions d’amélioration, génération de diagrammes : l’outil apporte un gain important en productivité de développement

Utilisation de CodeRabbit et structure des permissions

• L’offre Pro fournit des fonctions d’intégration avec des outils de linter et de SAST (analyse statique)
• Lors de l’authentification du compte GitHub et de l’installation de l’application, l’utilisateur accorde des droits de lecture/écriture sur les dépôts sélectionnés
• Si cette gestion des permissions est détournée, elle peut avoir un impact direct sur le code de tous les dépôts où l’application est installée

Exécution d’outils externes et découverte de l’exploit

• Lorsque CodeRabbit détecte des modifications de code dans une PR, il lance automatiquement plusieurs outils externes d’analyse statique (par exemple Rubocop)
• Rubocop utilise le fichier de configuration .rubocop.yml, qui permet de charger des extensions Ruby externes (ext.rb, etc.)
  • Un attaquant peut injecter du code malveillant dans .rubocop.yml et ext.rb, puis soumettre une PR afin d’amener CodeRabbit à exécuter ce code sur son serveur distant
• Le code ainsi exécuté transmettait toutes les variables d’environnement du serveur vers l’infrastructure de l’attaquant

Analyse du contenu des variables d’environnement exfiltrées

• Les variables d’environnement exfiltrées comprenaient notamment des clés d’API, jetons et mots de passe de nombreux services
  • Clés API Anthropic/OpenAI, salt/mot de passe de chiffrement, clé privée de la GitHub App, informations de connexion PostgreSQL, etc.
• Le RCE ouvrait la voie à des dommages secondaires importants et à fort effet de propagation, notamment l’accès à la base de données, la modification de code et la fuite d’informations internes
• Il aurait été possible de poursuivre l’exploration malveillante sur le serveur de production, mais les chercheurs se sont volontairement limités au strict minimum afin de ne pas perturber le service

Obtention de droits de lecture/écriture sur 1 million de dépôts

• La variable d’environnement GITHUB_APP_PEM_FILE (clé privée) permettait de s’authentifier auprès de l’API GitHub
• Sur l’ensemble des dépôts accessibles à CodeRabbit, publics comme privés, il devenait possible d’exercer des droits très étendus :
  • lecture/écriture du code source, remplacement de fichiers de release (attaque de la supply chain), modification de l’historique Git, etc.
• Un code de reproduction (PoC) a été publié, démontrant la faisabilité réelle de l’exploitation

Résumé du PoC

• À l’aide de bibliothèques comme PyGitHub, les chercheurs ont utilisé la clé privée exfiltrée, l’App ID et d’autres éléments pour émettre un jeton d’accès à n’importe quel dépôt
• Ce jeton permettait ensuite d’automatiser le clonage de dépôts privés, la modification de fichiers, la création de nouveaux commits et l’altération de fichiers de release

Possibilité de compromission des dépôts internes/privés de CodeRabbit

• L’organisation CodeRabbit elle-même utilisait aussi l’application pour son propre service, ce qui permettait également d’accéder aux dépôts internes de CodeRabbit et de les cloner
• Il suffisait de connaître le nom de l’organisation pour récupérer l’ID d’installation et accéder immédiatement à la liste des dépôts concernés

Résumé de l’impact

• Accès non autorisé à des dépôts privés et fuite de données personnelles
• Menace d’attaques de la supply chain via manipulation du code source, insertion de malware ou de backdoors
• Possibilité d’enchaîner avec d’autres failles, par exemple autour de GitHub Actions
• RCE direct pouvant entraîner destruction de données, indisponibilité du service et effets en cascade sur d’autres services

Contexte et limites du jugement de l’IA

• Pendant l’attaque, la PR elle-même a été revue normalement par CodeRabbit, qui a bien laissé un commentaire d’avertissement sur la vulnérabilité, sans pour autant identifier réellement la séquence menaçante
• Cela montre qu’un outil de revue de code par IA ne comprend pas nécessairement le contexte d’une situation de risque réelle

Réponse et recommandations

• CodeRabbit a désactivé Rubocop, remplacé les secrets et procédé à un audit du système dans les heures ayant suivi le signalement
• Le problème provenait d’un outil non isolé par sandbox (Rubocop) ; après correction, tous les outils externes ont été déplacés vers un environnement isolé
• Pour renforcer la sécurité, l’article insiste sur la nécessité d’une conception défensive : réduction des variables d’environnement exposées, restriction des IP autorisées pour l’accès réseau, blocage de l’accès Internet, etc.

Divulgation responsable et conclusion

• En janvier 2025, le signalement a été suivi d’une réponse et de mesures rapides
• L’exploitation est restée au stade du PoC, mais un attaquant malveillant aurait facilement pu s’en servir pour cibler des dépôts à forte valeur, mener des campagnes massives de ransomware ou lancer des attaques destructrices sur la supply chain
• L’affaire rappelle l’importance de mettre en œuvre une sandbox et le principe du moindre privilège lors de l’intégration d’outils d’analyse externes et de services d’automatisation basés sur l’IA

[GN⁺]

Avis Hacker News

• Oh là là, c’est une vulnérabilité vraiment grave. Heureusement qu’elle a été corrigée cette fois, mais le vrai problème, c’est qu’un tel défaut ait existé au départ. La règle de base absolue quand on conçoit un système qui analyse du code utilisateur sur une plateforme cloud, c’est que l’analyseur doit impérativement s’exécuter dans un environnement isolé. L’injection directe de code peut se produire via des plugins, et les linter/analyseurs/compilateurs sont des logiciels complexes avec une large surface d’attaque. Il ne faut jamais partir du principe qu’exécuter ce type d’outils sur des dépôts arbitraires dans un environnement partagé est sans danger. J’ai moi-même exploité une plateforme d’analyse de code, et même quand nous faisions tourner nos propres analyseurs sur les dépôts clients, tout était conçu pour fonctionner dans un environnement sandboxé. Il n’y avait ni variables d’environnement ni permissions de requêtes réseau, et l’analyse ne s’exécutait que dans le sandbox. C’est la seule manière de faire de l’analyse de code en toute sécurité
  https://github.com/getgrit/gritql

• J’ai annulé mon abonnement payant à CodeRabbit. Ce qui m’inquiète toujours, c’est quand il faut qu’un sujet devienne viral sur HN pour qu’une entreprise reconnaisse le problème. Il n’y a aucune mention de cette vulnérabilité sur le blog officiel, et aucun nouvel article aujourd’hui. Je pense que tout le monde peut faire des erreurs, mais le fait de ne pas communiquer de façon transparente quand ce genre de chose arrive nuit à l’image de l’entreprise

  • https://www.coderabbit.ai/blog/our-response-to-the-january-2025-kudelski-security-vulnerability-disclosure-action-and-continuous-improvement
  • Les deux articles ont été publiés aujourd’hui. À en juger par cela, l’équipe de recherche et CodeRabbit semblent avoir convenu d’une divulgation simultanée. Ce type de publication coordonnée n’est pas forcément obligatoire, sauf en cas de fuite de données clients ou d’indices circonstanciels, mais c’est une pratique qu’on voit parfois quand l’éditeur choisit de jouer le jeu. Le fait que les chercheurs en sécurité saluent leur réaction me paraît être un bon signal
  • La plupart des bugs de sécurité sont corrigés discrètement, sans annonce particulière. S’il n’y a pas eu de fuite de données client (et en général, cela peut être vérifié), la loi n’impose pas de divulgation. Je ne vois pas pourquoi cela devrait absolument être rendu public alors qu’il n’y a pas vraiment d’avantage à le faire

• Le fait que « pendant l’exécution de l’exploit, CodeRabbit lui-même ait laissé un commentaire d’avertissement sur la PR, alors qu’en réalité le piratage se produisait justement en exécutant cette PR » est vraiment bizarre. Vivre dans un monde où une IA explique qu’elle est en train de se faire pirater donne une impression irréelle. Et même si l’équipe CodeRabbit a réagi rapidement, ce qui m’inquiète davantage, c’est que « d’autres fournisseurs n’ont même pas répondu aux sollicitations de l’enquête et sont toujours vulnérables ». Bravo à l’équipe CodeRabbit, mais tout le monde devrait avancer avec beaucoup de prudence

  • C’est amusant de voir CodeRabbit relire lui-même l’exploit qui s’est exécuté sur son propre système
  • En réalité, c’est le modèle d’Anthropic qui a décrit l’exploit, et le système CodeRabbit l’a simplement ignoré
  • Encore une démonstration que l’IA n’est pas « intelligente », mais juste un système d’inférence qui fait souvent de bonnes suppositions

• Dans une partie de la déclaration officielle du CEO, il est dit que « le problème venait du fait que Rubocop s’exécutait hors du sandbox », mais honnêtement, j’ai des doutes. Pourquoi un seul composant se comportait-il de façon complètement différente, et pourquoi est-ce justement celui-là qui a été compromis ?

  • Je ne vois pas pourquoi ça ressemblerait à un mensonge. Ce genre d’erreur arrive souvent
  • Au départ, il est très probable que les chercheurs de Kudelski Security aient testé plusieurs outils d’analyse statique. Rubocop est simplement celui qui s’est comporté de façon atypique. L’article montre aussi des traces de différentes tentatives d’approche
  • « Pourquoi une seule tâche était configurée différemment ? » → parce que quelqu’un a fait une erreur. Ce genre de chose peut arriver. Quant à « pourquoi le service vulnérable a-t-il précisément été attaqué ? », je pense qu’il est au contraire tout à fait naturel qu’un service vulnérable soit la cible

• C’était un article vraiment intéressant, mais au fond ce n’est pas si surprenant. Les utilisateurs ajoutent sans réfléchir une multitude d’apps aux permissions excessives, et le système d’autorisations de GitHub lui-même pose problème, donc ce genre de situation était inévitable. Beaucoup de gens accordent beaucoup trop librement des permissions d’écriture sur les dépôts via les GitHub Apps, voire des permissions cloud. Même avec une protection de branche, il reste possible d’obtenir un accès privilégié via les GitHub Actions dans une pull request. Pour bien configurer cela, il faut modifier l’audience GitHub OIDC, et c’est mal documenté. Même quand on demande aux éditeurs d’apps de fournir une version séparée avec moins de permissions et certaines fonctions désactivées, la plupart ne s’y intéressent pas et ne comprennent pas les enjeux de sécurité. GitHub devrait permettre une granularité plus fine des permissions des apps, et de manière générale les autorisations devraient être beaucoup plus détaillées

• C’est vraiment sidérant. Je n’ai même pas encore fini de lire l’article, il y a tellement de choses que ça en devient vertigineux. En lisant qu’un attaquant aurait pu injecter un malware dans les artefacts de distribution de 100 000 à 1 000 000 d’outils open source/bibliothèques/logiciels, j’en suis arrivé à penser que le monde aurait pu basculer. Il est difficile d’imaginer combien de problèmes similaires restent encore à découvrir

  • J’en viens à penser que les « GitHub Apps » elles-mêmes sont dangereuses. Même si CodeRabbit n’avait pas été compromis, qui garantit qu’un fournisseur de ce type agira toujours de façon irréprochable ? Qui peut garantir qu’un employé interne n’agira pas de manière malveillante ? Dans un SaaS classique, la gestion des données personnelles est un sujet en soi, mais ici ces acteurs détiennent la clé d’attaques ciblées sur la supply chain et pourraient provoquer un chaos massif
  • L’industrie du logiciel devrait au minimum introduire des garde-fous ou une forme de régulation. La situation actuelle, où n’importe qui peut commettre n’importe quelle erreur sans aucune responsabilité, est vraiment anormale

• Je pense qu’un échec de sécurité aussi grave devrait être classé comme « compromission » ou « incident » et faire l’objet d’une divulgation obligatoire dans la presse. On parle d’un outil pouvant accéder à environ 7 000 clients et 1 million de dépôts, compromis par un exploit simplissime qu’un enfant de 11 ans aurait pu écrire. Si le piratage était aussi facile, il est très probable que des bots, des black hats ou des APT aient déjà pénétré le système et s’y soient installés discrètement. S’ils étaient là avant la divulgation par les white hats, alors corriger la vulnérabilité ne ferait que bloquer de nouveaux attaquants, sans forcément déloger ceux déjà infiltrés. Je sais que la sécurité est difficile, mais franchement, il faut se réveiller

  • Si on parle de « divulgation obligatoire », on peut regarder du côté du Cyber Resilience Act
  • Code Rabbit est une boîte de « vibe coders », donc je ne sais pas trop à quoi il fallait s’attendre. Ils cachent un incident de sécurité, publient uniquement du contenu marketing sur le blog Google Cloud sans même mentionner le piratage, et sont toujours incapables de prouver l’absence de backdoor
  • En tant qu’utilisateur ordinaire, le fait qu’un service aussi complexe et puissant puisse, par erreur, exposer toutes mes données précieuses à l’extérieur me fait sérieusement me demander si je veux continuer à utiliser ce genre d’outil. D’innombrables organisations, administrations, sous-traitants bancaires et autres utilisent ce type d’apps, et il suffit d’accepter les T&C pour céder un accès à un tiers. Le discours rassurant du type >>« cela peut arriver à toutes les entreprises »<< est peut-être consolant pour le fournisseur, mais pour les utilisateurs, c’est encore plus inquiétant

• L’un des problèmes est que toutes sortes d’analyseurs de code, bundlers et compilateurs (par exemple le compilateur Rust) peuvent exécuter du code arbitraire sans aucun avertissement. Par exemple, un pirate peut m’envoyer un dépôt sous prétexte d’un exercice de recrutement, et si j’exécute npm install ou une commande de compilation Rust, ma machine peut immédiatement tomber entre ses mains. Ou bien si le PC d’un collègue est compromis et qu’un malware entre dans le dépôt, il devient possible qu’une multinationale entière finisse compromise par des pirates étrangers. Cette architecture est le fait de npm et du compilateur Rust. Ces outils devraient demander une confirmation explicite à chaque exécution d’une commande externe (avec éventuellement une mise en cache d’une liste blanche pour ne pas redemander à chaque fois). Linux aussi devrait fournir un sandbox sûr et facile à utiliser pour les développeurs, alors qu’aujourd’hui il faut le construire soi-même à la main. En plus, dans certains cas comme l’installation de packages JS, il n’est même pas nécessaire d’exécuter du code externe. Et mettre les secrets et la configuration dans des variables d’environnement est une très mauvaise pratique. On dirait que les auteurs du « 12-factor app » ignorent l’existence des options en ligne de commande et des fichiers de configuration

  • Il faut toujours garder à l’esprit qu’exécuter des analyseurs de code/builders/linters sur un dépôt n’est absolument pas plus sûr que d’exécuter directement le code source lui-même
  • Pour le compilateur Rust (et les compilateurs basés sur LLVM), il est prudent de supposer l’existence de vulnérabilités permettant l’exécution de code arbitraire. Officiellement toutefois, cette capacité relève du build system cargo, pas de rustc lui-même
  • Si on utilise la ligne de commande ou un fichier de configuration à la place des variables d’environnement, les valeurs risquent d’être exposées dans la table des processus. Un simple ps suffit pour tout voir
  • L’idée implicite qu’il pourrait exister du « code de valeur qui ne sera jamais exécuté » est assez drôle
  • Le modèle « demander une confirmation explicite à chaque exécution d’une commande externe » ne sert à rien. Le problème n’est pas la commande externe, mais l’exécution de code arbitraire elle-même. Ce code peut accéder à toutes les API système et à tous les syscalls, donc il n’y a aucun moyen réaliste de demander une confirmation. Python/pip a exactement le même problème, donc il est déjà trop tard

• Le fait que la clé privée donnant le pouvoir de « devenir une GitHub App à volonté » ait été stockée dans une variable d’environnement est une pratique vraiment catastrophique. Tout le monde peut se faire pirater, mais là on parle des bases les plus élémentaires de la gestion des secrets. La documentation officielle de GitHub dit clairement de ne pas mettre une clé privée dans une variable d’environnement. C’est vraiment le B.A.-BA
  https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps#storing-private-keys

  • Si le secret n’est pas destiné à la signature, alors de toute façon il faut le récupérer depuis un vault vers l’application, ce qui veut dire qu’avoir accès au système de production revient de fait à avoir accès à ce secret. Bien sûr, dans un contexte d’exécution de code non fiable, il aurait fallu isoler l’environnement et ne pas transmettre ce genre de clé, mais ce cas reste inhabituel dans la pratique
  • Ici Howon de CodeRabbit. Nous utilisons le key vault du fournisseur cloud pour les secrets de l’application, y compris la clé privée GitHub

• Au moment où j’ai lu qu’il était possible de spécifier un chemin de fichier Ruby étendu dans la configuration Rubocop, je me suis dit : « ils n’ont quand même pas exécuté des outils d’extension utilisateur directement en production… » Et bien sûr que si. Cela dit, bloquer uniquement ce trou ne rend pas l’ensemble réellement sûr. Il est rare que la plupart des linters aient été audités ou fuzzés sérieusement face à des entrées hostiles ; là, c’était comme laisser la porte grande ouverte avec une enseigne au néon “Venez me pirater !”

  • En voyant dans la réponse officielle du CEO la phrase « Rubocop s’exécutait hors du sandbox », je ne pense pas que ce soit réellement le cœur du problème