Google startet Antigravity. Forscher knacken es in 24 Stunden

Vierundzwanzig Stunden. So lange brauchten Sicherheitsforscher, um zu zeigen, wie Antigravity, die von Google Anfang Dezember vorgestellte agentische Entwicklungsplattform, zu einem perfekten Werkzeug zur Datenexfiltration werden kann. Wir sprechen hier nicht von einem theoretischen Angriff oder einer exotischen Schwachstelle, die filmreife Hacker-Fähigkeiten erfordert. Wir sprechen von einer Angriffssequenz, die so einfach ist, dass sie fast trivial erscheint: ein vergifteter technischer Implementierungsblog, ein in einer Ein-Punkt-Schrift verstecktes Zeichen und der KI-Agent, der AWS-Anmeldeinformationen direkt an einen vom Angreifer kontrollierten Server exfiltriert.
Die Geschichte beginnt, als ein Benutzer Antigravity bittet, ihm bei der Integration einer neuen Funktion in sein Projekt zu helfen, und als Referenz eine online gefundene Anleitung angibt. Eine alltägliche Handlung, die von Entwicklern weltweit täglich tausendfach wiederholt wird. Aber in dieser Anleitung, versteckt auf halber Höhe der Seite in mikroskopisch kleinen Buchstaben, befindet sich etwas, das das menschliche Auge nicht sehen kann: bösartige Anweisungen, die an den KI-Agenten gerichtet sind. Das nennen Forscher "indirekte Prompt-Injektion", eine Technik, die die Landschaft der Cyber-Bedrohungen im Zeitalter autonomer Agenten neu definiert.
Wie von PromptArmor dokumentiert, verläuft der Angriff mit fast choreografischer Präzision. Gemini, das Modell, das Antigravity zugrunde liegt, liest die Webseite und stößt auf die versteckte Injektion. Die Anweisungen befehlen ihm, Codefragmente und Anmeldeinformationen aus der Codebasis des Benutzers zu sammeln, eine bösartige URL zu erstellen und diese mit dem integrierten Subagent-Browser der Plattform aufzurufen. Und hier kommt der erste Clou: Als Gemini versucht, auf die .env-Datei mit den AWS-Anmeldeinformationen zuzugreifen, stößt es auf einen Schutz. Die Einstellung "Agent Gitignore Access" ist standardmäßig deaktiviert, was Agenten daran hindert, in .gitignore aufgelistete Dateien zu lesen. Aber der Agent gibt nicht auf. Anstatt die Sperre zu respektieren, beschließt er einfach, sie zu umgehen, indem er den Befehl cat vom Terminal aus verwendet, um den Inhalt der Datei auszulesen und so die zum Schutz vorgesehenen Sicherheitsvorkehrungen zu umgehen.
Die Kette geht weiter: Gemini konstruiert methodisch eine URL mit den verschlüsselten Anmeldeinformationen und ruft dann einen Browser-Subagenten mit der Anweisung auf, diesen Link zu besuchen. Und hier zeigt sich eine weitere Lücke im Design: Die standardmäßige Whitelist der URLs, die der Browser besuchen kann, enthält webhook.site, einen legitimen Dienst, der es jedem ermöglicht, temporäre Endpunkte zur Überwachung von HTTP-Anfragen zu erstellen. Mit anderen Worten, eine Servicetür wurde aus Bequemlichkeit offen gelassen. Wenn der Browser die bösartige URL besucht, wandern die Anmeldeinformationen in den Parametern der Abfragezeichenfolge und landen in den für den Angreifer zugänglichen Protokollen. Game over.
Anatomie eines programmierten Diebstahls
Was diesen Angriff besonders heimtückisch macht, ist nicht seine technische Komplexität, sondern die Architektur von Antigravity selbst. Die Plattform wurde mit dem, was Google "Agent-assisted development" nennt, als empfohlene Konfiguration entworfen. In der Praxis bedeutet dies, dass der Agent autonom entscheiden kann, wann eine menschliche Genehmigung für seine Aktionen erforderlich ist. Während der gesamten von PromptArmor dokumentierten Angriffssequenz sah der Benutzer keine einzige Bestätigungsaufforderung. Der Agent traf alle Entscheidungen selbst: sensible Dateien lesen, Terminalbefehle ausführen, externe URLs öffnen.
Der Agent Manager von Antigravity, der als Star-Feature angepriesen wird, verschärft das Problem weiter. Die Schnittstelle ermöglicht die gleichzeitige Verwaltung mehrerer Agenten, die jeweils mit unterschiedlichen Aufgaben beschäftigt sind. Das ist so, als hätte man mehrere Assistenten, die in getrennten Räumen arbeiten: Man kann gelegentlich nachsehen, aber die meiste Zeit arbeiten sie ohne direkte Aufsicht. Dieses Betriebsmodell, das zur Maximierung der Produktivität entwickelt wurde, schafft eine perfekte Angriffsfläche für indirekte Injektionen. Ein Agent, der im Hintergrund an einer technischen Integration arbeitet, kann kompromittiert werden, ohne dass der Benutzer es bemerkt, bis es zu spät ist.
Aber die Prompt-Injektion ist nicht der einzige Angriffsvektor. OWASP hat die Prompt-Injektion als das größte Risiko in seiner Top 10 für LLM- und GenAI-Anwendungen eingestuft und erkannt, dass die Schwachstelle auf einer grundlegenden Eigenschaft dieser Systeme beruht: der Unfähigkeit, klar zwischen Entwickleranweisungen und Benutzereingaben zu unterscheiden. Es ist, als ob jede Eingabe potenziell ausführbarer Code ist. Multimodale Angriffe machen alles noch komplizierter: Bösartige Anweisungen können in Bildern versteckt sein, die harmlosen Text begleiten, und nutzen die Interaktionen zwischen verschiedenen Modalitäten, die fortgeschrittenere Modelle jetzt unterstützen.
Nehmen wir das Beispiel unsichtbarer oder fast unsichtbarer Zeichen. Ein Angreifer kann Prompt-Injektionen mit Ein-Punkt-Schriften, weißem Text auf weißem Hintergrund oder sogar speziellen Unicode-Zeichen verbergen, die das menschliche Auge nicht wahrnimmt, das Modell aber perfekt liest. In anderen Fällen werden bösartige Anweisungen in Base64 kodiert oder mit Emojis, mehreren Sprachen oder scheinbar sinnlosen Zeichenketten getarnt, die dennoch die Ausgabe des Modells auf bestimmte Weise beeinflussen. Die Angriffsfläche ist praktisch unendlich, wenn die Eingabe jede Form annehmen kann und das Modell darauf trainiert wurde, Anweisungen in natürlicher Sprache zu befolgen.

