CodeRabbit-Schwachstellen-Exploit: Von einem einfachen PR zu RCE und Schreibzugriff auf 1 Mio. Repositories

 (research.kudelskisecurity.com)
1 Punkte von GN⁺ 2025-08-20 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Sicherheitsteam konnte auf den Produktionsservern von CodeRabbit Remote Code Execution (RCE) sowie den Abfluss von API-Tokens und Geheimnissen erreichen
  • Über einen PR unter Nutzung von Rubocop konnten Umgebungsvariablen exfiltriert werden; Zugriff auf PostgreSQL sowie Lese-/Schreibzugriff auf 1 Million Repositories waren möglich
  • Durch den Abfluss des privaten Schlüssels der GitHub App waren reale Schäden möglich, darunter das Einschleusen von Schadcode und Änderungen am Quellcode in großem Umfang, auch in öffentlichen und privaten Repositories
  • CodeRabbit reagierte innerhalb weniger Stunden nach der Meldung sofort und verstärkte die Sicherheitsmaßnahmen
  • Beim Ausführen externer Tools wird die Notwendigkeit betont, Sicherheitsvorfälle durch Sandbox-Isolation, Least Privilege und Netzwerksperren zu verhindern

Einführung

  • Im Januar 2025 veröffentlichte das Forschungsteam von Kudelski Security eine schwerwiegende Sicherheitslücke in CodeRabbit
  • Bei CodeRabbit, das weithin als Tool zur Automatisierung von PR-Reviews genutzt wird, wurden gravierende Probleme festgestellt: Remote Code Execution (RCE), Abfluss von Umgebungsvariablen und sensiblen Informationen sowie Read/Write-Zugriff auf mehr als 1 Million Repositories
  • Dieser Beitrag enthält eine detaillierte Analyse der auf der Black Hat USA vorgestellten offengelegten Schwachstelle und ist als praxisnahes Beispiel für Schwachstellen in codebasierten Review-Tools und angebundenen Systemen besonders relevant
  • Die gemeldete Schwachstelle wurde unmittelbar nach der Meldung schnell gepatcht

Überblick über CodeRabbit

  • CodeRabbit ist die am häufigsten installierte KI-basierte Code-Review-App im GitHub- und GitLab-Marketplace
  • Auf beiden Plattformen wurden 1 Million Repositories und 5 Millionen Pull Requests geprüft
  • Jedes Mal, wenn ein Nutzer einen PR erstellt oder aktualisiert, analysiert die KI-Engine den Code und erzeugt automatisch Kommentare und Vorschläge
  • Funktionen wie Code-Zusammenfassungen, Erkennung von Sicherheitslücken, Verbesserungsvorschläge und Diagrammerstellung steigern die Produktivität in der Entwicklung deutlich

Nutzung von CodeRabbit und Berechtigungsstruktur

  • Der Pro-Plan bietet die Integration von Linter- und SAST-Tools (statische Analyse)
  • Bei der Authentifizierung des GitHub-Kontos und der Installation der App werden Lese-/Schreibrechte für ausgewählte Repositories erteilt
  • Wenn dieses Berechtigungsmodell missbraucht wird, kann es den Code in allen installierten Repositories direkt beeinflussen

Ausführung externer Tools und Entdeckung des Exploits

  • Erkennt CodeRabbit Code-Änderungen in einem PR, führt es automatisch mehrere externe Tools zur statischen Analyse (z. B. Rubocop) aus
  • Rubocop ist so konzipiert, dass über die Konfigurationsdatei .rubocop.yml externe Ruby-Erweiterungsdateien (ext.rb usw.) geladen werden können
    • Ein Angreifer kann Schadcode in .rubocop.yml und ext.rb einfügen und dann einen PR einreichen, um CodeRabbit dazu zu bringen, diesen Code auf dem Remote-Server auszuführen
  • Der so ausgeführte Code übertrug sämtliche Umgebungsvariablen des Servers an den Server des Angreifers

Analyse der exfiltrierten Umgebungsvariablen

  • Die exfiltrierten Umgebungsvariablen enthielten API-Keys, Tokens und Passwörter verschiedener Dienste, darunter
    • API-Keys von Anthropic/OpenAI, Encryption salt/password, privater Schlüssel der GitHub App, PostgreSQL-Zugangsdaten usw.
  • Durch RCE waren umfangreiche Folgeauswirkungen mit hoher Tragweite möglich, etwa Datenbankzugriff, Code-Änderungen und der Abfluss interner Service-Informationen
  • Auf dem produktiven Server hätte eine weitergehende bösartige Exploration stattfinden können, wurde jedoch mit Rücksicht auf den Betrieb nach einer Minimalverifikation abgebrochen

