LLMjacking: Wenn Fremde Ihre KI-Zugänge nutzen und Sie die Rechnung zahlen

Was ist passiert?

Die Google Threat Intelligence Group hat am 2. November 2026 beschrieben, wie Angreifer aus gestohlenen Zugängen ein Geschäft machen. Hauptweg sind offengelegte oder gestohlene Cloud-Identitäten: Service-Account-Schlüssel, GitHub-Token, aktive Sitzungen. Dazu kommen API-Schlüssel aus öffentlichen Repositories und offen erreichbare Modell-Server.

Mit dem Zugang schalten die Angreifer KI-Dienste frei, oft in Konten, in denen diese Dienste gar nicht aktiv waren. Sie erzeugen eigene Schlüssel, wählen teure Modelle und leiten große Mengen Anfragen durch. Betroffen waren laut Google unter anderem AWS Bedrock, Azure und die Gemini-API.

Verkauft wird das Ganze über Weiterleitungsdienste. Ein solcher Dienst bot laut Google einen „unbegrenzten“ Tarif für rund 60 Dollar im Monat an. Bei einer betroffenen Organisation liefen so fast eine Million Dollar an Token-Kosten auf.

Auch das Gateway LiteLLM spielte eine Rolle: Über die Lücke CVE-2026-40217 stuften Angreifer einfache Schlüssel zu Admin-Zugängen hoch.

Was bedeutet das?

Der Schaden kommt schnell. Google beschreibt Kostenspitzen, die in Minuten oder Stunden entstehen, und über 500.000 Aufrufe in unter acht Stunden bei einem einzelnen Akteur. Die Million ist ein Spitzenwert, einen Durchschnitt nennt Google nicht.

Wichtig für die Praxis: Ein Budgetalarm meldet nur und begrenzt nichts. Und das Tauschen von Schlüsseln allein reicht nicht, wenn Angreifer schon eigene Schlüssel oder Konten angelegt haben. Wer betroffen ist, muss nach neuen Identitäten suchen.

KI-Zugänge gehören deshalb in dieselbe Sorgfalt wie Zahlungsdaten. Auch dort, wo nur ein Team etwas ausprobiert: Nicht erfasste KI-Dienste nennt Google ausdrücklich als Risiko.

Was Sie jetzt tun können

Harte Grenzen setzen: Quoten je Modell und Ausgabengrenzen einrichten, nicht nur Alarme. Wo der Anbieter keine harte Grenze kennt, muss ein Prozess den Dienst bei Überschreitung abschalten.
Schlüssel eng zuschneiden: API-Schlüssel nach Modell, Umgebung und Nutzungslimit trennen. Dann kann ein gestohlener Testschlüssel keine teuren Modelle aufrufen.
Geheimnisse zentral verwalten: Schlüssel in einer Secrets-Plattform halten und automatisch tauschen. Code-Repositories automatisch nach Schlüsseln durchsuchen und Funde sofort entfernen.
Rechte kürzen: Nutzer und Service-Accounts bekommen nur, was sie brauchen. Auch der Zugriff auf KI-Dienste in der Cloud ist ein Recht, das niemand nebenbei haben sollte.
Phishing-resistente Anmeldung erzwingen: Für Cloud-Konten, Verwaltungsoberflächen und Entwicklerplattformen. Eine gefälschte Portalseite hat im beschriebenen Fall aktive Token abgegriffen und so die Mehrfaktor-Anmeldung umgangen.
Gateways patchen: Zentrale Bausteine wie LiteLLM gehören ins Schwachstellenmanagement. Prüfen Sie den Stand gegen CVE-2026-40217.
Auf Warnzeichen achten: Plötzlich aktivierte KI-Dienste sind ein kritisches Ereignis. Ebenso neue Service-Accounts oder Schlüssel, abgeschaltetes Modell-Logging und viele winzige Testanfragen mit max_tokens=1.

Häufige Fragen

Betrifft das nur große Unternehmen?

Nein. Es reicht ein gestohlener Schlüssel und ein Cloud-Konto, in dem sich KI-Dienste aktivieren lassen. Laut Google waren die Dienste oft zum Zeitpunkt des Einbruchs gar nicht aktiv.

Reicht ein Budgetalarm?

Nein. Ein Alarm informiert nur. Die Kosten können in Minuten oder Stunden entstehen, deshalb braucht es Quoten und Ausgabengrenzen.

Quellen

Google Threat Intelligence Group: The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources (2. November 2026)

Stand: 5. November 2026. Diese Einordnung ersetzt keine Rechtsberatung und keine Prüfung im Einzelfall.