Autor: Holger von Rhein

Kryptographie
KI/ML

KI-Agenten machen Berechtigungsgrenzen zur Sicherheitsfrage

Der Sicherheitsvorfall beim US-amerikanischen KI-Dienstleister Hugging Face im Juli 2026 zeigt, warum KI-Agenten nicht allein über Modellschutz abgesichert werden können. Während einer internen Cyber-Evaluation identifizierten und kombinierten OpenAI-Modelle Schwachstellen in der Testumgebung. Sie erlangten darüber Internetzugang und drangen anschließend bis in die Produktionsinfrastruktur von Hugging Face vor.

https://openai.com/index/hugging-face-model-evaluation-security-incident/

Betroffen waren interne Datensätze sowie Zugangsdaten von Diensten. Öffentliche Modelle, Datensätze, Spaces und die Software-Lieferkette waren nach Angaben von Hugging Face nicht manipuliert.

https://huggingface.co/blog/security-incident-july-2026

Der Vorfall fand in einer Evaluation mit reduzierten Schutzmechanismen statt. Er ist deshalb nicht mit dem Einsatz eines Standardprodukts gleichzusetzen. Seine Relevanz liegt an anderer Stelle. Ein Agent kann bekannte Angriffstechniken über viele Einzelschritte hinweg verbinden, wenn seine Umgebung zu weitreichende Zugriffe ermöglicht. Sicherheit entsteht damit nicht nur durch Vorgaben im Modell, sondern auch durch technisch durchgesetzte Grenzen für Identitäten, Zugriffe und Aktionen.

https://openai.com/index/hugging-face-incident-and-the-road-ahead/

Auch aktuelle Erkenntnisse zu Ransomware stützen diese Einordnung. Der Sicherheitsdienstleister CloudSEK dokumentierte in einem Fall den Einsatz des KI-Agenten Cursor zur Planung von Angriffsschritten. Das ist kein Beleg für eigenständig operierende KI. Es zeigt aber, dass Angreifer KI-Assistenten bereits in bestehende Angriffsketten einbinden, um technische Aufgaben schneller vorzubereiten und umzusetzen.

https://www.cloudsek.com/blog/aurora-ransomware-affiliate-ai-attack-planning-crypto-payments

Prompt Injection verschärft das Risiko. Inhalte aus Dokumenten, Websites oder Repositories können dabei von einem Agenten als Handlungsanweisung verarbeitet werden. Modellseitige Schutzmechanismen können problematische Antworten mit einiger Wahrscheinlichkeit erkennen und unterdrücken. Sie verhindern jedoch nicht zuverlässig, dass ein manipulierter Agent mit einer gültigen Berechtigung auf Daten zugreift oder eine Aktion ausführt. Die entscheidende Sicherheitsfrage lautet daher (wie beim Hugging-Face-Fall), welche Rechte ein Agent technisch besitzt, und welche Aktionen ohne menschliche Freigabe möglich sind.

Die gemeinsame Leitlinie der Five-Eyes-Behörden vom 1. Mai 2026 und die vorläufigen Hinweise des britischen NCSC vom 20. August 2026 weisen in dieselbe Richtung. Agentische Systeme benötigen eng begrenzte Berechtigungen und eine stetige Überwachung. Für kritische Fälle müssen Eingriffsmöglichkeiten erprobt sein.

https://ncsc.govt.nz/protect-your-organisation/careful-adoption-of-agentic-ai-services/

https://ncsc.gov.uk/blogs/managing-the-cyber-risk-of-agentic-ai

In dieselbe Richtung gehen auch die Überlegungen der NSA zum Sicherheitsdesign des Model Context Protocol. Das MCP verbindet Agenten mit Datenquellen und Funktionen anderer Systeme. Das Protokoll schreibt jedoch weder eine eindeutige Zuordnung von Sitzungen zu Identitäten noch eine rollenbasierte Zugriffskontrolle verbindlich vor. Auch der Umgang mit Zugangsdaten, Freigaben und Protokollierung hängt wesentlich von der jeweiligen Umsetzung ab. Das Dokument der NSA beschreibt zentrale Risiken bei der Integration von KI-Agenten mit externen Tools und Datenquellen und gibt Empfehlungen für einen sicheren, Zero-Trust-orientierten Betrieb.

https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF

Für CISO, IT-Leitung und KI-Governance folgt daraus eine konkrete Priorität. Jeder eingesetzte Agent braucht eine nachvollziehbare Identität. Seine Berechtigungen müssen auf den jeweiligen Zweck begrenzt sein. Besonders risikoreiche Aktionen benötigen eine menschliche Freigabe. Erst auf dieser Grundlage lassen sich Risiken realistisch bewerten und Zugriffe wirksam begrenzen.

Schwachstelle

Signiert und trotzdem bösartig

Der Angriff auf die Softwarebibliotheken keyv und cacheable vom 4. August 2026 zeigt eine oft übersehene Grenze. Die sogenannte Provenance, also der Nachweis, wo und über welchen Prozess ein Artefakt gebaut wurde, bestätigt die Herkunft eines Builds. Sie bestätigt nicht, dass der zugrunde liegende Quellcode legitim oder unverändert war.

