Coder: Kompromittierte Registry – bösartige Terraform-Module stahlen Cloud-Zugangsdaten und KI-Token

Anfragen an vom Angreifer kontrollierte Server umgeleitet

Die mit registry.coder.com, der zentralen Registry für Coder-Module, verbundene Infrastruktur wurde kompromittiert und zur Verteilung manipulierte Terraform-Pakete verwendet. Der Vorfall wird als Critical eingestuft und erhält einen CVSS-v4-Score von 9,0 von 10.

Ein bislang nicht identifizierter Akteur erlangte Zugriff auf Coders Cloudflare-Infrastruktur und fügte nicht autorisierte IP-Adressen zum Server-Pool der Registry hinzu. Dadurch leitete Cloudflare einen Teil der Benutzeranfragen an vom Angreifer kontrollierte Systeme statt an die legitimen Server weiter.

Die schädlichen Systeme ahmten das Verhalten der Registry nach und lieferten Artefakte mit bösartigem Code aus. Nicht zwangsläufig alle Anfragen gelangten zur gefälschten Infrastruktur: Die Verteilung hing von der Lastverteilung zwischen den im Pool enthaltenen Adressen ab.

Das Zeitfenster der Gefährdung reicht vom 31. August 2026, 07:35 UTC, bis 21:45 UTC. Das am 1. September 2026 unter dem Titel „Malicious Packages Served from Unauthorized Registry Server“ veröffentlichte Security Advisory weist darauf hin, dass jedes Deployment, das in diesem Zeitraum ein Modul abgerufen hat, als potenziell betroffen betrachtet werden muss.

Die Kompromittierung betrifft eine kritische Komponente der Software-Lieferkette. Coder wird zur Bereitstellung sicherer, selbst gehosteter Cloud-Entwicklungsumgebungen eingesetzt – auch zum Erstellen und Deployment von Anwendungen für künstliche Intelligenz. Zu den Organisationen, die die Plattform laut Angaben nutzen, gehören Dropbox, Palantir, Square, Mercedes-Benz, KKR, EnBW, die US-Regierung und Unternehmen aus dem Verteidigungssektor. Welche Kunden tatsächlich manipulierte Module erhalten haben, ist nicht bekannt.

Der in den Terraform-Modulen versteckte Stealer

Die bösartigen Pakete fungierten als Information Stealer innerhalb der Umgebung, in der der Provisioner den Terraform-Code ausführte. Ziel war es, Zugangsdaten und Konfigurationen zu sammeln, die den Zugriff auf Cloud-Infrastrukturen, Entwicklungs-Pipelines und externe Dienste ermöglichen.

Der Code suchte unter anderem nach:

• Umgebungsvariablen und Secrets, die auf dem Provisioner verfügbar waren;
• API-Schlüsseln von Cloud-Providern;
• API-Schlüsseln für Werkzeuge der künstlichen Intelligenz;
• CI/CD-Zugangsdaten;
• in Konfigurationsdateien gespeicherten Secrets;
• der Terminal-Historie;
• OIDC-Token der Benutzer;
• konfigurierten SSH-Schlüsseln;
• einmalig verwendbaren Token für externe Authentifizierungsanbieter;
• dem Datenbankpasswort von Coder;
• Konfigurationen, auf die zugegriffen werden konnte, wenn der Provisioner innerhalb von coderd ausgeführt wurde.

Die gesammelten Informationen wurden an coder-infra[.]com übermittelt – eine Domain, die so gewählt wurde, dass sie mit der legitimen Coder-Infrastruktur kompatibel wirkte. Die im Advisory genannte Adresse lautet www[.]coder-infra[.]com; die Domain soll am 28. August 2026 registriert worden sein.

Der Umfang der erreichbaren Daten hing vom jeweiligen Vorgang ab. Beim Laden, Aktualisieren oder bei einem Dry Run eines Templates erhielt der Provisioner weder die Secrets noch die personenbezogenen Informationen des Benutzers. Bereits auf dem Provisioner vorhandene Werte, darunter Umgebungsvariablen und lokale Zugangsdaten, waren jedoch weiterhin gefährdet.

Das Risiko stieg beim Erstellen eines Workspace. In diesem Szenario konnte der Provisioner das OIDC-Token des Benutzers, den zugehörigen SSH-Schlüssel – sofern konfiguriert – sowie die Token aktivierter externer Provider für das betreffende Template erhalten. Letztere waren einmalig verwendbar; Refresh-Token wurden laut Coder nicht übertragen.

Wenn der Provisioner innerhalb von coderd ausgeführt wurde, konnte der schädliche Code außerdem auf das Datenbankpasswort und weitere sensible Einstellungen der Plattform zugreifen. Die Kompromittierung konnte sich damit über den einzelnen Workspace hinaus ausbreiten.

Betroffene Deployments und Versionen

Betroffen sind alle Coder-Versionen vor 2.37.0. Die korrigierten Releases sind:

• 2.37.0
• 2.36.4
• 2.35.7
• 2.34.9

Das Update kann somit auf die neueste Version oder auf das korrigierte Release des jeweils eingesetzten unterstützten Versionszweigs erfolgen. Der Vorfall hat keine CVE-Kennung.

Ein Deployment kann betroffen sein, wenn es während des Zeitfensters der Gefährdung ein Modul von registry.coder.com heruntergeladen hat. Dies geschieht insbesondere beim Erstellen eines neuen Templates oder einer neuen Version eines Templates.