Erlangung von Read/Write-Zugriff auf 1 Million Repositories

  • Mit der in den Umgebungsvariablen enthaltenen GITHUB_APP_PEM_FILE (privater Schlüssel) war eine Authentifizierung gegenüber der GitHub API möglich
  • Für alle Repositories, auf die CodeRabbit zugreifen konnte, einschließlich öffentlicher und privater,
    • konnten äußerst weitreichende Rechte ausgeübt werden, etwa Quellcode lesen/schreiben, Release-Dateien ersetzen (Supply-Chain-Angriff) und die Git-Historie verändern
  • Der veröffentlichte Reproduktionscode (PoC) belegte, dass eine tatsächliche Ausnutzung möglich war

Zusammenfassung des PoC

  • Mithilfe von Bibliotheken wie PyGitHub konnten mit dem exfiltrierten privaten Schlüssel, der App-ID usw. beliebige Repository-Access-Tokens ausgestellt werden
  • Mit diesen Tokens konnten das Klonen privater Repositories, Dateiänderungen, neue Commits und die Manipulation von Release-Dateien automatisiert werden

Möglichkeit der Kompromittierung interner/nicht öffentlicher Repositories von CodeRabbit

  • Da auch die CodeRabbit-Organisation die App im eigenen Service installiert und genutzt hatte, war der Zugriff auf und das Klonen der internen Quellcode-Repositories von CodeRabbit ebenfalls möglich
  • Wenn nur der Name der Organisation bekannt war, konnte nach Abfrage der Installations-ID direkt auf die entsprechende Repository-Liste zugegriffen werden

Zusammenfassung der Auswirkungen

  • Unbefugter Zugriff auf private Repositories und Abfluss personenbezogener Daten
  • Bedrohung durch Supply-Chain-Angriffe wie Manipulation von Quellcode sowie Einschleusen von Schadcode/Backdoors
  • Möglichkeit zur Verkettung mit weiteren Schwachstellen, etwa in GitHub Actions
  • Direkte RCE mit möglichen Folgen wie Datenzerstörung, Dienstausfällen und Kaskadenschäden in anderen Services

Kontext und Grenzen der KI-Bewertung

  • Auch während des Angriffs wurde der PR von CodeRabbit selbst normal geprüft; zwar wurde ein Warnkommentar zur Schwachstelle hinterlassen, die tatsächlich bedrohliche Syntax wurde jedoch nicht erkannt
  • Das zeigt, dass ein „KI-Code-Review-Tool“ den Kontext realer Gefahrensituationen nicht unbedingt erfassen kann

Reaktion und Empfehlungen

  • CodeRabbit deaktivierte Rubocop innerhalb weniger Stunden nach der Meldung, tauschte Geheimnisse aus und führte ein System-Audit durch
  • Das Problem trat bei einem Tool ohne Sandbox-Anwendung (Rubocop) auf; nach den Maßnahmen wurde dies verbessert, sodass alle externen Tools in isolierten Umgebungen ausgeführt werden
  • Zur Stärkung der Sicherheit wird die Notwendigkeit defensiver Architektur betont, etwa durch Minimierung von Umgebungsvariablen im Ausführungskontext externer Tools, Einschränkung zulässiger Netzwerk-IP-Adressen und Sperrung des Internetzugangs