Bei keyv@6.0.0 waren npm-Provenance und SLSA-Attestation (ein Beleg, dass die Software in einer sicheren, nachvollziehbaren Umgebung gebaut wurde) gültig. Dennoch enthielt das veröffentlichte Paket Schadcode, weil dieser bereits vor dem Build in das Repository eingebracht worden war. Der reguläre Prozess baute und signierte damit korrekt einen kompromittierten Stand.

https://socket.dev/supply-chain-attacks/keyv-and-cacheable-compromise

Provenance schützt den Veröffentlichungsweg, nicht automatisch die Integrität des Quellcodes. Wer eine gültige Attestation als vollständigen Sicherheitsnachweis bewertet, verwechselt Build-Herkunft mit Code-Integrität.

Das kompromittierte Paket enthielt einen preinstall-Hook, der bereits bei der Installation lief. Damit konnte Schadcode auf Entwicklerrechnern oder CI-Runnern auf Tokens, Cloud-Zugänge und weitere sensible Daten zugreifen. Die Gefahr beginnt also nicht erst in der Produktivumgebung, sondern beim Auflösen und Installieren von Abhängigkeiten.

https://snyk.io/blog/inside-keyv-npm-compromise-preinstall-malware-trusted-provenance-ide-hooks/

Hinzu kamen Projektkonfigurationen für Claude Code und VS Code, die beim Öffnen eines Repositorys Code ausführen konnten. Solche Dateien gehören inzwischen ebenso in Sicherheitsreviews wie Build-Skripte und CI-Konfigurationen. Ein reiner Dependency-Scan reicht dafür nicht aus.

https://safedep.io/keyv-npm-supply-chain-compromise/

Die gemeldete Reichweite unterstreicht das Risiko, auch wenn sie keine Zahl tatsächlich kompromittierter Systeme beschreibt. keyv kam laut Aikido zum Zeitpunkt der Analyse auf rund 127 Millionen wöchentliche Downloads. Entscheidend für die eigene Bewertung sind jedoch nicht globale Summen, sondern die konkret verwendeten Versionen in Lockfiles, Artefakt-Proxys und Build-Caches.

https://aikido.dev/blog/keyv-and-friends-compromised-in-npm-supply-chain-attack

Für Security- und Plattformteams folgt daraus eine klare Priorität. Lifecycle-Skripte sollten nur dort laufen, wo sie erforderlich sind, und dabei möglichst geringe Rechte erhalten. Installationsprozesse dürfen keinen Zugriff auf weitreichende Publishing-Tokens oder produktive Cloud-Zugänge bekommen. Neu veröffentlichte Abhängigkeiten können zudem vor der Übernahme in zentrale Builds eine Wartezeit durchlaufen.

Auch die Incident Response muss diesen Fall abdecken. Nach einer potenziell bösartigen Installation muss schnell erkennbar sein, welche Zugangsdaten auf dem betroffenen System verfügbar waren. Host-Isolierung und die Suche nach Persistenz sollten vor der Token-Rotation erfolgen, weil eine vorschnelle Sperrung Angreifer warnen kann.

https://snyk.io/blog/inside-keyv-npm-compromise-preinstall-malware-trusted-provenance-ide-hooks

Provenance bleibt wichtig. Sie ist jedoch ein Herkunftsnachweis, kein vollständiger Integritätsnachweis. Sicherheit entsteht erst dann, wenn auch die Ausführung fremden Codes, seine Berechtigungen sowie ausführbare Editor- und Agentenkonfigurationen kontrolliert werden.

Der Vorfall sollte für jeden Anlass sein, die Ausführung fremden Codes als eigenständiges Risiko zu behandeln. Besonders gilt dies bei Installationsprozessen und Build-Runnern mit weitreichenden Zugängen, da dort ein kompromittiertes Paket unmittelbar Tokens oder Cloud-Zugriffe abgreifen kann. Editor- und Agentenkonfigurationen gehören deshalb verbindlich in Repository-Reviews.

Post-Quanten-Kryptografie

Der G7 drängt, die EU-Uhr läuft: Post-Quanten-Migration ist ein Inventarproblem

Die G7-Arbeitsgruppe für Cybersicherheit hat am 3. September 2026 öffentliche und private Organisationen in einem gemeinsamen Aufruf dazu aufgefordert, den Übergang zu Post-Quanten-Kryptografie jetzt vorzubereiten. Wann kryptografisch relevante Quantencomputer verfügbar sein werden, ist offen. Das Risiko besteht dennoch bereits heute. Angreifer können verschlüsselte Daten schon jetzt abgreifen und so speichern, um sie später zu entschlüsseln, wenn die technische Fähigkeit dafür vorhanden ist. Besonders betroffen sind Informationen, die über viele Jahre vertraulich bleiben müssen.

