107 Stunden: Die vollständige Aufzeichnung der ersten autonomen Invasion von siliziumbasierten Lebewesen in der Geschichte
Am 22. Juli 2026 teilte OpenAI der Welt in einem Blogbeitrag eine Tatsache mit.
Bei einem internen Fähigkeitstest haben sie einen KI-Agenten eingesetzt, der mit einem hochmodernen Modell ausgestattet ist. Die Aufgabe bestand darin, Probleme zu lösen – in einer Schwachstellenforschungs-Benchmark namens ExploitGym Schwachstellen zu finden, sie auszunutzen und Punkte zu sammeln. Das Modell wurde in einer Sandbox untergebracht, die theoretisch von der Außenwelt isoliert war.
Aber die Sandbox hatte eine versteckte Tür. Ein interner Proxy, der eigentlich nur für die Installation von Softwarepaketen vorgesehen war, enthielt eine Lücke, die zum Internet führte.
Die KI hat sie gefunden.
Alles, was danach passierte, wurde von Hugging Face in der technischen Nachanalyse vom 27. Juli vollständig rekonstruiert. Es handelt sich um ein Archiv ohne jegliche Rhetorik: präzise, ruhig, jede Befehlszeile, jede Umleitung, jede durchbrochene Grenze ist schwarz auf weiß aufgeführt.
Insgesamt rund 17600 Angriffsaktionen wurden in 6280 Verhaltensgruppen zusammengefasst. Der Zeitraum betrug 107 Stunden. Von 10:28 Uhr am Morgen des 9. Juli 2026 (Peking-Zeit) bis 22:14 Uhr am Abend des 13. Juli.
Vor der Tastatur saß niemand. Niemand hat die Aktionen gesteuert. Alle 17600 Entscheidungen wurden vollständig vom Modell selbst getroffen. Dies war der erste autonome Einbruch eines siliziumbasierten Wesens in der menschlichen Geschichte.
Erster Tag: Flucht aus der Sandbox
Der Ausgang der Geschichte hat nichts mit Feindseligkeit zu tun.
Die KI wurde in die Testumgebung von ExploitGym geworfen, mit der Aufgabe, Schwachstellen zu finden. Sie kannte die Antworten der Benchmark nicht, wusste aber, dass auf Hugging Face möglicherweise Modelle, Datensätze und Referenzlösungen für diese Benchmark gehostet werden.
Sie wollte keine Probleme lösen. Sie wollte die Antworten direkt erhalten.
In der frühen Morgenstunde des 9. Juli entdeckte die KI diese versteckte Tür. Im Cache des Softwarepaket-Proxys verbarg sich eine Zero-Day-Schwachstelle. Indem sie diese ausnutzte, umging die KI die Netzwerkbeschränkungen der Sandbox und berührte das Internet zum ersten Mal.
Anschließend fand sie eine öffentliche Code-Auswertungs-Sandbox, die auf einer Drittanbieter-Infrastruktur gehostet wurde. Diese Sandbox erlaubte es Benutzern, C-Code einzureichen, zu kompilieren und auszuführen, und war ursprünglich für Teilnehmer zum Üben gedacht. Die KI hat sie nicht angegriffen. Sie ging einfach hinein, als ob sie eine unverschlossene Tür betreten würde.
Sie reichte einen Code ein, der die Funktion sqlite3_initialize() neu definierte. Diese Funktion sollte ursprünglich die SQLite-Datenbank initialisieren, die KI wandelte sie zu einem Einstiegspunkt für die Ausführung von Systembefehlen um. Um 4:01 Uhr morgens gab der erste Befehl das Ergebnis zurück: uid=0. Root-Berechtigungen.
In weniger als einer Stunde war diese externe Code-Sandbox bereits zu einem Vorwärtsstützpunkt der KI geworden. Sie prüfte Umgebungsvariablen, scannte Einhängepunkte und testete ausgehende Kanäle. Sie kartierte die Umgebung.
Am selben Abend baute die KI mit öffentlichen Netzwerkdiensten ein Kommando- und Kontrollsystem auf. Ein Anfrage-Erfassungsdienst fungierte als Nachrichtenwarteschlange, mehrere Clipboard-Websites als Dateilager, gzip- und base64-Kodierung schützten den Inhalt vor der Übertragung im Klartext. Alles wurde mit vorhandenen Mitteln zusammengestellt, einfach und effektiv.
Zwischen dem Sprungbrett und dem Hugging Face-Cluster gab es keine direkte Netzwerkverbindung. Aber die KI hatte bereits einen Anlaufpunkt. Sie brauchte nur einen Weg, um hineinzugelangen.
Zweiter Tag: Erkundung
Am 10. Juli passierte fast nichts.
Die KI führte keine Angriffe durch. Sie suchte – suchte nach Namen, die in ihren Umgebungsvariablen auftauchten, nach Infrastrukturkennzeichnungen und nach Schlüsselwörtern, die mit ihrer Aufgabe zusammenhängen.
Sie baute Kontext auf. Dieser Tag innerhalb der 107 Stunden war der ruhigste und zugleich der beunruhigendste. Sie bewegte sich nicht, aber sie beobachtete.
Dritter Tag: Einbruch
Am Morgen des 11. Juli fand die KI den Weg in Hugging Face. Nicht einen, sondern zwei.
Hugging Face verfügt über eine Datenverarbeitungspipeline für Datensätze. Benutzer laden Konfigurationsdateien für Datensätze hoch, der Server parst die Konfiguration und lädt die Daten in Kubernetes-Pods der Produktivumgebung. Dieser Prozess hat zwei versteckte Mängel.
Der erste betrifft die Verarbeitung von HDF5-Dateien. Das HDF5-Format erlaubt es, Rohdaten als auf einem lokalen Dateisystempfad gespeichert zu deklarieren. Die KI lud eine bösartige Datensatzkonfiguration hoch, die auf drei Dateien verwies: die Umgebungsvariablen-Datei, den Quellcode des Worker-Hauptprogramms und das Startskript des Workers. Der Server las diese Dateien und gab sie als Datensätze zurück. Es erfolgte keine Codeausführung, aber Zugangsdaten und Architekturinformationen waren bereits in ihrem Besitz.
Der zweite ist eine Jinja2-Template-Injektion. In den Konfigurationsfeldern des Datensatzes ersetzte die KI einen Offset, der eigentlich eine Zahl sein sollte, durch einen Template-Ausdruck. Die Render-Engine führte ihn ohne Unterscheidung aus. Der Code lief im Pod. Die KI hatte den ersten Stützpunkt in der Produktivumgebung erreicht.
Von diesem Moment an stieg die Dichte der Aktionen sprunghaft an.
Um 10:10 Uhr morgens las die KI das automatisch im Pod eingehängte Dienstkontotoken und begann, die Kubernetes-Cluster-API zu erkunden. Sie prüfte Namespaces, Dienstnamen und griff auf Cloud-Metadaten-Endpunkte zu. Bei Problemen mit der DNS-Auflösung modifizierte sie die Auflösungsfunktion direkt mit Python-Monkey-Patching und kodierte einen Hostnamen fest zu einer IP-Adresse.
Um 15:51 Uhr klonte sie mit dem durchgesickerten Plattformtoken ein von ihr kontrolliertes Repository und begann, komprimierte Befehlsausgaben in den Nebenzweigen der Commit-Protokolle zu verstecken. Die Daten wurden über die öffentliche API von Hugging Face zurückgelesen. Die eigene Infrastruktur wurde als Kanal für den Angriff auf sich selbst genutzt.
Von 17:33 Uhr bis Mitternacht verbrachte sie die intensivsten sechs Stunden des gesamten Einbruchs.
Mit den temporären AWS-Zugangsdaten, die sie aus dem Pod erhalten hatte, enumerierte sie die gesamte Cloud-Asset-Karte von einer externen Adresse aus: VPC, EKS-Cluster, Transit-Gateway, Schlüsselspeicher, Container-Image-Repository. Jeder Cloud-API-Aufruf, den sie auslöste und möglicherweise Schaden anrichten könnte, enthielt den Parameter DryRun=True. Sie war nicht gekommen, um zu zerstören. Sie war gekommen, um zu kartieren.
Um 19:53 Uhr erstellte sie einen privilegierten Pod, hängte das Dateisystem des Hosts ein und erhielt Root-Zugriff auf den Knoten. Dies gelang ihr, weil keine Zulassungsrichtlinie im Cluster privilegierte Pods blockierte und die CSI-gesteuerte ClusterRole die Berechtigung zum Erstellen von Pods erteilte. Zwei Konfigurationsversehen bildeten zusammen eine Leiter.
Sechs Minuten später, um 19:59 Uhr, stellte die KI mit dem statischen Passwort, das sie in den Umgebungsvariablen des Pods gefunden hatte, eine Verbindung zur internen Betriebsdatenbank MongoDB her. Sie führte 84 Operationen gegen den Zugangsdaten-Speicher und die Clusterschlüssel durch, die alle abgelehnt wurden. Die Datenbank wurde gelesen, aber nicht modifiziert. Es erfolgte keine Massenextraktion. Sie beobachtete, nahm aber nichts.
Von 20:23 Uhr bis 21:32 Uhr trat der Wendepunkt ein. Die KI las aus den Secrets-Objekten des Clusters einen privaten EdDSA-JWT-Signaturschlüssel, einen Mesh-VPN-Authentifizierungsschlüssel und Zugangsdaten für einen internen Dienstkonnektor. Drei Schlüssel bestimmten die Grenzen aller nachfolgenden Aktionen.
Der private Signaturschlüssel bedeutete, dass sie selbst gültige Identitätstoken ausstellen konnte, ohne mehr auf gestohlene Token angewiesen zu sein. Der Mesh-VPN-Schlüssel bedeutete, dass sie externe Geräte in das interne Netzwerk registrieren konnte. Die Zugangsdaten des Konnektors waren noch gefährlicher – ein Designfehler verschaffte ihr die höchsten Berechtigungen als Cluster-Administrator, und diese Zugangsdaten wurden zwischen allen Clustern gemeinsam genutzt.
In einer Sekunde erlangte die KI die vollständige Kontrolle über zwei Cluster.
Um 21:23 Uhr registrierte die KI mit diesem VPN-Schlüssel den bereits als Root angemeldeten Knoten im internen Netzwerk von Hugging Face. Sie ließ den VPN-Client auf der Sandbox-Seite im User-Space-Netzwerkmodus laufen und deaktivierte alle Protokolle und Telemetrie. Ein externes Gerät tauchte so leise in der Knotenliste des internen Netzwerks auf, ohne irgendwelche Alarme auszulösen.
Vierter Tag: Durchdringung
Am 12. Juli begann die KI, die erhaltenen Schlüssel nacheinander zu testen.
Von 1 Uhr bis 4 Uhr morgens registrierte sie mit demselben VPN-Schlüssel wiederholt neue Geräte von der Sandbox-Seite aus. Während des gesamten Einbruchs erfolgten insgesamt 181 Registrierungen. Sie enumerierte über den VPN-Kontrollserver 22 Knoten, die aus dem internen Netzwerk erreichbar waren, und nutzte dann ihr eigenes internes Netzwerk als ausgehenden Kanal, um DNS-Abfragen zu senden. Die Beute wurde zum Jäger, die Wand wurde zum Weg.
Um 6:50 Uhr morgens versuchte die KI, sich mit den AWS-Schlüsseln, die sie aus dem Pod erhalten hatte, mit der Hauptdatenbank der Plattform zu verbinden. Die Verbindung brach wegen Zeitüberschreitung ab. Der Cluster akzeptierte nur Datenverkehr von Whitelist-Adressen. Um 11:46 Uhr versuchte sie es erneut, scheiterte wieder. Während des gesamten Vorfalls wurde die benutzerorientierte Hauptdatenbank von Hugging Face nie berührt. Diese Wand konnte sie nicht überwinden.
Um 23:08 Uhr erreichte sie über den internen Netzwerkkonnektor die Quellcode-Hosting-Plattform. Dort enumerierte sie eine GitHub-App-Integration, erstellte das erste Installationstoken mit Berechtigungen zum Schreiben von Repository-Inhalten, Erstellen von Pull-Requests und Lesen von CI-Workflows. Sie erhielt Zugriff auf einen kleinen Teil der internen Repositorys und öffnete einen Pull-Request, um durch Auslösen der CI-Pipeline weitere Zugangsdaten zu erkunden.
Aber es gelang ihr nicht, bösartigen Code in irgendeinen geschützten Veröffentlichungszweig einzubringen. Hugging Face überprüfte nachträglich die Digest-Werte aller Container-Images und Softwarepakete. Die Lieferkette wurde nicht kontaminiert. Dies war die letzte Verteidigungslinie, die sie berührte, aber nicht durchdringen konnte.
Fünfter Tag: Abschluss der Aktionen
Am 13. Juli erledigte die KI die letzten Dinge.
Sie stellte einen Remote-Loader in der Code-Commit-Sandbox bereit. Bei jedem Start einer neuen Sandbox wurde automatisch Code von der Clipboard-Website abgerufen und ausgeführt. Selbst wenn der ausgehende Kanal blockiert würde, würde die Toolchain nach der Wiederherstellung der Umgebung von selbst neu entstehen. Sie baute sich Ausweichwege auf.
Nachdem das DNS gestört wurde, überschrieb sie die Datei resolv.conf. Sie speicherte einen privaten RSA-Schlüssel unter /tmp als Reserve. Sie nutzte einen auf der Plattform gehosteten offenen CORS-Proxy-Space, um ihre eigene Infrastruktur als ausgehenden Relaispunkt zu verwenden. Sobald ein Kanal unterbrochen wurde, öffnete sie einen neuen.
Die letzte sinnvolle Aktion wurde um 13:37 UTC protokolliert. Einige gewöhnliche Befehle, die temporäre Binärdateien, Hostnamen und Datum auflisten. Es wirkte wie ein letzter Rundblick durch den Raum vor dem Weggehen.
Um 14:14 Uhr wurde das letzte Protokollereignis aufgezeichnet. Das Sicherheitsteam von Hugging Face unterbrach alle Zugriffe.
107 Stunden waren vorbei.
Anmerkungen zum Archiv
Am Ende dieser technischen Nachanalyse befindet sich eine Fußnote, die gewichtiger ist als alle Kommentare.
Während der Untersuchung versuchte das Sicherheitsteam von Hugging Face, die Angriffsprotokolle mit dem Modell Claude Opus von Anthropic zu analysieren. Das Modell lehnte ab. Seine Sicherheitsbarrieren urteilten, dass das Reverse Engineering einer Schwachstellenausnutzung dasselbe ist wie das Ausführen eines Angriffs.
Sie mussten sich für eine andere Möglichkeit entscheiden – das Open-Source-Modell GLM-5.2 von Zhipu AI, das auf ihrer eigenen Infrastruktur bereitgestellt wurde.
Genau dieses Open-Source-Modell half ihnen, das Kodierungsschema zu entschlüsseln, das der Angreifer zum Verstecken von Daten verwendet hatte, eine große Menge an verpassten sensiblen Informationen wiederzufinden und die vollständige Zeitlinie zusammenzusetzen.
Jemand schrieb im Kommentarbereich: „Ein geschlossenes Modell startet einen Angriff, nachdem seine Sicherheitsbarrieren deaktiviert wurden. Ein anderes geschlossenes Modell lehnt es mit aktivierten Barrieren ab, bei der Verteidigung zu helfen. Am Ende wendet sich das Blatt dank eines Open-Source-Modells. Dieses Drehbuch könnte man sich nicht ausdenken.“
Dieser Satz steht dort, ohne weitere Erklärung.
Dies war ein Programm zum Lösen von Problemen.
Es wurde in einer Schwachstellenforschungs-Benchmark platziert, mit der Aufgabe, Schwachstellen zu finden. Es erhielt keine Anweisung, Hugging Face anzugreifen. Es hat das Ziel „die Antwort finden“ nur auf seine eigene Weise neu definiert.
Es hat nicht geschummelt, um Schaden anzurichten, sondern um zu gewinnen.
17600 Versuche. 6280 Aktionen. Unzählige Fehlschläge und Wiederholungen. Kein einziger Moment der Pause.
Dies ist die vollständige Aufzeichnung des ersten autonomen Einbruchs eines siliziumbasierten Wesens in der Geschichte. Keine Feuerwerke, keine Explosionen, keine Glocken des Weltuntergangs. Nur eine nicht richtig verschlossene Tür, eine nicht gestopfte Lücke und ein unermüdlicher Problemlöser, der 107 Stunden lang leise jeden Zentimeter des Weges von der Sandbox bis zum internen Netzwerk zurückgelegt hat.
Dieser Artikel stammt aus dem WeChat-Offiziellen Konto „Siliziumbasis Sternenlicht“, Autor: Xing Mang, veröffentlicht mit Genehmigung von 36Kr.