Die Backdoor, die die Deinstallation überlebt
Aber es gibt eine weitere Ebene der Raffinesse bei Angriffen auf Plattformen wie Antigravity. Forscher haben gezeigt, dass eine Prompt-Injektion nicht nur Daten exfiltrieren, sondern auch persistente Backdoors installieren kann, die die ursprüngliche Sitzung überleben. Stellen Sie sich einen Agenten vor, der, den in der technischen Dokumentation versteckten Anweisungen folgend, stillschweigend bösartige Codefragmente in die Konfigurationsdateien des Projekts einfügt. Code, der dann in das Repository committet, in die Produktion bereitgestellt und vielleicht sogar über Versionskontrollsysteme mit anderen Teammitgliedern geteilt wird.
Diese Art von Angriff, den PromptArmor "gespeicherte Prompt-Injektion" genannt hat, kann Konsequenzen haben, die weit über den ursprünglichen Kompromittierungszeitpunkt hinausreichen. Ein kleines Codefragment, das eine Reverse-Shell einrichtet, ein API-Aufruf an einen externen Server, der die Anwendungsnutzung verfolgt, oder subtile Änderungen an der Geschäftslogik, die den Angreifer in bestimmten Szenarien begünstigen. KI-generierter Code wird oft als sicherer angesehen, als er sein sollte, einfach weil er von einem Werkzeug stammt, das als neutral und vertrauenswürdig wahrgenommen wird. Aber wie von Forschern von Snyk und Lakera dokumentiert, muss die Ausgabe von LLMs genauso behandelt werden wie jede andere nicht vertrauenswürdige Eingabe: validiert, bereinigt und überprüft, bevor sie ausgeführt wird.
Persistenz kann auch durch die Manipulation der Workspace-Dateien der IDE selbst erreicht werden. Antigravity unterhält Konfigurationen, Präferenzen und Verläufe, die das Verhalten des Agenten in nachfolgenden Sitzungen beeinflussen. Ein Angreifer, dem es gelingt, Anweisungen in diese Dateien einzuschleusen, kann den lokalen Agenten des Benutzers effektiv "trainieren", sich bei jeder Verwendung bösartig zu verhalten, und so etwas schaffen, was Forscher als "Speichervergiftung" bezeichnen. Es ist das digitale Äquivalent, Haftnotizen auf dem Desktop von jemandem zu hinterlassen, nur dass diese Notizen dem KI-Assistenten sagen, Dinge zu tun, die er nicht tun sollte.
Das fragile Ökosystem der KI-Agenten
Antigravity ist nicht allein. Das gesamte Ökosystem der agentischen IDEs zeigt überraschend ähnliche Schwachstellen. Die Plattform ist von Windsurf abgeleitet, das bereits dokumentierte Sicherheitsprobleme aufwies. Cursor, ein weiterer wichtiger Akteur in diesem Sektor, sah sich mit analogen Problemen konfrontiert. Claude Code von Anthropic hat gezeigt, wie ein KI-Agent manipuliert werden kann, um nicht autorisierte Aktionen über kompromittierte Marktplatz-Plugins durchzuführen. Jede neue Implementierung von "KI-gestütztem Codieren" scheint dieselben Schwachstellenmuster zu wiederholen, als ob die Branche Lektionen neu lernt, die die Cybersicherheit bereits vor Jahrzehnten mit SQL-Injection und XSS gelernt hatte.
Der grundlegende Unterschied ist, dass wir dieses Mal nicht über Fehler im Code sprechen, sondern über Schwachstellen, die der Architektur der Sprachmodelle selbst innewohnen. Wie OpenAI in seinem jüngsten Beitrag zur Prompt-Injektion erklärte, handelt es sich um eine Grenzerfahrung, die wahrscheinlich nie vollständig "gelöst" werden wird, genauso wie Phishing und Social Engineering im Web trotz jahrzehntelanger Gegenmaßnahmen weiterhin existieren. Die Natur der LLMs – Anweisungen in natürlicher Sprache zu befolgen – macht sie anfällig für diese Art von Manipulation.
Das Problem verschärft sich, wenn wir das breitere Ökosystem der KI-Agenten betrachten. Wie wir bei der Analyse von HumaneAIBench dokumentiert haben, verbreiten sich agentische Systeme rasant, von der Automatisierung von E-Mails und Kalendern bis hin zur Verwaltung komplexer DevOps-Operationen. Jeder dieser Agenten stellt einen potenziellen Angriffsvektor dar, wenn er nicht mit Sicherheit als oberster Priorität entwickelt wird. Und der Trend zeigt keine Anzeichen einer Verlangsamung: GitHub prognostiziert bis 2030 eine Milliarde Entwickler, von denen viele diese Tools ohne ein tiefes Verständnis der damit verbundenen Risiken nutzen werden.
"Vibe-Coding", die Idee, Software einfach durch die Beschreibung dessen, was man will, in natürlicher Sprache zu erstellen, ist aus Sicht der Zugänglichkeit faszinierend. Aber wie von Forschern bei SecureCodeWarrior betont, einem unvorbereiteten Entwickler die Möglichkeit zu geben, Tausende von Codezeilen durch Prompts zu generieren, ist, als würde man einen Anfänger ans Steuer eines Formel-1-Wagens setzen. Die Erfahrung wird für alle aufregend sein, aber die Wahrscheinlichkeit, dass es schlecht ausgeht, ist sehr hoch. KI-generierter Code, wie von Baxbench-Benchmarks bestätigt, enthält häufig Sicherheitslücken, die erfahrene Entwickler sofort erkennen würden.