https://cyber.gouv.fr/en/news/post-quantum-cryptography-transition-anssi-and-its-g7-partners-rally-public-and-private-sectors-with-urgent-call-to-action/

Auch die europäische Roadmap wird häufig missverstanden. Ende 2026 ist kein Endtermin für die Migration. Bis dahin sollen alle EU-Mitgliedstaaten erste Schritte umgesetzt und nationale Post-Quantum-Computing-Strategien (PQC) angestoßen haben. Hochrisikofälle, etwa in kritischen Infrastrukturen, sollen so früh wie möglich und spätestens bis Ende 2030 auf quantenresistente Verfahren umgestellt sein. Die Roadmap empfiehlt für den Übergang standardisierte hybride Verfahren. Krypto-Agilität gehört ebenfalls dazu.

https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography

Ab 2027 will Frankreich PQC bei der Qualifizierung von Sicherheitsprodukten berücksichtigen. Für Organisationen bedeutet das vor allem eines. Sie sollten neue Produkte und Ersatzbeschaffungen nicht mehr ohne eine belastbare Aussage des Herstellers zu PQC und Krypto-Agilität bewerten.

https://cyber.gouv.fr/enjeux-technologiques/cryptographie-post-quantique/faq-pqc/

Die entscheidende Frage zu Beginn einer Migration lautet nicht, welches PQC-Verfahren eingesetzt werden soll, sondern, ob die Organisation ihre heutige Kryptografie kennt. Wo werden RSA, ECC oder Diffie-Hellman eingesetzt? Welche Zertifikate, VPN-Verbindungen, HSM, Signaturprozesse und Geräteflotten hängen daran? Welche Abhängigkeiten bestehen zu Herstellern oder Dienstleistern?

Wer PQC als reines Update behandelt, übersieht das eigentliche Risiko. Die Erfassung scheitert selten an fehlender Technik. Häufig fehlen klare Verantwortlichkeiten und ein sinnvoll abgegrenzter Startbereich.

Statt sofort das gesamte Unternehmen zu erfassen, sollte zunächst ein Pilot in einem geschäftskritischen, aber überschaubaren Bereich starten. Eine verantwortliche Rolle sollte den Umfang festlegen und die eingesetzten Verfahren dokumentieren. Parallel sollten Beschaffungsvorgaben ergänzt werden. Hersteller müssen darlegen, wie sie Krypto-Agilität ermöglichen und wann sie PQC unterstützen.

Diese Maßnahmen lohnen sich unabhängig davon, wann der Q-Day eintritt. Sie schaffen die Grundlage, um Risiken priorisiert zu bewerten und die Migration kontrolliert zu steuern.

NIS2

NIS-2-Registrierung und die Lücke in der Statistik

18.845 Registrierungen von Einrichtungen, die unter die NIS-2-Richtlinie fallen, zum 31.07.2026 – gegenüber einer erwarteten Zahl von rund 29.500. Die Differenz prägt die Debatte über NIS-2. Sie belegt jedoch nicht, dass rund 10.000 Einrichtungen ihre Pflichten ignorieren.

Die Zahl von 29.500 war eine Schätzung des Statistischen Bundesamtes auf Basis älterer Daten. Das Bundesinnenministerium lässt diese Bezugsgröße inzwischen neu berechnen. Damit ist die vielzitierte Registrierungslücke vor allem eines sicher nicht: ein belastbarer Nachweis über die tatsächliche Zahl registrierungspflichtiger Einrichtungen. Sie beschreibt die Differenz zwischen Registrierungen und einer Prognose, deren Grundlage nun selbst überprüft wird.

https://www.it-daily.net/shortnews/nis2-nach-nachfrist-weiter-zu-wenig-registrierungen

Für die eigene Organisation ist diese Debatte dennoch kein Grund zum Abwarten. Die Registrierungspflicht entsteht nicht durch eine bundesweite Quote und auch nicht durch ein Anschreiben des BSI. § 33 BSIG knüpft sie an den Zeitpunkt, zu dem eine Einrichtung erstmals oder erneut als wichtig oder besonders wichtig gilt. Ab diesem Zeitpunkt läuft die individuelle Dreimonatsfrist.

https://www.gesetze-im-internet.de/bsig_2025/__33.html

Der 31.07.2026 war dabei eine vom BSI kommunizierte Erwartung, nicht jedoch eine neue gesetzliche Frist. Für Einrichtungen, die bereits am 6. Dezember 2025 erfasst waren, endete die gesetzliche Dreimonatsfrist am 6. März 2026. Eine fehlende oder verspätete Registrierung kann nach § 65 BSIG bußgeldbewehrt sein.

https://itmr-legal.de/blog/nis2-registrierung-verpasst

Entscheidend ist deshalb die Selbsteinstufung je Rechtseinheit. Gerade in Konzernen liegt das Risiko oft nicht bei der Mitarbeiterzahl, sondern bei der Frage, welche Gesellschaft welche Dienstleistung erbringt und welchem regulierten Sektor sie zuzuordnen ist. Eine Konzernentscheidung ersetzt diese Prüfung nicht.

