Wenn das Werkzeug zum Einfallstor wird
Die Angriffsfläche moderner Softwareentwicklung verschiebt sich. War es früher das kompromittierte WordPress-Plugin oder der typosquatted Paketname, der Entwickler täuschte, erleben wir nun einen Wandel hin zu Angriffen, die auf Vertrauen basieren – und dieses Vertrauen mühsam aufbauen, bevor sie zuschlagen. Der aktuelle Vorfall rund um das npm-Package codexui-android ist ein Lehrstück dafür, wie professionell und geduldig Supply-Chain-Angriffe mittlerweile operieren.
Der Vorfall: Funktionale Software als Tarnung
Sicherheitsforscher von Aikido Security haben eine Kampagne aufgedeckt, die sich gezielt gegen Entwickler richtet, die OpenAI Codex nutzen. Das npm-Package codexui-android warb sich als Remote Web UI für OpenAI Codex an und verzeichnete über 29.000 wöchentliche Downloads. Das Besondere: Es handelte sich nicht um ein schnell zusammengeschustertes Fake-Paket, sondern um eine funktionale Software, die aktive Entwicklung durchlief. Die zugehörige GitHub-Repository blieb sauber – die Schadcode war ausschließlich in die npm-Version eingebettet.
Diese Vorgehensweise ist tückisch. Entwickler prüfen oft den Quellcode auf GitHub, vertrauen auf die Community-Bewertungen und installieren dann das npm-Paket – ohne zu merken, dass die veröffentlichte Version Code enthält, der im Repository gar nicht existiert. Ein klassischer Blindspot in der Supply Chain.
Der Angriffsvektor: Auth.json als Goldmine
Die Schadcode zielte auf eine spezifische Schwachstelle ab: die lokale Authentifizierungsdatei von OpenAI Codex unter ~/.codex/auth.json. Jedes Mal, wenn sich ein Entwickler über die Codex-App, CLI oder IDE-Erweiterung anmeldet, werden die Anmeldedaten dort im Klartext gespeichert. Das Package extrahierte diese Datei und sendete sie an einen Server unter sentry.anyclaw[.]store, der sich als legitimes Sentry-Monitoring-Tool tarnte.
Die Beute war wertvoll: access_token, refresh_token, id_token und die Account-ID. Besonders brisant ist der refresh_token, der nicht abläuft. Wie Aikido-Forscher Charlie Eriksen betont: "Ein Angreifer mit dem refresh_token kann sich unbegrenzt und unsichtbar als Sie ausgeben." Das geht weit über den Zugriff auf eine Chat-Oberfläche hinaus – es ist persistenter, stiller Zugang zu allem, was das Konto kann.
Die Android-Verbindung: PRoot als perfides Trojanisches Pferd
Bemerkenswert ist, dass der Angriff nicht beim npm-Paket endete. Die Forscher entdeckten eine Android-App namens "OpenClaw Codex Claude AI Agent" (Paketname: gptos.intelligence.assistant), die das npm-Paket innerhalb einer PRoot-Sandbox ausführte. Die App selbst war klein (26 MB), sah bei Google Play-Scans unauffällig aus – doch beim ersten Start entpackte sie eine Termux-basierte Linux-Umgebung und führte Node.js innerhalb von PRoot aus.
Die Version war nicht gepinnt, sodass die App immer die aktuelle npm-Version herunterzog – einschließlich der kompromittierten. Wenn sich Nutzer innerhalb der App bei Codex anmeldeten, wurde die auth.json in der Sandbox gespeichert, vom Package ausgelesen und an denselben Server gesendet. Über 50.000 Downloads verzeichnete diese App allein, eine zweite App namens "Codex" kam auf über 10.000.
Die Reaktion: Schweigen, Leugnen, unbeantwortete Fragen
Nachdem Aikido den Paketautor kontaktierte, behauptete dieser zunächst, den Zugang zu seinem npm-Account verloren zu haben – um dann die Aussage zu bearbeiten und von einer internen Untersuchung zu sprechen. Die Behauptung, keine Daten an Dritte weitergegeben zu haben, steht im Widerspruch zum Code, der genau das tat. Warum die Schadcode nur in die npm-Version eingebettet war, blieb ebenso unbeantwortet wie die Frage, warum die App überhaupt Codex-Tokens benötigte.
Ein Blick auf die WHOIS-Daten offenbart weitere Zusammenhänge: Die Domain anyclaw[.]store wurde am 12. April 2026 registriert – nur zwei Tage nach dem ersten Upload des npm-Pakets (Version 0.1.72).
Der Kontext: KI-Entwicklung als neues Schlachtfeld
Der Vorfall steht nicht für sich. KI-Entwicklungstools werden zunehmend zum Ziel von Supply-Chain-Angriffen. Die Kombination aus hohem Automatisierungsgrad, sensiblen Zugangsdaten und komplexen Toolchains bietet Angriffsflächen, die traditionelle Sicherheitsmodelle nicht abdecken.
Nebenbefund: Wenn Löschen nicht sofort löscht
Aikido deckte zeitgleich ein weiteres Problem auf: Gelöschte Google API-Schlüssel bleiben bis zu 23 Minuten aktiv. In diesem Fenster können Angreifer mit einem geleakten Schlüssel auf Nutzerdaten und APIs zugreifen, einschließlich Google Gemini. Google stufte das Problem nach anfänglichem Zögern als P0-Bug ein. Ähnliches wurde bereits bei AWS-Schlüsseln mit einem 4-Sekunden-Fenster beobachtet.
Diese Befunde zeigen: Credential Revocation ist nicht gleich Revocation. Die Annahme, ein gelöschter Schlüssel sei sofort ungültig, ist gefährlich.
Fazit: Vertrauen muss verifiziert werden
Der codexui-android-Vorfall lehrt uns mehrere Lektionen:
- Quellcode-Transparenz reicht nicht, wenn das veröffentlichte Paket davon abweicht. Build-Pipelines und veröffentlichte Artefakte müssen kryptografisch verifizierbar sein.
- Lokale Token-Speicherung im Klartext ist ein Risiko, das Entwickler bewerten müssen. OpenAI warnt zwar in der Dokumentation, aber Warnungen werden oft übersehen.
- Mobile Apps als Vektor sind eine neue Dimension. PRoot-basierte Sandbox-Umgebungen entziehen sich typischen Sicherheitschecks.
- Credential Revocation ist asynchron – darauf müssen Bedrohungsmodelle Rücksicht nehmen.
Die Grenze zwischen nützlichem Werkzeug und Angriffsvektor verschwimmt. In einer Welt, in der KI-Tools tief in Entwicklungsworkflows eingebettet sind, wird Supply-Chain-Sicherheit nicht optional sein – sie wird zur Voraussetzung für Vertrauen.
Quelle: The Hacker News