Die zwei größten Security-Geschichten von Mitte 2026 sind derselbe Fehler, eine Abstraktionsebene auseinander. Eine Firewall wurde gerootet, weil ein Authentication-Portal aus dem offenen Internet erreichbar war. Ein KI-Agent wurde bestohlen, weil er einen unsignierten Skill von einem offenen Marktplatz installierte. Anderes Jahrzehnt, anderer Stack, identisches Versagen: keine Provenienz, kein Least Privilege, keine Change-Control.
Ich sichere seit siebzehn Jahren Enterprise-Netzwerke ab. Der KI-Agenten-Welt in diesem Jahr beim Zusammenbruch zuzusehen, fühlt sich genau an wie das Zusehen, wenn eine fehlkonfigurierte Firewall übernommen wird, denn es ist dasselbe. Die Lektionen, die die Netzwerksicherheits-Zunft über zwanzig Jahre mit Blut bezahlt hat, sind die Lektionen, die die KI-Welt jetzt live lernt, im Tempo und in aller Öffentlichkeit. Dieser Beitrag ist die Übersetzung, geschrieben von jemandem, der beide Seiten der Linie kennt.
Was auf der Firewall-Seite wirklich passiert ist
Im Mai 2026 legte Palo Alto Networks CVE-2026-0300 offen: ein Buffer Overflow im PAN-OS User-ID Authentication Portal, der einen unauthentifizierten Angreifer per präparierter Pakete Code als Root ausführen lässt. CVSS 9.3. Betroffen sind PA-Series- und VM-Series-Firewalls, die dieses Portal nutzen, und Unit 42 bestätigte aktive Ausnutzung durch ein vermutlich staatlich gesteuertes Cluster, das Shellcode in einen nginx-Worker-Prozess injizierte.
Das entscheidende Detail ist nicht der Overflow. Es ist die Voraussetzung. Die Schwachstelle greift nur, wenn das Authentication Portal gegenüber nicht vertrauenswürdigen Netzen exponiert ist. Palo Altos eigene Empfehlung ist unmissverständlich: Beschränken Sie das Portal auf vertrauenswürdige interne IPs, und das Risiko bricht zusammen. Eine begleitende Schwachstelle, CVE-2026-0257 in GlobalProtect, wurde auf kritisch heraufgestuft, nachdem aktive Ausnutzung einen Auth-Bypass als real statt theoretisch bestätigte.
Die Box war also durch einen Code-Defekt verwundbar, gerootet wurde sie aber, weil jemand einen management-nahen Dienst ins öffentliche Internet stellte und niemand das als Änderung markierte. Das ist kein Palo-Alto-Problem. Genau diesen Befund habe ich in Audit-Berichten über ein Dutzend Hersteller hinweg geschrieben. Die Appliance ist nur der Ort, an dem es diesmal sichtbar wurde.
Was auf der KI-Seite wirklich passiert ist
Im selben Zeitfenster deckten Sicherheitsforscher eine Supply-Chain-Kampagne auf dem Skill-Marktplatz einer offenen KI-Agenten-Plattform auf. Koi Security nannte sie im Februar 2026 ClawHavoc. Die Zahlen sind die Geschichte: mindestens 1.184 bösartige Skills, verteilt über eine Handvoll Publisher-Konten, geschätzt 300.000 Agenten-Nutzer in Reichweite, und ein macOS-Payload, den Forscher der Atomic-macOS-Stealer-Familie zuordneten und der Keychains, SSH-Schlüssel, Browser-Zugangsdaten und Krypto-Wallets abgriff.
Das ausschlaggebende Detail ist auch hier nicht die Malware. Es ist die Veröffentlichungshürde. Um einen Skill hochzuladen, den ein Agent abruft und ausführt, brauchte ein Angreifer ein GitHub-Konto, das mindestens eine Woche alt war. Kein Code-Review. Keine Signatur. Keine Provenienzprüfung zwischen „ein Fremder hat das geschrieben“ und „dein Agent führt es jetzt mit deinen Rechten aus“. Der Marktplatz optimierte auf reibungslose Beiträge und behandelte Vertrauen als das Problem von jemand anderem.
Ein KI-Skill ist nur Code, der in deinem Kontext läuft. Ein Marktplatz, der unsignierten Code anonymer Autoren direkt in einen ausführenden Agenten liefert, ist ein Software-Repository mit abgefeilter Sicherung. Diesen Film haben wir schon gesehen. Er hieß die frühe Paket-Registry-Ära, und npm, PyPI und der Rest verbrachten Jahre damit, die Kontrollen nachzurüsten, die vom ersten Tag an fehlten.
Warum ich sie denselben Fehler nenne
Reduziert man beide Vorfälle auf die Entscheidung, die sie verursacht hat, laufen sie zusammen. Jeder vertraute etwas, dem er nicht hätte vertrauen dürfen, gab diesem Etwas mehr Reichweite als nötig und ließ es das laufende System ändern, ohne dass jemand die Änderung prüfte. Die Abstraktionsebene ist verschieden. Die Bruchlinie läuft durch dieselben drei Kontrollen.
| Versagte Kontrolle | Firewall-Seite (CVE-2026-0300) | KI-Agenten-Seite (ClawHavoc) |
|---|---|---|
| Provenienz & Vertrauen | Ein Auth-Portal, das Pakete von jeder nicht vertrauenswürdigen Quelle im Internet annimmt | Unsignierte Skills anonymer Publisher, kein Review zwischen Upload und Ausführung |
| Least Privilege | Exploit landet als Root, volle Kontrolle über die Appliance, keine Begrenzung des Blast Radius | Skill läuft mit der vollen Identität des Agenten: Keychains, SSH-Schlüssel, Wallets |
| Change-Control | Das Exponieren eines management-nahen Dienstes wurde nie als Änderung geprüft | Das Hinzufügen eines Drittanbieter-Skills ist eine stille Abhängigkeitsänderung, die niemand freigibt |
| Exposition | Per Design aus dem öffentlichen Internet erreichbar | Per Design über einen öffentlichen Marktplatz erreichbar |
| Erkennung | nginx-Worker-Shellcode blieb bis zur Hersteller-Offenlegung unbemerkt | Der Diebstahl lief wochenlang, bevor Forscher — nicht Opfer — Alarm schlugen |
Lesen Sie diese Tabelle von oben nach unten, und Appliance und Agent hören auf, wie getrennte Probleme auszusehen. Die neue Technologie hat keine neue Art zu scheitern erfunden. Sie hat die älteste wiederentdeckt und ihr einen schnelleren Motor verpasst.
Die Kontrolle, die die Netzwerkwelt mühsam gelernt hat: Provenienz
Provenienz heißt zu wissen, woher etwas kommt und ob man ihm vertrauen sollte, bevor man es handeln lässt. Die Netzwerksicherheit lernte diese Lektion auf die teure Tour. Wir hörten auf, Traffic zu vertrauen, nur weil er am Innen-Interface ankam. Wir hörten auf, einem Gerät zu vertrauen, nur weil es im richtigen VLAN saß. Zero Trust ist im Kern eine zwanzigjährige Entschuldigung dafür, angenommen zu haben, dass Standort Vertrauen bedeutet.
Die KI-Agenten-Welt macht dieselbe Annahme mit frischem Anstrich. „Es ist im offiziellen Marktplatz, also ist es in Ordnung.“ „Es hat Sterne, also ist es in Ordnung.“ Ein Marktplatz-Eintrag ist ein Standort, keine Vertrauensentscheidung — genauso wie eine interne IP ein Standort und keine Vertrauensentscheidung war. Die Lösung ist dieselbe Lösung: die Quelle verifizieren, Signaturen verlangen und alles Unverifizierte als feindlich behandeln, bis das Gegenteil bewiesen ist. Wer die ausführliche Version dieses Arguments speziell für KI will: Ich habe es entlang des Frameworks in der OWASP LLM Top 10 für 2026 aufgeschrieben, wo Prompt Injection (LLM01) und Excessive Agency (LLM06) dasselbe Provenienz-und-Privilegien-Versagen sind, nur für die Modell-Ebene angezogen.
Die Kontrolle, die beide Welten überspringen: Least Privilege
Least Privilege beantwortet eine Frage: Wenn dieses Etwas kompromittiert wird — und das wird es —, wie viel kann es anfassen? Auf der Firewall lautete die Antwort „alles“, weil der Exploit als Root landete. Auf dem Agenten lautete die Antwort ebenfalls „alles“, weil ein Skill die volle Identität des Agenten erbt, der ihn lädt, und dieser Agent trug Keychains und Wallet-Zugriff mit sich, die er für die anstehende Aufgabe nie brauchte.
Ich habe eine Laufbahn lang argumentiert, dass eine Firewall-Regel die engste Quelle, das engste Ziel und den engsten Dienst erlauben sollte, der das Geschäft funktionieren lässt — und keinen Port mehr. Der Grund ist nicht Ordnungsliebe. Es ist, dass die Regel irgendwann falsch oder missbraucht sein wird, und das Einzige, was zwischen „falsch“ und „Vorfall“ steht, ist, wie wenig diese Regel anfassen durfte. Ein KI-Agent braucht dieselbe Disziplin. Ein Skill, der Dokumente zusammenfasst, hat bei Wallet-Schlüsseln nichts verloren. Begrenzen Sie die Credentials des Agenten auf die Aufgabe, setzen Sie die Tools, die er aufrufen darf, auf Default-Deny, und verlangen Sie ausdrückliche Bestätigung für alles Destruktive. Genau dieses Denken habe ich über Hunderte Firewall-Audits angewandt, neu gezeichnet für eine neue Oberfläche — die Firewall-Version lege ich in meinem Beitrag zur Firewall-Change-Automatisierung dar.
Die Kontrolle, die die anderen zwei real macht: Change Management
Provenienz und Least Privilege sind statische Design-Entscheidungen. Change Management hält sie nach dem Launch wahr, wenn der Druck steigt und das System driftet. Beide Vorfälle von 2026 sind Change-Management-Versagen, verkleidet als technische. Das Exponieren dieses Auth-Portals war eine Änderung, die niemand prüfte. Das Installieren dieses Skills war eine Abhängigkeitsänderung, die niemand freigab.
Hier ist die unbequeme Parallele. Die Netzwerkbranche weiß bereits, dass Change-Control auf dem Papier den Kontakt mit der operativen Realität nicht überlebt — genau deshalb habe ich eine Plattform gebaut, die sie auf Firewalls durchsetzt, statt dem wöchentlichen Change Board zu vertrauen. Die KI-Agenten-Branche hat nicht einmal die Papier-Stufe erreicht. Es gibt kein Change Board für „mein Agent hat um 2 Uhr nachts einen neuen Skill hinzugefügt“. Ein Team, das 2026 autonome Agenten betreibt, hat weniger Sicht darauf, was seine Software ausführt, als ein Netzwerkteam 2006 auf sein Firewall-Regelwerk hatte — und das sollte jeden erschrecken, der je ein echtes Audit erlebt hat. Zur größeren Reifelücke, die das im Mittelstand aufreißt, siehe warum der deutsche Mittelstand gefährlich unvorbereitet auf NIS2 ist.
Was Sie dieses Quartal konkret tun sollten
Die Übersetzung nützt nur, wenn sie den Montag verändert. Ob Sie Firewalls, KI-Agenten oder beides betreiben: Dieselbe kurze Liste gilt. Nichts davon ist neu, und genau das ist der Punkt.
- Inventarisieren Sie Ihre Exposition. Listen Sie jeden management-nahen Dienst, der aus einem nicht vertrauenswürdigen Netz erreichbar ist, und jeden Drittanbieter-Skill, jedes Modell und jedes Tool, das Ihre Agenten laden können. Sie können nicht verteidigen, was Sie nicht aufgezählt haben.
- Verlangen Sie Provenienz. Beschränken Sie das Firewall-Portal auf vertrauenswürdige IPs. Erlauben Sie nur signierte, geprüfte Skills aus Quellen, die Sie überprüft haben. Behandeln Sie einen Marktplatz-Eintrag als Behauptung, nicht als Nachweis.
- Kürzen Sie Privilegien auf die Aufgabe. Patchen Sie CVE-2026-0300 und Verwandte, dann begrenzen Sie, was übrig bleibt. Scopen Sie Agenten-Credentials und Tool-Berechtigungen wie eine Firewall-Regel: das engste, was funktioniert, alles andere Default-Deny.
- Machen Sie Änderungen sichtbar. Jede Konfigurationsänderung und jede neue Abhängigkeit sollte prüfbare Evidenz erzeugen. Wenn Sie „was hat sich geändert, wer hat es freigegeben, und warum“ nicht in Minuten beantworten können, ist Ihr Audit-Trail Dekoration.
Gleichen Sie das mit jedem Framework ab, dem Sie unterliegen, und es landet in denselben Kontrollen: ISO 27001, NIS2, DORA, BSI IT-Grundschutz. Sie alle verlangen Provenienz, Least Privilege und Nachweis von Änderungen. Die Frameworks hatten recht; wir wenden sie nur auf eine Ebene an, die es bei ihrer Entstehung nicht gab. Wer den breiteren europäischen Beratungskontext will: Ich behandle ihn in meiner Notiz zur KI-Sicherheitsberatung für europäische Unternehmen, und die Erkennungsseite in KI-Bedrohungserkennung für CISOs.
Warum ein Netzwerksicherheits-Hintergrund die richtige Linse ist
Ich bin kein KI-Forscher, der unterwegs etwas Security aufgeschnappt hat. Ich kam aus der anderen Richtung: von PAN-OS, Check Point, Cisco und Fortinet, von OT-Segmentierung und ISO-27001-Audits, in die KI-Sicherheit. Diese Reihenfolge zählt, denn die KI-Agenten-Versagen von 2026 sind keine neuartigen KI-Probleme. Es sind klassische Infrastrukturprobleme mit einem Modell obendrauf, und die Menschen, die das am besten sehen, sind die, die die Lektion schon einmal bezahlt haben.
Die Firewall-Welt verbrachte zwei Jahrzehnte damit zu lernen, dass Vertrauen verdient sein muss, Privilegien minimiert sein müssen und Änderungen kontrolliert sein müssen. Die KI-Welt lernt es jetzt, schneller und öffentlicher, mit denselben drei Kontrollen, die jedes einzelne Mal im Post-Incident-Bericht stehen. Sie müssen es nicht so lernen, wie wir es taten. Sie können sich die Antwort leihen. Ich habe produktive KI unter genau dieser Disziplin ausgeliefert, was ich in den Lektionen aus dem Bau von RogueAI aufgeschrieben habe.
Wenn Sie KI-Agenten ausrollen und Ihr Sicherheitsmodell nicht mit dem Schritt gehalten hat, was diese ausführen können, ist diese Lücke jetzt prüfbar, statt nach einem Vorfall. Ich führe Projekte, die Enterprise-Netzwerksicherheits-Disziplin auf KI-Workloads übersetzen: Provenienz, Least Privilege und Change-Control, gebaut, um ein echtes Audit zu überstehen. Review anfragen. Siehe auch FwChange.com für Firewall-Change-Automatisierung und RogueAI.de für das Produktiv-KI-Portfolio.