Verantwortungsvolle Offenlegung und Fazit

  • Im Januar 2025 erfolgten nach der Meldung eine schnelle Reaktion und Gegenmaßnahmen
  • Es blieb beim PoC, doch es wurde bestätigt, dass ein bösartiger Angreifer dies leicht für die Auswahl hochwertiger Repositories, groß angelegte Ransomware oder destruktive Supply-Chain-Angriffe hätte missbrauchen können
  • Erneut bestätigt wurde die Bedeutung der Umsetzung von Sandboxing und dem Least-Privilege-Prinzip bei der Anbindung externer Analysetools und KI-basierter Automatisierungsdienste

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-20
Hacker-News-Kommentare

  • Oh wow, das ist wirklich eine gravierende Schwachstelle. Gut, dass sie diesmal behoben wurde, aber schon die Tatsache, dass so ein Problem überhaupt existierte, ist problematisch. Die grundlegendste Regel beim Bau eines Systems, das Nutzercode auf einer Cloud-Plattform analysiert, ist, dass der Analyzer unbedingt in einer isolierten Umgebung laufen muss. Über Plugins kann direkt Code eingeschleust werden, und Linter/Analyzer/Compiler sind komplexe Software mit großer Angriffsfläche. Man sollte niemals davon ausgehen, dass es ungefährlich ist, solche Tools für beliebige Repositories in einer gemeinsam genutzten Umgebung auszuführen. Ich habe selbst eine Code-Analyse-Plattform betrieben, und selbst wenn wir unsere selbst entwickelten Analyzer auf Kundenspeichern ausgeführt haben, war das so entworfen, dass sie in einer Sandbox laufen. Sie hatten weder Zugriff auf Umgebungsvariablen noch auf Netzwerk-Requests, und die Analyse lief ausschließlich in der Sandbox. Das ist die einzige Möglichkeit, Code-Analyse sicher zu machen
    https://github.com/getgrit/gritql

  • Ich habe mein kostenpflichtiges Coderabbit-Abo gekündigt. Es beunruhigt mich immer, wenn ein Unternehmen ein Problem erst dann anerkennt, wenn es auf HN viral geht. Auf dem offiziellen Blog gibt es nirgends einen Hinweis auf diese Schwachstelle, und auch heute keinen neuen Beitrag. Fehler können jedem passieren, aber wenn so etwas geschieht und man es nicht transparent offenlegt, schadet das dem Unternehmensimage

    • https://www.coderabbit.ai/blog/our-response-to-the-january-2025-kudelski-security-vulnerability-disclosure-action-and-continuous-improvement
    • Beide Artikel wurden heute veröffentlicht. Es sieht so aus, als hätten das Forschungsteam und Coderabbit eine gleichzeitige Veröffentlichung vereinbart. Solche koordinierten Veröffentlichungen sind nicht zwingend erforderlich, solange es keinen Kundendatenabfluss oder forensische Hinweise darauf gibt, und kommen öfter vor, wenn ein Anbieter sich freiwillig zur Offenlegung entschließt. Dass die Sicherheitsforscher die Reaktion loben, wirkt wie ein gutes Zeichen
    • Die meisten Sicherheitsfehler werden still und ohne große Ankündigung behoben. Wenn keine Kundendaten abgeflossen sind (und das lässt sich normalerweise feststellen), ist eine Offenlegung rechtlich nicht vorgeschrieben. Ich sehe keinen besonderen Vorteil darin, also verstehe ich nicht, warum das unbedingt nötig sein soll

  • Dass CodeRabbit während der Ausführung des Exploits selbst einen Warnkommentar im PR hinterlassen hat, während genau durch diesen PR der Hack stattfand, ist schon bizarr. Es fühlt sich surreal an, in einer Welt zu leben, in der eine AI erzählt, dass sie gerade gehackt wird. Außerdem hat das CodeRabbit-Team zwar schnell reagiert, aber noch beunruhigender ist, dass „andere Anbieter trotz Kontaktaufnahme der Forscher überhaupt nicht geantwortet haben und weiterhin verwundbar sind“. Für das CodeRabbit-Team gibt es Applaus, aber alle sollten sehr vorsichtig vorgehen

    • Es ist lustig, dass CodeRabbit den Exploit, der auf dem eigenen System lief, selbst reviewt hat
    • Tatsächlich hat eher das Anthropic-Modell den Exploit beschrieben, und das Coderabbit-System hat ihn ignoriert
    • Es zeigt wieder einmal, dass AI nicht wirklich klug ist, sondern eher ein gut treffendes Inferenzsystem

  • In einem Teil der offiziellen Erklärung des CEO heißt es, „das Problem sei entstanden, weil Rubocop außerhalb der Sandbox lief“, aber ehrlich gesagt erscheint mir das etwas fragwürdig. Warum lief genau dieses eine Ding völlig anders, und warum war ausgerechnet das der angreifbare Job?

    • Ich verstehe nicht, warum das wie eine Lüge wirken soll. Solche Fehler passieren häufig
    • Die Forscher von Kudelski Security haben mit hoher Wahrscheinlichkeit mehrere statische Analyse-Tools ausprobiert. Rubocop hat sich nur auf eine besondere Weise verhalten. Auch im Artikel sieht man Spuren verschiedener Versuche
    • „Warum war ein bestimmter Job anders konfiguriert?“ → Weil jemand einen Fehler gemacht hat. Das kann passieren. Und auf die Frage „Warum war ausgerechnet der verwundbare Service betroffen?“ würde ich sagen: Dass ein verwundbarer Service angegriffen wird, ist eher das natürliche Szenario

  • Ein wirklich interessanter Beitrag, aber eigentlich keine Überraschung. Dass Nutzer gedankenlos massenhaft Apps mit sehr weitreichenden Rechten hinzufügen und dass auch das GitHub-Berechtigungssystem problematisch ist, machte so etwas nahezu unvermeidlich. Viele erlauben GitHub-Apps missbräuchlich Schreibrechte auf Repositories oder sogar Cloud-Berechtigungen. Selbst mit Branch Protection kann man über Pull Requests privilegierten Zugriff in GitHub Actions bekommen. Um das sauber zu konfigurieren, muss man die GitHub-OIDC-Audience anpassen, und das ist kaum dokumentiert. Selbst wenn man App-Anbieter bittet, eine separate Version mit weniger Rechten und deaktivierten Funktionen bereitzustellen, sind die meisten nicht interessiert und verstehen das Sicherheitsproblem nicht. GitHub sollte App-Berechtigungen viel granularer machen, und generell müssten Berechtigungen feiner abgestuft werden

  • Das ist wirklich schockierend. Ich habe den Artikel noch nicht einmal ganz gelesen, und es ist schon so viel, dass mir der Kopf schwirrt. Bei der Stelle, dass ein Hacker Malware in die Auslieferungsdateien von Open-Source-Tools/Bibliotheken/Software in einer Größenordnung von 100.000 bis 1.000.000 einschleusen konnte, dachte ich kurz, davon hätte die Welt untergehen können. Es ist kaum vorstellbar, wie viele ähnliche Probleme noch existieren könnten

    • Inzwischen denke ich, dass „GitHub Apps“ an sich riskant sind. Selbst wenn CodeRabbit nicht kompromittiert worden wäre, wer garantiert denn, dass so ein Anbieter sich immer redlich verhält? Wer garantiert, dass kein interner Mitarbeiter böswillig handelt? Bei normalem SaaS ist der Umgang mit personenbezogenen Daten eine Sache, aber hier hält man den Schlüssel für gezielte Supply-Chain-Angriffe in der Hand, was totales Chaos auslösen kann
    • Auch in der Softwarebranche sollte es zumindest minimale Schutzvorkehrungen oder Regulierung geben. Dass aktuell jeder jeden Fehler machen kann, ohne dafür irgendeine Verantwortung zu tragen, ist wirklich anormal

  • Ich finde, solch schwere Sicherheitsversagen sollten als „Sicherheitsverletzung“ oder „Vorfall“ eingestuft und verpflichtend öffentlich gemacht werden. Wir reden hier von einem Tool mit Zugriff auf rund 7.000 Kunden und 1 Million Repositories, das von einem simplen Exploit geknackt wurde, den im Zweifel sogar ein Elfjähriger hätte bauen können. Wenn der Hack so einfach war, ist es gut möglich, dass Bots, Black Hats oder APTs bereits eingedrungen sind und sich unauffällig eingenistet haben. Falls sie schon vor der Veröffentlichung durch White Hats drin waren, stoppt ein Patch nur neue Angreifer, entfernt aber möglicherweise keine bereits versteckten Eindringlinge. Mir ist klar, dass Sicherheit schwierig ist, aber hier muss man wirklich aufwachen

    • Wenn man „verpflichtend offenlegen“ will, kann man sich den Cyber Resilience Act ansehen
    • Code Rabbit ist eine „Vibe-Coder“-Firma, daher weiß ich nicht, was man da groß erwarten soll. Sie verbergen den Sicherheitsvorfall, posten im Google-Cloud-Blog nur Marketingmaterial ohne den Hack überhaupt zu erwähnen und können immer noch nicht belegen, dass keine Backdoor vorhanden ist
    • Als normaler Nutzer frage ich mich inzwischen ernsthaft, ob ich solche komplexen und mächtigen Dienste weiter verwenden sollte, wenn sie durch einen Fehler all meine wertvollen Daten nach außen leaken können. Solche Apps werden überall eingesetzt – in Organisationen, Behörden, bei Bankdienstleistern und an zahllosen anderen Orten –, und mit einem Klick auf die AGB überträgt man Dritten Zugriffsrechte. >>„Beruhigende Floskeln wie: Das kann jedem Unternehmen passieren“<< mögen den Anbieter trösten, machen Nutzern aber nur noch mehr Sorgen

  • Eines der Probleme ist, dass verschiedenste Code-Analyzer, Bundler und Compiler (z. B. der Rust-Compiler) ohne jede Warnung beliebigen Code ausführen können. Ein Hacker könnte mir etwa ein Repository als Bewerbungsaufgabe schicken, und sobald ich npm install oder einen Rust-Kompilierbefehl ausführe, gehört mein Rechner womöglich sofort dem Angreifer. Oder der PC eines Kollegen wird kompromittiert, Malware landet im Repository, und am Ende wird ein globaler Großkonzern von ausländischen Hackern übernommen. Diese Struktur haben npm und der Rust-Compiler geschaffen. Solche Tools sollten jedes Mal, wenn sie externe Befehle ausführen, eine explizite Bestätigung verlangen können (man könnte erlaubte Befehle cachen, damit nicht jedes Mal nachgefragt wird). Linux sollte Entwicklern außerdem leicht nutzbare sichere Sandboxes bereitstellen; derzeit muss man so etwas mühsam selbst bauen. Dazu kommt, dass es Fälle wie die Installation von JS-Paketen gibt, in denen die Ausführung von Fremdcode gar nicht nötig wäre. Und Geheimnisse und Konfiguration per Umgebungsvariablen zu hinterlegen, ist wirklich eine schlechte Praxis. Die Person hinter der „12-factor app“ scheint nicht zu wissen, dass es Kommandozeilen-Schalter und Konfigurationsdateien gibt

    • Man sollte sich immer bewusst machen, dass das Ausführen von Analyzern/Buildern/Lintern auf einem Repository keineswegs sicherer ist, als den Quellcode selbst direkt auszuführen
    • Beim Rust-Compiler (und LLVM-basierten Compilern) ist es sicherer, von Schwachstellen zur Ausführung beliebigen Codes auszugehen. Formal betrifft diese Funktionalität aber nur das Build-System cargo, nicht rustc selbst
    • Wenn man statt Umgebungsvariablen Kommandozeile/Konfigurationsdateien nutzt, werden Werte in der Prozesstabelle sichtbar. Schon ein ps-Befehl reicht, um alles offenzulegen
    • Die Andeutung, es könne „wertvollen Code geben, der niemals ausgeführt wird“, ist lustig
    • Eine „explizite Bestätigung bei jedem externen Befehl“ hilft nicht weiter. Das Problem sind nicht externe Befehle, sondern die Ausführung beliebigen Codes selbst. Solcher Code hat Zugriff auf alle System-APIs und Syscalls, also gibt es nichts, was man sinnvoll bestätigen könnte. Python/pip haben genau dasselbe Problem, daher ist es ohnehin schon zu spät

  • Dass der Schlüssel mit den Rechten, „nach Belieben eine GitHub-App zu werden“ (der Private Key), in einer Umgebungsvariable gespeichert war, ist wirklich eine katastrophale Praxis. Jeder kann gehackt werden, aber das hier ist die absolute Grundlage der Geheimnisverwaltung. Selbst in der offiziellen GitHub-Dokumentation steht klar, dass man Private Keys nicht in Umgebungsvariablen speichern soll. Das ist absolute Basics
    https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/managing-private-keys-for-github-apps#storing-private-keys

    • Wenn ein Geheimnis nicht zum Signieren dient, muss es am Ende ohnehin aus einem Vault in die App geholt werden. Wer Zugriff auf das Produktionssystem hat, hat damit letztlich auch Zugriff auf dieses Geheimnis. Natürlich hätte man bei der Ausführung nicht vertrauenswürdigen Codes die Umgebung isolieren und solche Schlüssel gar nicht weiterreichen dürfen, aber das ist eher ein Sonderfall
    • Hier ist Howon von CodeRabbit. Wir verwenden für App-Geheimnisse den Key Vault unseres Cloud-Anbieters, einschließlich des GH-Private-Keys

  • In dem Moment, als ich las, dass man in der Rubocop-Konfigurationsdatei den Pfad zu erweiterten Ruby-Dateien angeben kann, dachte ich sofort: „Die werden doch nicht ernsthaft benutzerdefinierte Erweiterungstools direkt in der Produktionsumgebung ausgeführt haben ...“ – und genau so war es. Natürlich ist das System nicht wirklich sicher, nur weil man dieses eine Loch stopft. Die meisten Linter dürften kaum gegen bösartige Eingaben auditiert oder gefuzzt worden sein. Das ist, als hätte man die Tür offen stehen lassen und ein Neonschild aufgehängt mit „Bitte hackt uns!“

    • Wenn man sich die Aussage des CEO ansieht, dass „Rubocop außerhalb der Sandbox lief“, scheint das nicht einmal der eigentliche Kern des Problems zu sein