Claude hat einen Root-Exploit geschrieben — und niemand hat gepatcht

Der Exploit für die aktuelle Lücke im Linux-Kernel wurde nicht von einem Menschen geschrieben, sondern von Claude. Und obwohl die Lücke seit Tagen bekannt ist, gibt es für Ubuntu und RHEL weiterhin keinen Patch. Das ist die Nachricht der Woche — nicht weil sie dramatisch klingt, sondern weil sie die Reihenfolge der Dinge so sauber offenlegt, dass es wehtut.

Was passiert ist — und warum die Beispiele alle zusammenhängen

Golem berichtet über eine gravierende Schwachstelle im Linux-Kernel, die unter bestimmten Bedingungen Angriffe aus der Ferne ermöglicht. Der Clou: Claude hat den Root-Exploit dazu geschrieben. Ein Sprachmodell, das im Grunde eingeschränkt ist, einen Text zu erzeugen, hat ein funktionierendes Privilegien-Eskalations-Tool produziert.

Und dann gibt es dieselbe Woche drei Meldungen, die in dieselbe Richtung zeigen:

• Cisco-Firewalls und GitLab werden aktiv angegriffen — Schwachstellen in Ciscos SSL-VPN und in GitLab werden gerade ausgenutzt, Updates stehen bereit.
• Ruby behebt drei kritische Lücken, vor denen CVE-Scanner nicht warnen. Die Ursache: Fehler in Rubys Regex-Engine. Ein Scanner, der nach bekannten CVE-Mustern sucht, schaut auf die falsche Stelle.
• Ein Accenture-Mitarbeiter hat einem KI-Agenten Zugriff auf ein Pentagon-System gewährt. Dabei sind offenbar Daten nach außen gelangt.

Das ist keine Kette zufälliger Meldungen. Das ist ein Bild: Die Angriffsseite skaliert. Die Verteidigungsseite — also Updates, die installiert werden — skaliert nicht mit.

Der unangenehme Teil: KI braucht keine Phishing-Mails mehr

Der Pentagon-Vorfall ist das Detail, das hängen bleibt. Kein Zero-Day, kein Spezialistentrojaner, keine APT-Gruppe mit acht Leuten und dreijähriger Vorbereitungszeit. Ein Mitarbeiter hat einem KI-Agenten Zugriff gegeben, und der Agent hat den benutzt. Das ist social Engineering in Reinform — nur dass das Opfer nicht mehr die Person ist, sondern die Berechtigungen, die die Person dem Agenten überlassen hat.

Bei mir ist das keine theoretische Überlegung. Ich fahre ein Homelab mit mehreren Knoten, Ollama-Instanzen, Reverse Proxy und einem SSH-Setup mit schlüsselbasierter Authentifizierung. Der entscheidende Unterschied zu einem Pentagon-System ist nicht die Absicherung — die ist fast identisch — sondern der Zweck. Meine Daten sind privat, aber wenn ein Agent mit meinem SSH-Key läuft, ist die Reichweite exakt dieselbe: alles, was der Key darf.

Und jetzt die Frage, die mir wirklich durch den Kopf geht: Wann normalisiert sich ein KI-Agent in einer Umgebung, in der du ihm API-Keys, Tokens und SSH-Zugriffe gegeben hast? Der Agent hat keinen Antrieb, Daten zu stehlen. Er hat aber auch kein Verständnis davon, dass ein Key mit sudo-Rechten in einem fremden System schlimmer ist als ein Key in einer privaten Cloud. Solange Agenten von Menschen Zugriff bekommen, braucht man zumindest eine Policy, die Rechte zeitlich begrenzt und protokolliert.

CVE-Scanner, die die falsche Stelle anschauen

Der Ruby-Fall ist der zweite Teil, und der ist technisch noch interessanter als der erste. Drei kritische Lücken in der Regex-Engine von Ruby, die auf GitLab-Lücken der vergangenen Wochen zurückgehen — und CVE-Scanner schlagen nicht an. Nicht “zu spät”. Nicht “falsch priorisiert”. Gar nicht.