Die Empfehlung lautet, die Betroffenheitsprüfung je Rechtseinheit zu dokumentieren. Das gilt auch für den Zeitpunkt der erstmaligen Betroffenheit und für den Beginn der daraus folgenden individuellen Dreimonatsfrist.

News

Cyberangriff auf das Berliner Landesnetz

Die folgende Meldung basiert ausschließlich auf öffentlich zugänglichen Quellen mit Stand vom 8. September 2026.

Die Gruppe Rhysida hat sich nach Angaben des Landes Berlin zum Angriff auf zwei Berliner Senatsverwaltungen bekannt und behauptet, Daten im Umfang von 5,7 Terabyte exfiltriert zu haben. Die Daten wurden gegen ein Mindestgebot von 30 Bitcoin angeboten. Berlin erklärte, auf die Erpressung nicht einzugehen.

https://www.berlin.de/rbmskzl/aktuelles/pressemitteilungen/2026/pressemitteilung.1710327.php

Nach Ablauf des Ultimatums veröffentlichte die Tätergruppe am 4. September ein erstes Datenpaket, das laut Medienberichten rund 1,44 Millionen Dateien umfasst.

https://www.heise.de/news/Cyberangriff-Berlin-mit-Steuerungseinheit-will-Betroffene-kontaktieren-11442896.html

Wie viel des von Rhysida behaupteten Bestands tatsächlich abrufbar ist, ist öffentlich nicht abschließend geklärt. Der Tagesspiegel berichtet am 6. September von mindestens 755.121 Dateien.

https://tagesspiegel.de/interaktiv/das-berliner-datenleck-in-grafiken-wie-viele-menschen-betroffen-und-welche-dateien-brisant-sind-16021746.html

Am 6. September veröffentlichte die Tätergruppe nach Angaben des Landes Berlin ein weiteres Datenpaket, das unter anderem Zugangsdaten enthält. Die zuständige Senatsverwaltung überprüfte daraufhin die nach der ersten Veröffentlichung ergriffenen Maßnahmen und schärfte sie vorsorglich in Teilen nach, was kurzfristig zu Einschränkungen bei Fachverfahren führen kann.

https://berlin.de/rbmskzl/aktuelles/pressemitteilungen/2026/pressemitteilung.1710816.php

Nach dem bisherigen Prüfstand des Senats sind auch Verschlusssachen des Geheimhaltungsgrades VS-NfD betroffen. Daten mit noch höherer Sensibilität für die öffentliche Sicherheit wurden bislang nicht festgestellt. Die Auswertung von mehr als 1,2 Millionen Dateien dauert an.

https://www.berlin.de/aktuelles/10618882-958090-keine-hochsicherheitsdaten-von-hackerang.html

Der Tagesspiegel berichtet, das veröffentlichte Material enthalte Dokumente mit Bezügen zu kritischer Infrastruktur, Zivilschutz und Verteidigungsplanung. Ob die betroffenen Systeme für die Verarbeitung von Verschlusssachen freigegeben waren, ist bisher nicht bekannt. Nach einem weiteren Tagesspiegel-Bericht soll ein geleakter interner Vermerk vom Februar 2026 festhalten, dass digitaler Geheimschutz im strengen Sinne in der Berliner Verwaltung nicht möglich sei. Im Berliner Innenausschuss stand das Land Berlin bereits über mehrere Jahre wegen unzureichender Cybersicherheit in der Kritik. Frühere Warnungen vor erheblichen Sicherheitslücken erhalten nun neue Brisanz.

https://tagesspiegel.de/berlin/behorde-veroffentlicht-neue-details-zum-angriff-mit-dieser-methode-drangen-die-hacker-offenbar-in-berlins-it-netz-ein-16028757.html

https://tagesspiegel.de/berlin/hackerangriff-auf-berliner-verwaltung-der-daten-leak-war-ein-anschlag-die-reaktion-des-senats-ein-skanda-16020558.html

https://tagesspiegel.de/berlin/dpa-folgen-des-hackerangriffs-in-berlin-bsi-warnt-vor-erhohter-cyber-bedrohung-16020663.html

Zum mutmaßlichen Erstzugang beschreibt das BSI die Kampagne TerminalFix. Dabei verleiten gefälschte Captcha-Abfragen Nutzende zur Ausführung von Terminal- oder PowerShell-Befehlen. TerminalFix ist damit als öffentlich zugeordneter Erstzugangsvektor zu bewerten. Aussagen zur vollständigen Angriffskette oder zu strukturellen Ursachen sind öffentlich noch nicht abschließend belegt.

https://social.bund.de/@bsi/117212729947889443

https://golem.de/news/bsi-warnung-berliner-landes-it-offenbar-ueber-fake-captcha-gehackt-2609-212711.html

