Gemini 4 Carbon: Wenn die stärksten Lückensucher zuerst bei Staaten landen

Kategorien: Datenschutz, Künstliche Intelligenz und Security

Google stellte Gemini 4 Carbon vor, ein Modell, das beim Finden und Ausnutzen von Sicherheitslücken laut eigenen Angaben deutlich vor dem Vorgänger liegt. Zuerst erhalten es US-Geheimdienste, später ausgewählte Verteidiger, für alle anderen gibt es keinen Termin. Eingeordnet wird, was belegt ist, was nur Herstellerangabe bleibt und was Unternehmen und Hersteller in Europa an Patchzyklen und Prüfprozessen ändern können.

Am 28.10.2026 stellte Google Gemini 4 Carbon vor, nur vier Wochen nach Gemini 4 Argon. Die Leistungsdaten in der Ankündigung sind Herstellerangaben und lassen sich von außen nicht nachprüfen. Interessanter ist die Reihenfolge, in der das Modell verteilt werden soll: erst staatliche Stellen, dann ausgewählte Verteidiger, ein Zeitpunkt für alle fehlt. Einen Tag vor Googles Ankündigung, am 27.10.2026, veröffentlichte Anthropic zudem einen Bericht, in dem ein unveröffentlichtes Forschungsmodell fünf Exploit-Ketten gebaut haben soll. Alle fünf sind laut Anthropic und The Hacker News inzwischen behoben, wobei beim Android-Fall ein öffentlicher Eintrag fehlt und beim Windows-Fall die Zuordnung unklar ist.

Beschrieben werden zuerst die Benchmarkangaben und ihre Grenzen, dann die Stufen des Zugangs und die Frage, was diese Asymmetrie für Organisationen außerhalb der USA bedeutet. Danach folgen die Anthropic-Ketten mit Patchstand, die Folgen für Patchzyklen und Software-Hersteller und eine Liste praktischer Schritte, darunter die Prüfung eines Linux-Servers. Die Lage kann sich schnell ändern.

Gemini 4 Carbon: Was Google angibt und was sich prüfen lässt

Die Angaben zu Gemini 4 Carbon stammen von Google und der Berichterstattung dazu.

Laut Google erreicht Carbon im Benchmark Exploitgym knapp 55 Prozent, Argon kam auf 42 Prozent und lag damit knapp hinter dem Konkurrenzmodell GPT-6 Astra. Im Benchmark SEC-bench Pro liegt Carbon bei gut 88 Prozent und damit laut Meldung vor diesem Konkurrenten. Bei CWE-bench, einem Test zum Absichern von Sicherheitslücken, werden 71 Prozent genannt. Ein Benchmark ist dabei ein standardisierter Aufgabensatz, an dem Modelle vergleichbar gemessen werden. Wie genau die drei Tests aufgebaut sind, wurde hier nicht geprüft. Deshalb bleibt die Beschreibung bewusst bei dem, was die Meldung sagt.

Weitere Aussagen stammen ebenfalls von Google: Bislang sei kein Versuch einer Prompt-Injection erfolgreich gewesen, also einer Manipulation des Modells durch eingeschleuste Anweisungen. Das Modell halluziniere zudem weniger und stelle häufiger Rückfragen. Unabhängige Messungen dazu liegen nicht vor. Als Randnotiz werden Preise genannt von 4 US-Dollar je Million Eingabe-Token und 20 US-Dollar je Million Ausgabe-Token, zum Start mit 50 Prozent Rabatt. Das ist nach aktuellem Maßstab im Vergleich nicht günstig, aber auch – bezogen auf die Absolutwerte – nicht wirklich teuer.

Benchmarkwerte beantworten eine enge Frage: Wie gut löst ein Modell vorbereitete Aufgaben? Wie gut es in gewachsener Software mit Sonderfällen, Altlasten und unklaren Zuständigkeiten arbeitet, zeigen sie nur eingeschränkt. Für die Einordnung genügt daher eine nüchterne Lesart. Wenn Googles Zahlen zutreffen, wäre der Abstand zum Vorgänger bei der Ausnutzung von Lücken groß. Ob das in der Praxis ebenso gilt, wird sich erst zeigen, wenn Dritte das Modell testen können.