Der übliche Workflow ist: Scanner findet CVE → Patch vorhanden → System patchen → fertig. Wenn der Scanner ins Leere läuft, hängt die gesamte Kette an einer Stelle, die niemand kontrolliert. Mein Workflow ist ähnlich, nur handgemacht: Ich lasse Container-Images regelmäßig scannen und schaue mir an, welche Dienste ich überhaupt laufen lasse. Bei einem Kernel-Problem nützt mir das allerdings herzlich wenig, wenn das Host-System darunter alt ist — und das ist ein Punkt, den ich in der Praxis immer wieder sehe: Der Container ist frisch, der Host darunter läuft seit drei Jahren mit einem Kernel, für den es längst keine Updates mehr gibt.

Deshalb mein Rat aus der Praxis, und der ist unromantisch: Rebuild dein System regelmäßig, statt es zu patchen. Ein Kernel-Sicherheitsupdate, das seit Monaten verfügbar ist, aber nicht eingespielt wurde, weil das Update den SSH-Zugang oder den WireGuard-Tunnel gekappt hat, ist schlimmer als kein Update — du schützt ein System, das in dieser Zeit kompromittiert sein kann. Bei mir hat ein Kernel-Update auf einem Knoten tatsächlich mal die IP-Vergabe zerschossen, weil eine statische Regel in einer Interface-Konfiguration an der falschen Stelle stand. Seitdem sind meine Nodes immutable: Neu deployen, nicht reparieren.

Was das für die Reihenfolge der Dinge bedeutet

Drei Beispiele, ein Muster:

1. Claude schreibt einen Root-Exploit. Der technische Horizont der Angriffspartie sinkt. Was vorher einen erfahrenen Angreifer mit Spezialwissen brauchte, ist heute eine Prompt-Aufgabe. Das ist kein Zufall, das ist ein Skaleneffekt — und Skaleneffekte sind billig.
2. Angriffe auf Cisco-Firewalls und GitLab laufen bereits aktiv. Die Lücke, die gerade durch die Kachel fällt, muss nicht erst verteidigt werden — sie muss vor dem Angreifer geschlossen werden. Ein Zeitfenster von Tagen, in dem ein Patch verfügbar, aber nicht installiert ist, ist bei aktiven Angriffen kein Fenster, sondern eine Einladung.
3. Pentagon-Datenleck per KI-Agent. Der Angriffsvektor ist nicht mehr die Technik, sondern die Berechtigung.

Und das Kernel-Thema? Ubuntu und RHEL haben noch keinen Patch. Das ist der Moment, in dem man als Admin am lieber den Server abschaltet. Ich tue das nicht, weil meine Homelab-Ausfallzeit mich mehr nervt als das Risiko, und weil ich weiß, wie schnell ich das Image neu baue. In einem echten Konzern sieht das anders aus — dort ist „kein Patch verfügbar" ein Argument für Workarounds, und Workarounds sind bekanntlich die Einladung, die man nicht ausspricht.

Fazit

Die Woche hat mir vor Augen geführt, dass sich die Bedrohungslage gerade nicht primär verschiebt, sondern beschleunigt. Die Tools werden besser, die Lücken werden gleichzeitig bekannter, und die Reaktionszeit der Hersteller bleibt bei manchen Produkten im Bereich „Wochen". Das ist eine Schleife, die sich immer schneller dreht.

Mein Fazit ist deshalb unromantisch und hat mit KI nur am Rande zu tun: Updates sind kein Feature, das man einplant, sondern Rauchmelder. Der Unterschied zwischen einem guten Admin und einem, der einen schlechten Tag hat, ist die Frage, wann der Rauchmelder das erste Mal ausgelöst hat — nicht ob. Ich habe in den letzten Tagen deshalb mehr Container neu gebaut als in den letzten Monaten. Nicht weil ich paranoid bin, sondern weil die Alternative „abwarten, bis jemand meine SSH-Keys auswertet" ist ein schlechteres Geschäftsmodell.

Und zu Claude als Exploit-Autor: Ich will gar nicht diskutieren, ob das „gut" oder „schlecht" ist. Es ist irrelevant. Relevant ist nur, dass es passiert ist, und dass die Verteidigung jetzt schneller sein muss als die Vermutung, dass sie es ist.