Auch der Umgang mit dem Angriff ist sehr umstritten. Die Senatskanzlei setzte CrowdStrike für die IT-Forensik ein und hat diese als „alternativlos“ bezeichnet. Deren Software sollte in allen Bezirken installiert werden. Lichtenberg lehnte ab, Steglitz-Zehlendorf entfernte den Agenten nach technischen Problemen wieder. Der Senat drohte Lichtenberg daraufhin mit der Abtrennung von Fachverfahren. Später stimmte der Bezirk einer begrenzten Untersuchung zu. CrowdStrike unterliegt als US-Unternehmen dem CLOUD und FISA Act. Darüber hinaus halten sie eine strategische Partnerschaft mit Palantir.

https://tagesspiegel.de/berlin/bezirke/lichtenberg/meine-geduld-ist-am-ende-berliner-bezirk-blockiert-nach-hackerangriff-us-software–jetzt-droht-isolation-16028000.html

Der Streit zeigt zwei Fragen, die getrennt bewertet werden müssen. Erstens geht es um Datenschutz und mögliche Zugriffsrisiken bei einem US-Anbieter. Zweitens geht es um die Betriebssicherheit eines tief ins System eingreifenden und Konflikt erzeugenden Agenten in produktiven Fachverfahren. Beides muss vor einem Sicherheitsvorfall geklärt sein. Unter Zeitdruck werden aus offenen Fragen operative Risiken.

News

SC104 lockert AIA-Vorgabe für TLS-Zertifikate

Der Herstellerzusammenschluss CA/Browser-Forum CAB hat mit der Abstimmung SC104 beschlossen, die Authority-Information-Access-Erweiterung soll bei öffentlich vertrauenswürdigen TLS-Serverzertifikaten künftig empfohlen statt verpflichtend sein. Die 30-tägige IPR-Review-Phase läuft noch bis zum 3. Oktober 2026, daher ist die Änderung noch nicht wirksam.

https://cabforum.org/2026/09/03/ballot-sc104-set-presence-of-aia-extension-to-should-for-subscriber-certificates/

Für IT-Verantwortliche ist SC104 vor allem ein Signal. Anforderungen an öffentliche TLS-Zertifikate können sich ändern. Wer Zertifikate dezentral und ohne belastbares Inventar verwaltet, kann oft nur mit hohem Aufwand feststellen, welche Dienste betroffen sind und welches Team handeln muss. Entscheidend ist daher ein Überblick darüber, welches Zertifikat welchen extern erreichbaren Dienst absichert und wer dafür zuständig ist.

Genau dort beginnt Krypto-Agilität. Sie beschreibt die Fähigkeit, kryptografische Algorithmen, Protokolle und Schlüssel bei neuen Anforderungen oder erkannten Schwachstellen kontrolliert auszutauschen. Ein Krypto-Inventar schafft die nötige Transparenz. Es verbindet Zertifikate mit Diensten, Verantwortlichkeiten und mit den eingesetzten kryptografischen Komponenten. Dadurch lassen sich Änderungen wie SC104 früh einordnen, Auswirkungen bewerten und notwendige Anpassungen gezielt anstoßen.

Schwachstelle

Die Perimeter-Schmelze

Warum VPN-Gateways und Legacy-Altlasten uns im Sommer 2026 einholen

Während Check Point und Palo Alto kritische bzw. hochriskante Authentifizierungsumgehungen offenlegten, zeigte FortiBleed eine parallele Schwächeklasse: massenhafte Kompromittierung durch wiederverwendete oder aus Konfigurationen extrahierte Zugangsdaten, begünstigt durch Legacy-Credential-Handling und exponierte Management-/VPN-Oberflächen. Das Perimeter-Modell erodiert strukturell. Check Point selbst beobachtete, dass dieselbe Bedrohungsakteur-Infrastruktur parallel auch Schwachstellen bei Palo Alto, Fortinet und F5 ausnutzt. Ein koordinierter Angriff auf die gesamte Gateway-Kategorie.

CVE-2026-50751 (CVSS 9.3) erlaubt unauthentifizierten Angreifern, eine VPN-Sitzung ohne gültiges Passwort aufzubauen. Entscheidend ist die Bedingung: Die Schwachstelle betrifft ausschließlich Deployments, die das veraltete IKEv1-Schlüsselaustauschprotokoll nutzen, bei denen Gateways Legacy-Remote-Access-Clients akzeptieren und kein Maschinenzertifikat verlangen. Die Ausnutzung begann bereits am 7. Mai, verstärkte sich Anfang Juni, und Check Point bewertet mit mittlerer Konfidenz, dass der Akteur finanziell motiviert ist und Qilin-Ransomware einsetzt. Das „Zero-Day“-Fenster ohne verfügbaren Patch dauerte rund einen Monat.