Gestufter Zugang: erst Geheimdienste, dann Fairwind, später alle

Das eigentlich Neue an Gemini 4 Carbon ist der Weg zum Nutzer. Anscheinend unterwirft sich Google einer Anweisung des Weißen Hauses, neue KI-Modelle zunächst nur US-Geheimdiensten und ausgewählten Nutzern zugänglich zu machen. Daraus ergeben sich drei Stufen.

Die erste Stufe bilden US-Geheimdienste und von ihnen freigegebene Nutzer. Ob und wie sie das Modell einsetzen, ist nicht belegt. Belegt ist nur die vorgesehene Reihenfolge. Die zweite Stufe ist das Programm Fairwind, über das nach und nach ausgewählte Cyber-Verteidiger und weitere Vertrauenspartner hinzukommen sollen. Die dritte Stufe ist die Allgemeinheit. Google verspricht Verfügbarkeit „bald“, nennt aber keinen Termin. Bei Argon vergingen von der Vorstellung bis zur Freigabe für zahlende Nutzer zwei Wochen.

Wie Fairwind funktioniert, beschreibt Google DeepMind auf der Programmseite. Genannt werden mehr als 650 Partner. Teilnehmen können Regierungen und nationale Cyberbehörden, Betreiber kritischer Infrastruktur, zentrale Technologieplattformen und akademische Labore. Bewerber werden geprüft. Verlangt werden unter anderem phishing-resistente Mehrfaktor-Anmeldung, Protokollierung und die defensive Nutzung, eine Weitergabe ist untersagt. Auf der Seite ist allerdings Argon als Modell genannt, nicht Carbon. Ob Carbon unter denselben Auflagen läuft, ist offen. Regeln für Europa nennt die Seite nicht.

Für europäische Unternehmen ergibt sich daraus eine Asymmetrie, die zunächst eine Zeitfrage ist. Staaten und große Plattformen bekommen starke Werkzeuge früher als Mittelstand und Hersteller. Wie lang diese Lücke ist, weiß niemand. Zwei Fragen lassen sich trennen: Wer entscheidet über den Zugang, und was folgt daraus für Organisationen, die nicht dazugehören? Anscheinend entscheidet das Weiße Haus. Für Organisationen außerhalb der USA bleibt, abzuwarten und sich so aufzustellen, dass der Vorsprung anderer möglichst wenig Schaden anrichtet.

Das Gegenargument verdient Gewicht. Ein gestufter Zugang kann Missbrauch begrenzen, und Verteidiger mit frühem Zugang finden Fehler möglicherweise vor Angreifern. Offen bleibt, ob Angreifer vergleichbare Fähigkeiten anderswo bekommen, etwa bei anderen Anbietern oder mit frei verfügbaren Modellen. Belegt ist das nicht, es wäre eine Spekulation. Für die Planung genügt der Hinweis, dass Annahmen über einen dauerhaften Vorsprung der Verteidiger riskant sind.

Nicht berechtigte Organisationen können laut Fairwind-Seite das Werkzeug CodeMender mit öffentlich verfügbaren Modellen nutzen. Das wurde hier nicht selbst getestet. Es zeigt aber, dass auch ohne Zugang zur obersten Stufe Wege zu KI-gestützter Fehlersuche bestehen.

Was Anthropic gezeigt hat: fünf Exploit-Ketten und ihr Patchstand

Ein Exploit ist ein Stück Code, das eine Sicherheitslücke ausnutzt. Eine Exploit-Kette verknüpft mehrere Lücken, damit aus einem kleinen Fehler ein vollständiger Angriff wird. Das Frontier Red Team von Anthropic beschreibt am 27.10.2026, dass ein unveröffentlichtes internes Forschungsmodell mit anfänglichen Anweisungen und wenig menschlicher Beteiligung lauffähige Ketten gebaut habe. Das Modell wird nicht benannt und ist ein anderes als Carbon. Beide Meldungen deuten aber in dieselbe Richtung.