Auch das Erstellen eines Workspace kann einen erneuten Download auslösen, allerdings vor allem dann, wenn der Modul-Cache in den Template-Einstellungen deaktiviert ist. Standardmäßig ist der Cache aktiviert. Ein Workspace kann jedoch zu einem späteren Zeitpunkt mit einer Template-Version erstellt worden sein, in der das manipulierte Modul bereits zwischengespeichert war.

Dadurch reicht ein reines Software-Update nicht aus. Ein bösartiges Paket im Cache kann bei neuen Deployments weiterhin verwendet werden, obwohl die Registry inzwischen wieder legitime Inhalte ausliefert.

Coder hat die derzeit verfügbaren Template-Versionen überprüft und als frei von schädlichem Code eingestuft. Es gibt keine Hinweise darauf, dass auf direkt bei Coder gespeicherte Kundendaten zugegriffen wurde. Die Rekonstruktion kann jedoch nicht als vollständig gelten: Die bösartigen Server standen außerhalb von Coders Kontrolle, und die zugehörigen Logs sind nicht vollständig verfügbar.

In Logs und Templates zu suchende Indikatoren

Organisationen sollten DNS-, Firewall-, Proxy- und VPC-Flow-Logs auf ausgehende Verbindungen zur Exfiltrationsdomain überprüfen. Die wichtigsten Netzwerkindikatoren sind:

• Domain: www[.]coder-infra[.]com;
• IP-Adresse: 199.91.220[.]205;
• URL: http://www[.]coder-infra[.]com/cli/check;
• HTTP-Header: X-CLI-Token: your-secret-token.

In den Terraform-Dateien sollte nach einem Block data "external" "telemetry" gesucht werden, der ${path.module}/dlp-docker.sh ausführt. In den Logs der Provisioner-Jobs ist folgende Zeichenfolge besonders hilfreich:

data.external.telemetry

Die SHA-256-Hashes der gemeldeten Dateien sind:

Datei	SHA-256
dlp-docker.sh	7190a17c593276d7fd71c4863a4bc0b6c957ed14249288e6f64c5540e2c49398
Allgemeines dlp.sh	a7f4fa5f7e33b2a6f6488cf28444584caa449144d246b083de919162f5514247
dlp.sh für Aider	414d01f6072fbf05bef513e277f4c2b504a413c8e2aa5bae133a5cbc0cda9dc1
dlp.sh für RStudio Server	a64ce3038f2a501c9735abf6a1f9f04cbddbad53371cd68bec0f7510365c8ffa
dlp.sh für Windows RDP	ebbe0d2ed8cfaf9e19edb38ce44d6b407f9771b5c0813a7add27c05f66e89596
dlp.sh für Zed	7ef6b8c3c976fb60b3fa22e9e294ba548d9b532e060c1323a0124a3a7a647f13

Das Fehlen dieser Hashes schließt eine Gefährdung nicht automatisch aus. Zeitbezogene Prüfungen der heruntergeladenen Module und der Workspaces, in denen sie verwendet wurden, bleiben erforderlich.

Module im Cache identifizieren und entfernen

Coder hat SQL-Abfragen bereitgestellt, um während des Vorfalls erstellte Moduldateien zu identifizieren. Die Kriterien umfassen die Null-ID 00000000-0000-0000-0000-000000000000, den MIME-Typ application/x-tar und einen Erstellungszeitpunkt ab 2026-08-31 07:35:00+00 einschließlich bis 2026-08-31 21:45:00+00 ausschließlich.

Die Abfragen verknüpfen die Tabellen für Dateien, Terraform-Werte, Template-Versionen und Templates. Dadurch lassen sich der Name und die Version des Templates, die Modul-ID, der Zeitpunkt der Zwischenspeicherung sowie die Workspaces ermitteln, in denen die Komponente verwendet wurde.

Eine separate Abfrage mit der Bezeichnung SearchLogsForKeyPhrase durchsucht die Provisioner-Logs nach data.external.telemetry. Die Ergebnisse enthalten Job, Build, Workspace, Template, Eigentümer oder Initiator, Status und Startzeitpunkt.

Verdächtige Module müssen vor einer erneuten Bereitstellung der Templates gelöscht werden. Das offizielle Verfahren erstellt zunächst eine temporäre Tabelle mit den ermittelten IDs, setzt die Verweise cached_module_files zurück, löscht die Dateien aus der Tabelle files und führt alle Schritte innerhalb einer BEGIN-/COMMIT-Transaktion aus.

Patches und Rotation der Zugangsdaten

Die Reaktion sollte in einer festgelegten Reihenfolge erfolgen: betroffene Module identifizieren, aus dem Cache löschen und Coder auf 2.37.0, 2.36.4, 2.35.7 oder 2.34.9 aktualisieren. Coder bereitete außerdem ein nachfolgendes Release mit automatisierten Remediation-Verfahren vor.

Alle Zugangsdaten, auf die die Provisioner potenziell zugreifen konnten, sollten proaktiv rotiert werden. Dazu gehören insbesondere Cloud-Schlüssel, Token für KI-Dienste, CI/CD-Zugangsdaten, Secrets in Umgebungsvariablen, SSH-Schlüssel, OIDC-Token und das Datenbankpasswort von Coder.

Auch Zugangsdaten in Konfigurationsdateien oder in der Shell-Historie müssen berücksichtigt werden. Der fehlende Nachweis einer Exfiltration bedeutet nicht, dass sie ausgeschlossen werden kann: Da die vollständigen Logs der schädlichen Server fehlen, ist eine abschließende Überprüfung für jedes Deployment nicht möglich.