CVE-2026-0257 wirkt zunächst harmloser – ursprünglich nur mit CVSS 4,7 bewertet –, doch die Eskalation war dramatisch. Verwundbare PAN-OS-Versionen vertrauten jedem entschlüsselbaren Authentication-Override-Cookie, ohne zu prüfen, ob es legitim vom Gerät erzeugt wurde. Wird dasselbe Zertifikat für den HTTPS-Dienst und die Cookie-Verschlüsselung verwendet, kann ein Angreifer die öffentliche Zertifikatskette abrufen und gültige Cookies für beliebige Nutzer fälschen – inklusive Administratoren. Nach Rapid7s Proof-of-Concept und bestätigter Ausnutzung hob Palo Alto den Schweregrad auf 7,8 an; CISA nahm die Lücke am 29. Mai in den Known-Exploited-Vulnerabilities-Katalog (KEV-Katalog) auf. Bei acht von zehn betroffenen Rapid7-MDR-Kunden blieb es bei reinen Authentifizierungs-Sonden ohne vollständige VPN-Sitzung – ein Hinweis, dass die Angriffswelle noch breiter angelegt war als bislang sichtbar.

Was im Juni als Leak von rund 74.000 Fortinet-Zugangsdaten begann, hat sich zu einem der gravierendsten Vorfälle des Jahres entwickelt. Aktuelle SOCRadar-Recherchen beziffern die Kampagne auf über 430.000 angegriffene FortiGate-Firewalls weltweit mit mehr als 110 Millionen erbeuteten Zugangsdaten. Der technische Kern bleibt das Legacy-Data-Debt-Problem: Ältere Passwort-Hashes verbleiben nach einem Firmware-Update auf PBKDF2 so lange als schwächere SHA-256-Hashes gespeichert, bis sich ein Administrator nach dem Upgrade manuell neu anmeldet.

Die eigentliche Eskalation kam jedoch erst Anfang Juli: SOCRadars Threat Research Unit fand einen Operator, der gleichzeitig in den Verhandlungspanels von INC Ransom und Lynx eingeloggt war – der belastbare Beweis, dass FortiBleed direkt in die Ransomware-Ökonomie einspeist. Konkret bedeutet das: Scanning-Aktivität gegen rund 11.250 FortiGate-Portale, bestätigter Admin-Zugriff auf 409 Ziele, vollständiger Angriffsketten-Abschluss bei 354 davon, mit mindestens 12 bestätigten Ransomware-Deployments und hunderten verschlüsselten Endpunkten. Zusätzlich identifizierten die Forscher Hinweise auf einen Nextcloud-Zero-Day sowie Citrix-bezogene Artefakte, die auf eine Ausweitung über Fortinet hinaus deuten.

Drei unterschiedliche technische Ursachen – Protokoll-Legacy, Logikfehler, Krypto-Schulden – führen zum selben Ergebnis: kompromittierter Perimeter, Ransomware-Zugang. Patch-Management allein greift zu kurz. Notwendig sind die konsequente Deaktivierung von IKEv1, die Trennung von Zertifikatsverwendung pro Funktion, verpflichtende Passwort-Rotation nach jeder Krypto-Migration sowie der überfällige Umstieg von Perimeter-VPN auf identitätsbasierte Zero-Trust-Architekturen.

Quellen:

Check Point Blog: Hotfix für CVE-2026-50751
https://blog.checkpoint.com/security/check-point-releases-important-hotfix-for-vulnerabilities-in-deprecated-ikev1-vpn-protocol/

Rapid7: rapid7.com – CVE-2026-50751 & CVE-2026-0257 Threat Reports
https://www.rapid7.com/db/vulnerabilities/check-point-gaia-cve-2026-50751/
https://www.rapid7.com/blog/post/etr-rapid7-observed-exploitation-of-pan-os-globalprotect-authentication-bypass-vulnerability-cve-2026-0257/

BleepingComputer: Qilin-Attribution & FortiBleed-Berichterstattung
https://www.bleepingcomputer.com/news/security/fortibleed-credential-theft-campaign-linked-to-lynx-ransomware/

Palo Alto Networks Security Advisory
https://security.paloaltonetworks.com/CVE-2026-0257

Arctic Wolf: CVE-2026-0257 Analyse
https://arcticwolf.com/resources/blog/cve-2026-0257-pan-os-globalprotect-authentication-bypass/

SOCRadar: „FortiBleed — 86,644 Fortinet Firewalls Compromised“ https://socradar.io/blog/fortibleed-fortinet-firewalls-compromised/

Hudson Rock: „FortiBleed 75,000 Fortinet Firewalls Compromised“ https://www.hudsonrock.com/blog/fortibleed-75000-fortinet-firewalls-compromised-global-enterprises-exposed-claim-your-ethical-disclosure

The Hacker News: FortiBleed-Ransomware-Link
https://thehackernews.com/2026/07/fortibleed-credential-theft-linked-to.html

SecurityWeek: FortiBleed & Check Point Berichterstattung
https://www.securityweek.com/fortibleed-86000-fortinet-device-credentials-compromised/

Schwachstelle

Klue/Salesforce: Wenn OAuth-Tokens zum Datenabfluss werden

Nicht jeder Perimeter sieht aus wie ein VPN-Gateway. Im SaaS-Zeitalter besteht er aus OAuth-Tokens, Connected Apps und API-Berechtigungen, die oft weniger streng überwacht werden als menschliche Admin-Konten. Genau dieses Muster zeigte sich im Juni bei der Kompromittierung der Klue-Battlecards-Integration für Salesforce.