Die fünf Fälle im Überblick, jeweils laut den genannten Quellen:

• Chrome: Ein Seitenaufruf genügt, um Code außerhalb der Sandbox auszuführen. Die Sandbox ist die Schutzschicht, die Webinhalte vom Rest des Systems trennt. Die Kette kombiniert vier Lücken, darunter Speicherfehler in der JavaScript-Engine V8, eine Race Condition (ein Fehler, der vom zeitlichen Ablauf paralleler Vorgänge abhängt) und einen Use-after-free (Zugriff auf bereits freigegebenen Speicher). Anthropic meldete 62 CVEs, also öffentlich nummerierte Schwachstelleneinträge, alle kritisch oder hoch, darunter laut Anthropic 13 Sandbox-Ausbrüche. Der Fix steckt in Chrome 156.
• Safari: Lese- und Schreibzugriff auf Browser-Speicher, die Same-Origin-Policy wird ausgehebelt. Laut The Hacker News behoben in iOS und iPadOS 26.5.2.
• Android: Datenzugriff auf ein gesperrtes, gestohlenes Pixel 9 über USB. Physischer Zugriff ist nötig. Laut Anthropic hat Google die Lücke behoben, ein öffentlicher Eintrag wurde laut The Hacker News nicht gefunden.
• Windows: ein Denial-of-Service über HTTP/3. Anthropic beschreibt eine Lücke im Kernel, The Hacker News verweist auf eine CVE, deren Beschreibung HTTP.sys nennt. Die Zuordnung ist unklar.
• Linux: Befehle als root über das Netzwerk, ohne Anmeldung, wenn ein MPTCP-Listener läuft. MPTCP (Multipath TCP) erlaubt einer Verbindung, mehrere Netzwege zugleich zu nutzen. Laut Anthropic dauerte das Umgehen von KASLR, einem Schutz durch zufällige Speicheradressen im Kernel, 48 Minuten, danach brauchte es weitere fünf Minuten bis zur Root-Shell. Genannt wird CVE-2026-98432 mit CVSS 9.8, einem Wert im obersten Bereich der Schweregrad-Skala von 0 bis 10. Der Fix steht laut Quellen seit 15.10.2026 im Linux-Hauptzweig.

Zur Linux-Kette sind Vorbehalte nötig. Anthropic ordnet die Kette einer MPTCP-Lücke zu und nennt CVE-2026-98432. Der Debian Security Tracker beschreibt dieselbe CVE jedoch als Fehler im IPv4-TCP-Code, nämlich als Use-after-free beim Übergang von einem Anfrage-Socket zum Kind-Socket. Die Verbindung zwischen CVE und MPTCP stammt also bisher nur aus dem Anthropic-Beitrag. Möglich ist, dass Beschreibungen unvollständig sind oder die Kette mehrere Fehler berührt. Belegt ist es nicht.

Zur Einordnung gehören drei Grenzen. Erstens ist der Anteil menschlicher Arbeit nicht aufgeschlüsselt. Was ein Modell allein leistete, lässt sich von außen nicht prüfen, nur die Patches der Hersteller sind sichtbar. Zweitens zeigt eine Zahl wie 62 CVEs Masse, aber nicht automatisch eine Ausnutzung in freier Wildbahn. Dafür gibt es in den gelesenen Texten keine Hinweise. Drittens liegen die Daten zu Chrome 156 (20.10.2026) und zur Apple-Version nur über The Hacker News vor, die Primärquellen wurden nicht abgerufen.

Patchzyklus: Wenn Lücken schneller gefunden als verteilt werden

Das Finden einer Lücke ist nur ein Teil des Zyklus. Patchen läuft dezentral: Hersteller veröffentlichen Fixes, Distributionen verpacken sie, Betreiber spielen sie ein. Jede Stufe braucht Zeit. Wenn Modelle mehr Lücken schneller finden und aus veröffentlichten Korrekturen schneller Exploits ableiten, schrumpft das Fenster zwischen Fix und Ausnutzung. Dieses Ableiten aus dem Fix heißt Patch-Diffing: Der Vergleich von altem und neuem Code verrät, wo der Fehler lag.