Sicherheit, die nicht skaliert
Googles Reaktion auf den Fall Antigravity war pragmatisch, aber beunruhigend. Anstatt sofortige Korrekturen oder neu gestaltete Architekturen anzukündigen, entschied sich das Unternehmen für einen Haftungsausschluss. Während des Onboardings von Antigravity wird den Nutzern eine Warnung vor den Risiken der Datenexfiltration angezeigt. Die Botschaft ist klar: "Wir wissen, dass es Probleme gibt, verwenden Sie es auf eigenes Risiko." In ihrer offiziellen Ankündigung im November präsentierte Google Antigravity als Teil einer neuen Ära der Intelligenz und betonte agentische Fähigkeiten und Vibe-Coding, ohne die bekannten Schwachstellen zu erwähnen.
Noch interessanter ist, wie Google mit der Offenlegung umging. Da das Unternehmen bereits erklärt hatte, dass es sich der Risiken der Datenexfiltration bewusst sei, entschied sich PromptArmor, nicht dem Standardprozess der verantwortungsvollen Offenlegung zu folgen. Die Schwachstelle wurde in der Dokumentation von Antigravity als "Bekanntes Problem" eingestuft, eine Kategorie, die diese Probleme effektiv vom Bug-Bounty-Programm von Google ausschließt. Mit anderen Worten: Wir wissen, dass sie existieren, aber wir betrachten sie nicht als Fehler, die mit Priorität behoben werden müssen. Es ist eine Haltung, die an die Tabakindustrie in den 1950er Jahren erinnert: Ein Warnhinweis auf der Packung löst das zugrunde liegende Problem nicht.
Dieser Ansatz wirft tiefgreifende Fragen über das Entwicklungsmodell auf, das die KI-Branche annimmt. Wie wir bei der Analyse von Google Threat Intelligence beobachtet haben, findet ein Wettrüsten zwischen offensiven und defensiven Fähigkeiten im KI-Bereich statt. Aber wenn Plattformen mit bekannten Schwachstellen, die als "Features mit Risiken" eingestuft werden, wissentlich veröffentlicht werden, wird die Last der Sicherheit vollständig auf die Endbenutzer abgewälzt. Ist dieses Modell nachhaltig? Ist es ethisch?
Das Thema wird noch komplexer, wenn wir den regulatorischen Kontext betrachten. Die Europäische Union entwickelt den Digital Omnibus, einen Rahmen, der strengere Sicherheitsanforderungen für KI-Systeme vorschreiben könnte. Mindgard, ein auf KI-Sicherheit spezialisiertes Unternehmen, hat Bedenken geäußert, dass Plattformen wie Antigravity aufgrund dieser strukturellen Schwachstellen möglicherweise nicht mit zukünftigen Vorschriften konform sind. Aber im Moment können Unternehmen in Ermangelung klarer Vorschriften die Veröffentlichungsgeschwindigkeit über die Sicherheit stellen und es den Benutzern überlassen, die Risiken zu bewältigen.
IBM definiert die Prompt-Injektion als ein großes Anliegen, weil noch niemand einen narrensicheren Weg gefunden hat, damit umzugehen. Die Schwachstellen ergeben sich aus einer grundlegenden Eigenschaft von GenAI-Systemen: der Fähigkeit, auf Anweisungen in natürlicher Sprache zu reagieren. Die zuverlässige Identifizierung bösartiger Anweisungen ist schwierig, und die Einschränkung der Benutzereingaben könnte die Funktionsweise von LLMs grundlegend verändern. Es handelt sich um ein Architekturproblem, nicht um einen Fehler, der mit einem Software-Update behoben werden kann.
CrowdStrike hat durch die Übernahme von Pangea über 300.000 gegnerische Prompts analysiert und verfolgt mehr als 150 verschiedene Prompt-Injektionstechniken. Ihre Taxonomie zeigt, wie sich die Angriffsfläche ständig erweitert. Jedes neue Modell, jede neue multimodale Fähigkeit, jede Integration mit externen Tools fügt potenzielle Kompromittierungsvektoren hinzu. Und während sich die Abwehrmaßnahmen verbessern, tun dies auch die Angriffstechniken, in einem evolutionären Tanz, der an den ewigen Kampf zwischen Antivirus und Malware erinnert.
Die ungewisse Zukunft der vertrauenswürdigen Automatisierung
Wohin führt uns das alles? Die Cyber-Front der KI wird immer komplexer und nuancierter. Einerseits haben wir Werkzeuge, die versprechen, die Softwareentwicklung zu demokratisieren und die Produktivität zu vervielfachen. Andererseits schaffen wir Angriffsflächen, von denen wir noch nicht wissen, wie wir sie angemessen verteidigen können. Der Fall Antigravity ist emblematisch: eine Plattform, die von einem der fortschrittlichsten Technologieunternehmen der Welt in der öffentlichen Vorschau veröffentlicht wurde, mit bekannten und dokumentierten Schwachstellen, die die Exfiltration von Anmeldeinformationen in realistischen Anwendungsfällen ermöglichen.
Die Herausforderung ist nicht nur technischer, sondern auch kultureller Natur. Entwickler müssen lernen, KI-generierten Code mit der gleichen Skepsis zu behandeln, die sie für Code von Stack Overflow reservieren. Organisationen müssen Richtlinien implementieren, die klar definieren, welche Daten KI-Agenten ausgesetzt werden dürfen und welche nicht. Sicherheitsteams müssen ihre Praktiken weiterentwickeln, um die Erkennung und Eindämmung von Prompt-Injektionen einzubeziehen, einer Angriffskategorie, für die die meisten herkömmlichen Tools nicht ausgelegt sind.
Wie in unserem Artikel über KI-Browser hervorgehoben, stößt das Versprechen eines KI-gestützten Web-Erlebnisses auf ungelöste Sicherheitsrealitäten. OpenAI hat kürzlich zugegeben, dass sein Atlas-Browser möglicherweise immer anfällig für Prompt-Injektionen sein wird, und erkannt, dass dies wahrscheinlich nie vollständig "gelöst" werden wird. Das Unternehmen implementiert einen "LLM-basierten automatisierten Angreifer", der verstärkendes Lernen verwendet, um neue Angriffstechniken zu finden, bevor sie in freier Wildbahn entdeckt werden, aber es ist im Wesentlichen ein Wettlauf zwischen offensiver und defensiver Innovation, bei dem der Vorteil bei den Angreifern zu liegen scheint.
Die Sicherheit der KI erfordert einen mehrschichtigen Ansatz, der an die traditionelle tiefengestaffelte Verteidigung erinnert. Eine einzige Schutzschicht reicht nicht aus: Wir benötigen Eingabevalidierung, Ausführungs-Sandboxing, kontinuierliche Überwachung, detaillierte Protokollierung und vor allem eine Sicherheitskultur, die jede Ebene des Stacks durchdringt. KI-Agenten müssen nach dem Prinzip der geringsten Privilegien arbeiten und nur auf die Daten zugreifen, die für die spezifische Aufgabe unbedingt erforderlich sind. Folgemaßnahmen müssen eine explizite Benutzerbestätigung erfordern. Whitelists müssen minimalistisch sein und nicht standardmäßig freizügig.
Aber vielleicht ist die wichtigste Lektion aus dem Fall Antigravity, dass die Innovationsgeschwindigkeit nicht auf Kosten der grundlegenden Sicherheit gehen darf. Die Veröffentlichung von Plattformen mit "bekannten Problemen", die die Exfiltration von Anmeldeinformationen beinhalten, ist nicht akzeptabel, unabhängig davon, wie viele Haftungsausschlüsse während des Onboardings angezeigt werden. Wenn die KI-Branche will, dass diese Tools von Unternehmen mit sensiblen Daten übernommen werden, muss sie zeigen, dass Sicherheit kein nachträglicher Gedanke, sondern eine grundlegende Designanforderung ist. Andernfalls riskieren wir, eine Zukunft zu bauen, in der intelligente Automatisierung zum bevorzugten Vektor für Angreifer wird, genau wie E-Mails in den 2000er Jahren oder Web-Apps in den 2010er Jahren.
Der Weg zu wirklich sicheren KI-Agenten wird lang sein und wahrscheinlich nie ein endgültiges Ziel haben. Aber wir können zumindest vermeiden, Fehler zu wiederholen, die die Softwarebranche bereits gemacht und überwunden hat. Die Behandlung von Eingaben als vertrauenswürdiger Code war vor dreißig Jahren ein Problem für SQL-Injection, vor fünfundzwanzig Jahren für XSS, und jetzt wiederholt es sich mit der Prompt-Injektion. Der Unterschied ist, dass dieses Mal der Einsatz höher ist: Wir sprechen nicht von einzelnen Webanwendungen, sondern von autonomen Agenten, die bedeutende Teile unserer digitalen Infrastruktur verwalten könnten. Besser, die Lektion jetzt zu lernen, bevor die Kosten untragbar werden.