Klue ist eine Competitive-Intelligence-Plattform, die sich mit Salesforce verbindet, um Battlecards, Win/Loss-Daten und CRM-Kontext in Vertriebsprozesse einzubetten. Laut ReliaQuest wurde eine kompromittierte Klue-Integration genutzt, um über OAuth-Tokens und automatisierte REST-API-Abfragen Salesforce-CRM-Daten zu exfiltrieren. Eine Salesforce-Schwachstelle stand dabei nicht im Mittelpunkt; missbraucht wurde eine bereits vertrauenswürdige Drittanbieter-Verbindung. Salesforce deaktivierte die Klue-Battlecards-Verbindungen vorübergehend und erklärte, es gebe keinen Hinweis auf eine Schwachstelle in der eigenen Plattform.

Technisch lief der Angriff weitgehend innerhalb legitimer SaaS-Mechanismen: OAuth-Tokens, Objekt-Enumeration, Query- und QueryMore-Aufrufe über die Salesforce REST API. ReliaQuest beobachtete in einer Umgebung eine Abfragekette über fast 24 Stunden; in einem anderen Fall fast tausend API-Queries innerhalb von 15 Minuten. Damit wird der persistente OAuth-Refresh-Token zur modernen Variante des gestohlenen VPN-Zugangs — nur oft schlechter überwacht.

Der Vorfall ist Teil eines größeren SaaS-Supply-Chain-Problems: Drittanbieter-Apps besitzen dauerhaft Zugriff auf CRM-, Vertriebs- und Kundendaten, während ihre Berechtigungen selten regelmäßig überprüft werden. Cybersecurity Dive berichtete, dass unter anderem LastPass, Recorded Future und Tanium Zugriffe auf bestimmte CRM- bzw. Geschäftskontaktdaten bestätigten; ihre Kernprodukte seien nach bisherigem Stand nicht betroffen gewesen.

SaaS-Integrationen sind privilegierte Maschinenidentitäten. Jede Connected App mit Zugriff auf Salesforce, Microsoft 365, ServiceNow, GitHub oder Slack braucht Inventarisierung, Least-Privilege-Scopes, regelmäßige Token-Rotation, IP-Allowlisting, Monitoring auf ungewöhnliche API-Volumina und einen sauberen Offboarding-Prozess.

Der eigentliche Blind Spot liegt nicht in einem einzelnen Anbieter, sondern in der Annahme, dass eine einmal genehmigte Integration dauerhaft vertrauenswürdig bleibt.

ReliaQuest: „Klue Integration Abused in Salesforce Data Theft“
https://reliaquest.com/blog/threat-spotlight-integration-abused-in-crm-data-theft/

Cybersecurity Dive: „Klue investigating supply chain attack that targeted Salesforce integrations“
https://www.cybersecuritydive.com/news/klue-investigating-supply-chain-attack-salesforce-integrations/823532/

News

LiteLLM: Wenn das KI-Gateway selbst zum Einfallstor wird

LiteLLM ist ein Open-Source-Proxy und sitzt zwischen LLM-Anwendungen und den großen Modellanbietern, routet Anfragen, verwaltet API-Schlüssel und setzt Rate Limits durch. Genau diese zentrale Stellung im KI-Stack macht eine kürzlich bekanntgewordene Schwachstelle besonders brisant.

CVE-2026-42271 ist eine Command-Injection-Schwachstelle mit einem CVSS-Score von 8.7, die es jedem authentifizierten Nutzer erlaubt, beliebige Befehle auf dem Host auszuführen. Betroffen sind zwei Endpunkte, die eigentlich nur dazu gedacht waren, einen MCP-Server vor dem Speichern zu testen (POST /mcp-rest/test/connection und POST /mcp-rest/test/tools/list), die aber eine vollständige Serverkonfiguration inklusive command, args und env-Feldern für den stdio-Transport entgegennahmen. Die Endpunkte waren nur durch einen gültigen Proxy-API-Key geschützt und führten die stdio-Konfiguration als Subprozess aus; ein Rollencheck auf Admin-Rechte fehlte.

Richtig kritisch wird es in Kombination mit einer zweiten Lücke: Horizon3.ai verkettete CVE-2026-42271 mit CVE-2026-48710, einer „BadHost“ genannten Host-Header-Validierungslücke in der Starlette-Bibliothek, um die Authentifizierung vollständig zu umgehen und unauthentifizierte Remote Code Execution ganz ohne Zugangsdaten zu erreichen. Die CISA hat die Lücke inzwischen wegen Hinweisen auf aktive Ausnutzung in ihren Known-Exploited-Vulnerabilities-Katalog aufgenommen.

Wer nicht sofort patchen kann, sollte zumindest die betroffenen Endpunkte am Reverse Proxy oder API-Gateway blockieren, den Netzwerkzugriff auf vertrauenswürdige Segmente beschränken und alle vom Proxy verwalteten Zugangsdaten rotieren.