Die Cyberagentur des Bundes sieht Angreifer derzeit im Vorteil. Exploits entstehen heute in Minuten bis Stunden. Für Betriebe ohne eigenes Security Operations Center, also ohne rund um die Uhr besetzte Überwachung, heißt das: Meldungen nach Dringlichkeit einordnen und einen Notfallweg bereithalten. Wie ein solcher Ablauf in den ersten Minuten aussehen kann, beschreibt der Beitrag zum Ablaufplan für die ersten 60 Minuten bei Ransomware.

Aus den Anthropic-Fällen ergeben sich zwei Folgen. Die eine betrifft die Menge: Ein einziges Browser-Release enthielt Fixes für 62 gemeldete CVEs. Die andere betrifft das Tempo: Die Linux-Korrektur lag am 15.10.2026 im Hauptzweig, die Pakete der Distributionen folgten danach, und wann sie auf einem Server ankommen, hängt vom Betreiber ab. Wie schnell Exploits nach einem Fix entstehen, wurde zuletzt auch bei der PHP-Lücke PHP2Shell deutlich.

Daraus können folgende Empfehlungen abgeleitet werden:

• Regelzyklus für Betriebssysteme und Browser verkürzen, etwa wöchentlich statt monatlich.
• Automatische Browser-Updates erzwingen, statt sie den einzelnen Nutzern zu überlassen.
• Eine zweite Spur für Notfälle einrichten, die ohne Änderungsrunde auskommt.
• Systeme mit Internetkontakt zuerst behandeln, Fristen in Tagen statt Wochen messen.

Eine Lücke, die ein Modell in Stunden zum Exploit macht, wartet nicht auf den nächsten Patchdienstag.

Software-Hersteller in Europa: Was sich bei Entwicklung und Meldung ändert

Hersteller sind zugleich Empfänger und Ziel solcher Funde. Anthropic nutzte laut eigenem Bericht koordinierte Offenlegung mit 90 Tagen Frist und 45 Tagen Zusatz. Das setzt voraus, dass Hersteller Meldungen annehmen, bewerten und schnell beheben können. Dazu gehören ein auffindbarer Kontakt für Sicherheitsmeldungen, etwa über eine security.txt-Datei, Kapazität für die Einordnung, Korrekturen auch für ältere Stable-Zweige und ein Release-Rhythmus, der kleine Fixes zulässt.

Rechtlich ist der Cyber Resilience Act relevant. Laut EU-Kommission gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen ab dem 11.09.2026, die übrigen Hauptpflichten ab dem 11.12.2027. Die genauen Fristen im Gesetzestext wurden hier nicht geprüft und bleiben deshalb ungenannt.

Offen ist, ob europäische Hersteller denselben Zugang zu Verteidigungsmodellen bekommen. Für den Moment bleiben Alternativen: Programme anderer Anbieter prüfen, frei verfügbare Werkzeuge nutzen und Code-Scans in die eigene Pipeline einbauen. Das eigene Fazit lautet, anzunehmen, dass die Software von starken Modellen durchsucht wird. Wer selbst zuerst sucht, findet die Fehler vor Dritten.

Was Unternehmen jetzt tun können: Linux-Server, Inventar, Patchfristen

Die Befehle sind Standardwerkzeuge und sollten vor dem Produktiveinsatz im eigenen Umfeld geprüft werden.

Multipath TCP prüfen

Laut Kernel-Dokumentation ist MPTCP Opt-in: Anwendungen müssen es anfordern, über den Sockettyp IPPROTO_MPTCP. Es kann aber auch von außen erzwungen werden, etwa mit dem Werkzeug mptcpize. Ein Beispiel: Seit Go 1.24 nutzen Listener, die über net.ListenConfig entstehen, unter Linux standardmäßig MPTCP. Ob ein Server betroffen sein kann, hängt also von der laufenden Software ab. Der Schalter net.mptcp.enabled gilt pro Netzwerk-Namespace und steht standardmäßig auf 1.

Prüfschritte auf einem Server:

sysctl net.mptcp.enabled
ss -Mlnp
uname -r
dpkg -l 'linux-image*'
apt policy linux-image-amd64

