# Claude half beim Angriff auf OpenAI. Entscheidend sind die gesunkenen Angriffskosten > Aus einem öffentlichen Bild-Upload wurde Zugriff auf ein internes Repository. Entscheidend ist, wie KI die Kosten komplexer Exploits senkt – und welche Architekturkontrollen die Kette trotzdem stoppen. Source: https://mcdougall-digital.de/de/blog/claude-openai-breach-attack-economics/ Published: 2026-09-20 Author: Kyluke McDougall, McDougall Digital Language: de --- „Claude hat OpenAI gehackt“ ist eine unwiderstehliche Schlagzeile. Sie führt aber zur falschen Schlussfolgerung. Bei dem diese Woche veröffentlichten Vorfall handelte es sich um autorisierte Sicherheitsforschung – nicht um ein autonomes Modell, das eigenständig einen anderen KI-Anbieter angreift. Drei Forscher von Hacktron AI nutzten Claude-Modelle, ihre eigene Expertise und einen verantwortungsvollen Offenlegungsprozess, um zwei Schwachstellen zu finden und zu verketten. Nachdem sie die Auswirkungen mit einem harmlosen Pull Request demonstriert hatten, beendeten sie ihre Tests und meldeten die Probleme. Die Kette ist dennoch bemerkenswert: **HEIF-Bild-Upload → Speicherfehler → Codeausführung → SSO-Schwachstelle → Zugriff auf ChatGPT und Codex eines Mitarbeiters → verbundene GitHub-Organisation → interner Pull Request.** Laut Hacktron vergingen von der ersten Entdeckung bis zum Zugriff auf das interne Repository weniger als 72 Stunden. Die umfassendere zweimonatige Forschungskampagne habe weniger als 3.000 US-Dollar an Modell-Tokens gekostet. Die Forscher betonen, dass qualifizierte menschliche Anleitung weiterhin wichtig war. Neuere Modelle hätten jedoch Arbeit komprimiert, die früher deutlich mehr Zeit und seltene Exploit-Expertise erforderte. Das ist die relevante Geschichte für Unternehmen. KI macht bewährte Sicherheitskontrollen nicht überflüssig. Sie verkürzt die Zeit zwischen einer Schwachstelle und einem praktisch nutzbaren Exploit. Unternehmen können technische Komplexität nicht mehr als informellen Sicherheitspuffer betrachten. Für Gründer, CTOs und Produktteams lautet die Antwort nicht, in Panik vor „KI-Hackern“ zu verfallen. Sie sollten die Architekturgrenzen prüfen, durch die ein einziges manipuliertes Bild so weit gelangen konnte. ## Was laut Offenlegung geschah Der technische Bericht von Hacktron beschreibt zwei getrennte Schwachstellen, die zu einem folgenreichen Angriffspfad verbunden wurden. Die erste lag in der Bildverarbeitung. Das öffentliche Community-Forum von OpenAI nutzte Discourse. HEIC- und HEIF-Uploads wurden über ImageMagick verarbeitet, das sich beim Dekodieren auf die native Bibliothek `libheif` stützte. Hacktron zufolge identifizierten die Forscher fehlende Sicherheitskorrekturen in der eingesetzten Bibliothek und entwickelten einen Heap-Buffer-Overflow-Exploit, der während der Bilddekodierung Codeausführung ermöglichte. Diese Problemklasse ist nicht neu. Native Medienparser verarbeiten komplexe, von Angreifern kontrollierbare Binärformate. Daraus sind wiederholt Speichersicherheitslücken entstanden. Neu waren die Kosten, aus dem Fehler einen zuverlässigen Exploit zu machen. Hacktron berichtet, Claude Opus 4.8 habe geholfen, die fehlenden Korrekturen zu identifizieren und einen ersten Exploit zu erstellen. Das Modell habe jedoch Schwierigkeiten gehabt, ihn mit aktivierter ASLR zuverlässig zu machen. Als Claude Opus 5 verfügbar wurde, gaben die Forscher ihm dasselbe Problem. Nach ihrer Darstellung erstellte es innerhalb von etwa drei Stunden einen funktionierenden ARM64-Exploit und half anschließend bei der Anpassung an die x86-64-Umgebung von Discourse. Die zweite Schwachstelle lag in der Identitätsarchitektur. Codeausführung in einem öffentlichen Forum sollte nicht automatisch Zugriff auf die Kernprodukte oder Quellcode-Repositories eines Unternehmens ermöglichen. Das kompromittierte Forum war jedoch Teil eines OpenAI-Identity-Flows. Laut Hacktron erlaubte ein OpenAI-SSO-Problem, aus der Kompromittierung des Forums Zugriff auf das ChatGPT- und Codex-Konto eines Mitarbeiters zu gewinnen. Dieses Konto verfügte über eine verbundene GitHub-Integration. Um die Auswirkungen zu belegen, ohne internen Quellcode zu lesen, ließen die Forscher nach eigener Aussage über das kompromittierte Codex-Konto einen harmlosen Pull Request im internen Monorepo von OpenAI erstellen. Danach beendeten sie die Tests und meldeten die Kette. Hacktron zufolge behob OpenAI das SSO-Problem ungefähr 14 Stunden nach der Meldung. Discourse stellte bis zum folgenden Montag eine Korrektur bereit und ergänzte als zusätzliche Schutzschicht eine Sandbox für die Bildverarbeitung. OpenAI zahlte später eine Prämie von 6.500 US-Dollar für den OpenAI-seitigen Fund. Diese Details korrigieren zwei irreführende Interpretationen. Erstens war dies keine bösartige Angriffskampagne, sondern koordinierte Sicherheitsforschung mit verantwortungsvoller Offenlegung. Zweitens führte Claude den gesamten Angriff nicht selbstständig durch. Menschen wählten das Ziel, steuerten die Modelle, validierten Ergebnisse, trafen Entscheidungen und organisierten die Offenlegung. KI verstärkte fähige Forscher; sie ersetzte sie nicht. ## Der eigentliche Wandel: Exploit-Entwicklung wird wirtschaftlicher Softwareteams konnten sich noch nie seriös darauf berufen, Komplexität sei eine Sicherheitskontrolle. In der Praxis bot Komplexität dennoch einen gewissen Schutz. Ein Speicherfehler in einer unbekannten nativen Abhängigkeit kann öffentlich sichtbar sein. Ihn in einen zuverlässigen Exploit für eine fremde Betriebsumgebung zu verwandeln, erfordert aber häufig Spezialwissen, zielgerichtete Tests und Wochen an Arbeit. Viele Angreifer wählen deshalb billigere Wege: gestohlene Zugangsdaten, offene Administrationsoberflächen, ungepatchte bekannte Schwachstellen oder Social Engineering. KI verändert diese Rechnung. Sie kann unbekannten Code untersuchen, Versionen vergleichen, Testfälle erzeugen, Absturzverhalten analysieren, einen Exploit zwischen Architekturen anpassen und viele parallele Versuche vorantreiben. Ein erfahrener Forscher kann mehr Such- und Anpassungsarbeit delegieren, während Strategie und Validierung unter menschlicher Kontrolle bleiben. Die Zahlen von Hacktron sind Aussagen eines Sicherheitsanbieters, kein allgemeingültiger Benchmark. Die Richtung ist dennoch plausibel: Ein Teil seltener Expertenarbeit lässt sich zunehmend in Modell-Inferenz und Iteration umwandeln. Das verändert Threat Modeling auf drei Arten. ### Mehr Schwachstellen werden die Operationalisierung wert Ein Fehler, dessen Ausnutzung bisher zu aufwendig war, kann wirtschaftlich interessant werden, wenn ein Agent große Teile der Anpassung übernimmt. Die Frage ist nicht mehr nur, ob eine Schwachstelle existiert. Entscheidend ist, wie schnell ein motiviertes Team daraus einen wiederholbaren Angriffspfad gegen die eigene Umgebung machen kann. ### Angreifer können mehr Pfade parallel testen Die veröffentlichte Kampagne umfasste laut Hacktron mehrere Organisationen und Betriebsumgebungen. KI-Unterstützung erleichtert es, unterschiedliche Versionen, Formate, Architekturen und Schutzmaßnahmen zu untersuchen, ohne für jeden Zweig einen eigenen Spezialisten einzusetzen. Verteidiger sollten davon ausgehen, dass auch ungewöhnliche Konfigurationen und weniger verbreitete Abhängigkeitsversionen mehr Aufmerksamkeit erhalten als bisher. ### Die Zeit bis zum Exploit nähert sich der Zeit bis zum Patch Der betroffene Upstream-Code war laut Bericht geändert worden, ohne klar als Sicherheitskorrektur gekennzeichnet oder mit einer CVE versehen zu sein. Dadurch verzögerten sich offenbar Downstream-Backports. Das ist eine gefährliche Lücke. Klassische Patch-Prozesse warten oft auf einen benannten Fehler, einen Schweregrad und ein Hersteller-Advisory. KI-gestützte Forschung kann von einer unauffälligen Codeänderung zu einem funktionierenden Exploit gelangen, bevor diese administrativen Prozesse greifen. ## Ein Bild erreichte zu viele Vertrauensdomänen Der Vorfall lässt sich am besten nicht als eine spektakuläre Schwachstelle analysieren, sondern als Folge fehlender oder unwirksamer Kontrollen. Eine manipulierte Datei erreichte einen nativen Decoder. Der Decoder war nicht ausreichend isoliert. Die Codeausführung fand in einem Dienst statt, der an eine weiterreichende Identitätsgrenze gekoppelt war. Die resultierende Sitzung konnte leistungsfähige KI-Werkzeuge erreichen. Diese Werkzeuge hatten wiederum eine Verbindung zur Quellcodeverwaltung. Keine einzelne Komfortentscheidung erklärt die gesamten Auswirkungen. Die Auswirkungen entstanden durch ihre Kombination. Das ist ein typischer Architekturfehler in ernsthaften Produkten. Teams betrachten Komponenten getrennt: - Das Forum ist „nur eine Community-Seite“. - SSO reduziert Reibung beim Anmelden. - Ein GitHub-Connector macht den Coding Assistant nützlich. - Bildkonvertierung unterstützt Kunden-Uploads. - Eine gemeinsame Mitarbeiteridentität vereinfacht Zugriffe. Jede Entscheidung kann für sich vernünftig wirken. Zusammen entsteht ein Pfad von öffentlicher Eingabe zu interner Autorität. Architekturarbeit bedeutet zu einem großen Teil, diesen Pfad vor einem Angreifer zu erkennen. ## Sieben Kontrollen, die Teams jetzt prüfen sollten Die richtige Reaktion geht über das Update eines Pakets hinaus. ### 1. Parser-Angriffsfläche verkleinern Jedes akzeptierte Dateiformat vergrößert die Angriffsfläche. Wenn ein Produkt HEIF, AVIF, SVG, PDF oder ein anderes komplexes Format nicht benötigt, sollte es dieses nicht nur deshalb verarbeiten, weil eine Bibliothek es unterstützt. Validierung muss den Inhalt prüfen, nicht nur Dateiname oder MIME-Header. Dimensionen, Ebenen, Metadaten, Dekompression und Verarbeitungszeit brauchen enge Grenzen. Nicht vertrauenswürdige Medien sollten am Rand des Systems in ein eng definiertes internes Format konvertiert werden. Das Original gehört danach nicht in vertrauenswürdige Verarbeitungspfade. ### 2. Riskante Verarbeitung sandboxen Teams sollten davon ausgehen, dass Medienparser, Dokumentkonverter und Archivwerkzeuge künftig weitere Speichersicherheitsfehler enthalten werden. Sie sollten außerhalb des Hauptprozesses laufen – ohne Umgebungszugangsdaten, ohne Zugriff auf interne Netzwerke und möglichst mit schreibgeschütztem Dateisystem. Geeignet sind kurzlebige Worker, Ressourcenlimits und eine minimale Systemaufruf- und Paketoberfläche. Ein Parser-Absturz sollte ein isolierter Jobfehler sein, kein Einstiegspunkt in die Anwendung. Die zusätzliche ImageMagick-Sandbox von Discourse ist die dauerhafte Lehre. Ein Patch behebt den heutigen Fehler. Isolation begrenzt den morgigen. ### 3. Abhängigkeiten nach Sicherheitszustand bewerten Der beschriebene `libheif`-Fall zeigt eine schwierige Realität der Software-Lieferkette: Ein Distributionspaket kann eine ältere Versionsnummer mit zurückportierten Korrekturen tragen, während ein neuer wirkendes Paket sicherheitsrelevante Änderungen noch nicht enthält. Teams müssen wissen, welcher gepatchte Zustand tatsächlich läuft. Dazu gehören Betriebssystem-Advisories, neue Base-Image-Builds und transitive native Bibliotheken. Ein Anwendungscontainer kann neu gebaut werden müssen, obwohl sich keine direkte App-Abhängigkeit geändert hat. Eine Stückliste der resultierenden Pakete muss im Incident-Fall zeigen, welche Systeme mit welchem Decoder nicht vertrauenswürdige Dateien verarbeitet haben. ### 4. SSO als Blast-Radius-Entscheidung behandeln Single Sign-on verbessert die Bedienbarkeit und zentralisiert Kontrollen. Es verbindet aber auch Systeme mit sehr unterschiedlicher Exponierung. Ein öffentliches Forum, Support-Portal oder Marketing-Werkzeug sollte nicht automatisch eine Sitzung mit derselben Autorität wie zentrale Engineering-Systeme erhalten. Sinnvoll sind Tokens mit klar begrenzter Zielgruppe, getrennte Clients, kurze Laufzeiten und erneute Authentifizierung für sensible Produkte. Ein für einen Dienst ausgestelltes Token darf nur dann für einen anderen nützlich sein, wenn diese Beziehung ausdrücklich beabsichtigt und getestet ist. Eine direkte Frage hilft: **Welche Mitarbeitersitzungen und verbundenen Systeme werden erreichbar, wenn diese periphere Anwendung vollständig kompromittiert ist?** Das ist die tatsächliche SSO-Grenze. ### 5. KI-Connectoren separat begrenzen Ein KI-Assistent mit Zugriff auf Quellcodeverwaltung, E-Mail, Slack oder Cloud-Werkzeuge kann zu einer mächtigen Brücke werden. Er sollte nicht automatisch alle Berechtigungen des menschlichen Kontos erben. Connectoren brauchen eigene Identitäten, begrenzte Repositories, standardmäßig nur lesenden Zugriff und kurzlebige Zugangsdaten. Schreibaktionen sollten eine Freigabe erfordern. Interne und kundenspezifische Umgebungen müssen getrennt bleiben. Für jede Aktion sollte nachvollziehbar sein, welches Werkzeug sie ausgelöst hat. Der Nutzen eines Agenten entsteht durch hilfreichen Zugriff. Seine Sicherheit entsteht durch begrenzten Zugriff. ### 6. Exploit-Versuche erkennen, nicht nur erfolgreiche Angriffe Hacktron berichtet, während der breiteren Forschung viele Bilder gesendet und Bildprozessoren wiederholt zum Absturz gebracht zu haben, ohne dass dies bei den meisten Zielen sichtbar bemerkt wurde. Wiederholte Decoder-Abstürze, ungewöhnliche Formatkombinationen, Serien fehlerhafter Uploads und ständig neu startende Worker rund um ein Konto sind Sicherheitssignale. Sie sollten zentral erfasst und mit Identitätsereignissen sowie Connector-Nutzung korreliert werden. Auf einen Vorfall in einem öffentlichen Dienst folgende ungewöhnliche Token-Ausstellung, Kontowechsel oder Quellcodeaktivität braucht einen Alarm. Observability muss die Kette verbinden. Fünf getrennte Logs, die niemand gemeinsam auswertet, reichen nicht. ### 7. Anbieterübergreifende Reaktion üben Der demonstrierte Pfad verlief über eine Open-Source-Bibliothek, ein Distributionspaket, ImageMagick, Discourse, einen Identity Provider, ein KI-Produkt und GitHub. Kein einzelner Anbieter besitzt den gesamten Incident. Der eigene Prozess muss den Einstiegspunkt identifizieren, Sitzungen eindämmen, Connectoren deaktivieren, Zugangsdaten rotieren, betroffene Images neu bauen und Beweise sichern können, während verschiedene Lieferanten untersuchen. Zuständigkeiten müssen feststehen, bevor eine Meldung am Sonntagabend eintrifft. ## Was KI verändert – und was nicht KI erhöht offensive und defensive Fähigkeiten. Angreifer können mehr Code prüfen und Exploits schneller anpassen. Verteidiger können mit derselben Werkzeugklasse Abhängigkeiten untersuchen, Parser fuzzing-testen, Abstürze analysieren, Detection-Ideen erzeugen und Kontrollen testen. Der Vorteil entsteht nicht allein durch ein KI-Abonnement. Beide Seiten haben Zugang dazu. Entscheidend ist das Betriebsmodell rund um die Werkzeuge. Ein Unternehmen mit aktuellen Inventaren, isolierter Verarbeitung, begrenzten Identitäten, beobachtbaren Connectoren und geübter Reaktion kann KI nutzen, um die Behebung zu beschleunigen. Ein Unternehmen mit geteilten Zugangsdaten, undurchsichtigen Abhängigkeiten und flachen Vertrauensgrenzen gibt KI-unterstützten Angreifern mehr Hebelwirkung. Die grundlegenden Kontrollen bleiben vertraut: - exponierte Funktionen minimieren; - patchen, was tatsächlich läuft; - riskante Arbeit isolieren; - Identitäten und Zielgruppen trennen; - minimale Berechtigungen vergeben; - den aufgelösten Zustand verifizieren; - Grenzüberschreitungen überwachen; - entlang der gesamten Kette reagieren. KI macht fehlende Kontrollen leichter ausnutzbar. Sie macht vorhandene Kontrollen nicht weniger wirksam. ## Nicht auf „zu schwer auszunutzen“ vertrauen Der wichtigste Satz in Hacktrons Offenlegung ist nicht, dass ein Modell ein anderes übertraf. Entscheidend ist, dass ein kleines, erfahrenes Team eine anspruchsvolle Kampagne laut eigener Darstellung auf wenige Tage und ein überschaubares Token-Budget komprimieren konnte. Technische Schwierigkeit verliert als Schutzfaktor an Wert. Wenn ein System vor allem deshalb sicher ist, weil sein Exploit seltene Expertise und viel Geduld erfordert, schrumpft dieser Sicherheitspuffer. Für ernsthafte Produkte ist die dauerhafte Antwort eine Architektur, die davon ausgeht, dass ein fähiger Angreifer die Schwachstelle irgendwann praktisch nutzbar macht: - Der Parser ist isoliert. - Die Sitzung kann keine Zielgrenzen überschreiten. - Der Connector erreicht nicht alles. - Die Aktion hinterlässt nachvollziehbare Spuren. - Das Incident-Team kann den Zugriff schnell entziehen. Ein einziges hochgeladenes Bild sollte keinen plausiblen Weg zu einem internen Repository haben. Wenn dieser Weg existiert, ist das Problem größer als der Bilddecoder. --- Dieser Beitrag wurde mit Unterstützung von KI erstellt. Verantwortlich für den Inhalt ist McDougall Digital.