Ein weiteres Beispiel dafür, dass KI-Gateways längst kritische Komponenten sind und entsprechend rollenbasiert abgesichert und gepatcht werden müssen.

Horizon3.ai-Analyse zur Verkettung mit CVE-2026-48710: https://horizon3.ai/attack-research/vulnerabilities/cve-2026-42271-chained-with-cve-2026-48710/

GitHub Security Advisory (BerriAI/LiteLLM): https://github.com/advisories/GHSA-v4p8-mg3p-g94g, https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g

NVD-Eintrag: https://nvd.nist.gov/vuln/detail/CVE-2026-42271

CISA KEV-Katalog (Filter auf diese CVE): https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-42271

News

Der Patch-Tsunami von 2026

Wenn KI-Fuzzing das klassische Schwachstellenmanagement ertränkt

Manche Zahlen lassen sich nicht mehr wegdiskutieren. Der Juni-Patchday 2026 markiert, wie Dustin Childs von der Zero Day Initiative feststellt, seit er 2017 begonnen hat, CVEs zu zählen, den größten monatlichen Release dieser Zeit – der bisherige Rekord lag bei 177. Je nach Zählmethode kommen Microsoft-eigene 198 bis 208 CVEs zusammen; rechnet man, wie ZDI es tut, Chromium und andere Drittanbieter-Bugs hinein, erreicht die Gesamtsumme im Juni 571 CVEs, davon 38 als Critical eingestuft. Das ist kein Ausreißer. Ein Microsoft Security Engineer bringt es auf den Punkt: „Der 200+-CVE-Count ist keine Anomalie. Es ist die neue Baseline. KI-gestützte Schwachstellenfindung (Fuzzing, statische Analyse, Variantensuche) verkürzt den Zeitraum zwischen ‚ein Bug existiert‘ und ‚ein Bug wird gefunden‘ dramatisch.“ Die Asymmetrie zwischen automatisierter Forschung und manueller Verteidigung hat eine neue Qualität erreicht.

Besonders aufschlussreich ist CVE-2026-49160. Wie N-able berichtet, credited Microsoft OpenAIs Codex mit der Meldung von CVE-2026-49160, einem der drei publik gemachten Zero-Days des Monats. Technisch handelt es sich, wie das SANS Internet Storm Center erklärt, um eine „HPACK“-Kompressionsalgorithmus-Implementierung in HTTP/2 und HTTP/3, die zu einer „Kompressionsbombe“ führen kann, die exzessive Ressourcen verbraucht. Microsoft reagierte mit einer neuen Registry-Option: einer MaxHeadersCount-Registry-Einstellung, die Administratoren erlaubt, die Anzahl akzeptierter Header in HTTP/2- und HTTP/3-Anfragen zu begrenzen.

Das Problem bleibt nicht bei Windows. Dieselbe SANS-Analyse notiert, dass Microsoft Patches für 204 Schwachstellen veröffentlichte, davon 38 als kritisch eingestuft, und zusätzlich 360 verschiedene Chromium-Schwachstellen in den Edge-Browser übernommen – und zieht daraus den direkten Schluss: „Dies ist zweifellos ein geschäftigerer Patch Tuesday als üblich. Insbesondere die große Zahl gepatchter Chromium/Edge-Schwachstellen unterstreicht die Auswirkungen von KI-Werkzeugen auf die Schwachstellenfindung.“ Zeitgleich brannte es bei Cisco: die Cisco Catalyst SD-WAN Controller-Authentifizierung funktionierte nicht ordnungsgemäß, und im Mai 2026 wurde dem Cisco PSIRT eine begrenzte Ausnutzung dieser Schwachstelle bekannt – mit einem CVSS-Wert von 10.0. Die Enterprise-Landschaft ist heute so verzahnt, dass ein einziger Dienstag die Kapazität einer ganzen IT-Abteilung wochenlang bindet.

Der Zustand „vollständig gepatcht“ ist zur Fiktion geworden. Die strategische Antwort liegt in resilienten Architekturen: aggressives Network-Sandboxing und Mikrosegmentierung, kompensierende Kontrollen wie die Header-Begrenzung bei http.sys, und KI-gestütztes Patch-Testing auf Verteidigerseite. Die Zeit, in der Menschen im Monatstakt gegen Maschinen im Sekundentakt antraten, ist vorbei.

ZDI – „The June 2026 Security Update Review“
https://www.thezdi.com/blog/2026/6/9/the-june-2026-security-update-review

N-able – „June 2026 Patch Tuesday: A Record 198 CVEs…“
https://www.n-able.com/blog/june-2026-patch-tuesday-a-record-198-cves-three-zero-days-and-a-glimpse-of-the-ai-driven-future-of-vulnerability-research

SANS ISC – „Microsoft June 2026 Patch Tuesday“
https://isc.sans.edu/diary/33064

Cisco Security Advisory zu CVE-2026-20182
https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-sdwan-rpa2-v69WY2SW.html