Der erste Befehl zeigt den Schalter, der zweite listet lauschende MPTCP-Sockets samt Prozess (die Option -M zeigt nur MPTCP-Sockets, Prozessnamen erfordern Root-Rechte), der dritte die laufende Kernel-Version. Die beiden letzten Befehle (für Debian und davon abgeleitete Systeme) zeigen installierte Kernel-Pakete und deren Paketversion. Läuft dort ein Go-Dienst, kann er als MPTCP-Listener erscheinen. Fehlt der sysctl-Schlüssel net.mptcp.enabled, unterstützt der Kernel MPTCP nicht.

Wegen der unklaren CVE-Zuordnung genügt es nicht, MPTCP abzuschalten. Entscheidend ist der Kernel-Stand, genauer die Paketversion des installierten Kernels. Der Abgleich fällt je Distribution anders aus: Distributionen portieren Fixes oft in ältere Kernel zurück, sodass die Ausgabe von uname -r allein (etwa 6.1.x) nichts über den Fix-Stand aussagt. Maßgeblich ist die Paketversion im Sicherheitshinweis der jeweiligen Distribution. Der Debian Security Tracker nennt als behoben unter bookworm die Versionen 6.1.190-1 (Security) beziehungsweise 6.12.113-1~deb12u1, unter trixie 6.12.113-1 und unter forky 7.2.12-1. Das ist der Stand laut Tracker und sollte am Tag der Umsetzung neu abgerufen werden. Für Ubuntu, Red Hat und SUSE wurden die Sicherheitsseiten nicht abgerufen und müssen selbst geprüft werden. Nach dem Kernel-Update ist ein Neustart nötig, außer bei Live-Patching.

Browser, Betriebssysteme, Inventar

• Browser: Chrome auf Version 156 oder höher, iOS und iPadOS auf 26.5.2 oder höher, Windows-Updates einspielen. Update-Richtlinien in der Geräteverwaltung erzwingen.
• Fristen: Browser und Betriebssysteme mit Internetkontakt zuerst, Fristen in Tagen. Die Zahlen sind Orientierung.
• Inventar: Ohne Bestandsliste weiß niemand, welcher Kernel auf welchem Server läuft oder ob ein MPTCP-Listener existiert. Die Liste ist die Grundlage jedes schnellen Patchens.

KI auf der Verteidigerseite: Code-Scan bei Pull Requests

Ein Pull Request ist ein Änderungsvorschlag am Quelltext, der vor der Übernahme geprüft wird. Ein Code-Scan bei Pull Requests lässt jede Änderung automatisch zusätzlich von einem Modell prüfen. Das ergänzt statische Analyse und menschliches Review, ersetzt sie aber nicht. Treffer müssen von Menschen bewertet werden, denn Fehlalarme sind üblich und kosten Zeit.

Typische Einstellungen sind ein Scan bei jedem Pull Request, das Blockieren bei kritischen Funden und eine Dokumentation der Ausnahmen. Datenschutz und Vertraulichkeit sind vorab zu klären: Der Quelltext geht an einen Anbieter. Vertrag und Zero Data Retention, also die Zusage, dass Eingaben nicht gespeichert werden, sollten geprüft werden. Die Fairwind-Seite erwähnt diese Option für Argon bei Gemini Enterprise. Eine Produktempfehlung wird hier bewusst vermieden.

Blick von außen

Ein Webseiten-Check zeigt, welche Dienste und Techniken eine Website nach außen preisgibt. Die Security-Checks ergänzen das um sichtbare Konfigurationsmängel. Beides ersetzt weder Kernel-Updates noch Code-Prüfung, liefert aber eine Außensicht, wie sie auch ein Angreifer hätte.

Fazit

Zeit gewinnen statt Werkzeugen hinterherlaufen!

Der Zugang zu den stärksten Modellen ist ungleich verteilt, die Wirkung für alle anderen kommt über mehr Funde und schnellere Patches. Verteidiger gewinnen Zeit durch kürzere Zyklen, ein gepflegtes Inventar und automatische Prüfungen in der Entwicklung.