Autor: Holger von Rhein

Kryptographie
Schwachstelle

50 Grad im Kühlregal und Risiken in der Solar-Cloud

In der Nacht vom 11. auf den 12. Oktober 2026 haben Angreifer die Kühlsteuerungen französischer Supermärkte manipuliert. Laut Wirtschaftsminister Roland Lescure traf es rund 700 der etwa 10.000 Supermärkte im Land (Stand: 13. Oktober), allein bei Intermarché rund 150 Filialen. Die Täter schalteten Kühl- und Tiefkühlmöbel in den Dauerabtaumodus, woraufhin die Temperaturen auf bis zu 50 Grad stiegen. Betroffen sind vor allem Danfoss-Controller der Serien AK-SM und AK-SC, darunter die Altgeräte AK-SM 800 (Supportende 2021) und AK-SC 355 (seit 2016 abgekündigt). Das CERT-FR warnt zusätzlich vor Controllern von Copeland und Dixell. Berichten zufolge traf es auch Märkte in Deutschland. Wie die Täter eingedrungen sind, ist offiziell ungeklärt. Bekannt waren Lücken aber schon vorher. Im August hatte Claroty Team82 im neueren AK-SM 800A einen versteckten Login-Mechanismus aufgedeckt, für die Altgeräte gab es bereits 2023 Warnungen. Trotzdem zählte Reuters nach dem Angriff noch mindestens 4.500 Danfoss-Bedienoberflächen, die offen im Internet erreichbar sind.

Davon unabhängig wurde am 7. Oktober eine Lücke in der Plattform iSolarCloud des Wechselrichterherstellers Sungrow bekannt. Ein Forscher, der mit der Sicherheitsfirma Jakkaru zusammenarbeitet, gelangte über einen Fehler im Login ohne Passwort bis in Administratorkonten. Laut dpa sind in Deutschland rund 250.000 Anlagen mit zusammen 7,8 Gigawatt an die Plattform angeschlossen. Sungrow schloss die Lücke im August binnen drei Tagen und sieht keine Hinweise auf Missbrauch.

Beide Fälle folgen demselben Muster. Die Steuerung ist nicht ins Firmennetz eingebunden, sondern über den Fernzugang eines Dienstleisters oder die Cloud des Herstellers mit dem Internet verbunden. Nicht selten fehlt sie dann im IT-Inventar. Ein einzelnes Gerät ist ein überschaubares Risiko. Laufen aber Hunderte Märkte oder Hunderttausende Anlagen über denselben Zugang, entsteht ein Schaden in der Fläche. Seit dem 11. September müssen Hersteller nach dem Cyber Resilience Act aktiv ausgenutzte Schwachstellen binnen 24 Stunden melden, auch bei Altgeräten ohne Support. Ob Danfoss gemeldet hat, ist nicht bekannt.

Es empfiehlt sich, bei Dienstleistern für Betriebstechnik (OT), etwa für Kühlanlagen oder Gebäudesteuerung, schriftlich bestätigen zu lassen, welche Steuerungen auf welchem Weg aus der Ferne erreichbar sind und welche Firmware darauf läuft. Geräte ohne Support gehören vom Netz. Geht das nicht, bleibt nur ein strikter Perimeter-Schutz, der klar regelt, von wo aus ein Zugriff erlaubt ist.

Wer die Wartung auslagert, bleibt trotzdem für den Zugang verantwortlich. Entscheidend ist deshalb zu wissen, welche Anlagen ein externer Techniker wann fernsteuern kann.

https://complexdiscovery.com/refrigeration-hack-affected-about-700-french-supermarkets-government-says-as-danfoss-interfaces-stay-online/

https://claroty.com/team82/research/freeze-the-controller-defrost-the-food-uncovering-vulnerabilities-in-danfoss-refrigeration-controllers

https://www.synacktiv.com/sites/default/files/2023-10/synacktiv-danfoss-sm800-sc255-sc355-auth-bypass.pdf

https://thehackernews.com/2026/10/attackers-heat-french-supermarket.html

https://www.cbsnews.com/news/cyberattack-supermarkets-refrigerators-france-fires-food-losses

https://cert.cyber.gouv.fr/alerte/CERTFR-2026-ALE-012

https://www.pv-magazine.de/2026/10/08/nach-hackerangriff-sungrow-schliesst-schwachstelle-in-seiner-isolarcloud/

https://www.tagesspiegel.de/wirtschaft/dpa-hacker-hatte-hunderttausende-solaranlagen-in-deutschland-lahmlegen-konnen-16137653.html

https://www.hlc.com/en/publications/eu-cyber-resilience-act-vulnerability-and-incident-reporting-obligations-now-apply

KI/ML

Google pausiert, Anthropic scannt: Bei KI-Funden wird die Prüfung knapp

Seit dem 1. Oktober 2026 nimmt Google in seinem Open-Source-Bug-Bounty (OSS VRP) vorerst keine neuen Meldungen zu Produktschwachstellen an. Als Grund nennt Google eine stark gestiegene Zahl automatisierter Einreichungen, die größtenteils ungültig seien. Meldungen zur Lieferkette und bereits eingereichte Fälle sind nicht betroffen. Ein Update ist für das erste Quartal 2027 angekündigt. Schon seit März verlangt Google für bestimmte Speicherfehler eine OSS-Fuzz-Reproduktion oder einen übernommenen Patch.

Das curl-Projekt hatte seine Geldprämien Ende Januar aus ähnlichem Grund eingestellt und nimmt Meldungen seit März wieder über HackerOne an. Im April beschrieb Maintainer Daniel Stenberg, wie sich die Lage seitdem verändert hat. Fast alle Meldungen seien inzwischen KI-gestützt und überwiegend brauchbar. Ihr Aufkommen ist allerdings etwa doppelt so hoch wie 2025.

Am 8. Oktober startete Anthropic den OSS Scanner. Open-Source-Projekte, die aufgenommen werden, erhalten kostenlos regelmäßige KI-Scans. Die Berichte gehen ohne menschliche Prüfung an die Maintainer und enthalten jeweils einen Reproduzierer und einen Patchvorschlag. Parallel läuft das bisherige Verfahren mit manuell geprüften Meldungen weiter. Die 90-Tage-Frist bis zur Veröffentlichung greift erst, wenn Anthropic einen Fund manuell bestätigt und die Maintainer darüber informiert hat.

Die Ausgangszahlen stammen aus einer sechsmonatigen Forschungsphase vor dem Start. Anthropic fand rund 29.000 mögliche Schwachstellen, konnte aber nur etwa 6.000 davon manuell sichten. Von 97 hoch oder kritisch eingestuften Funden erfüllten laut Anthropic 85 die Kriterien für eine koordinierte Offenlegung. Elf waren echte, aber bereits bekannte Fehler, einer war ungültig. Eine unabhängige Prüfung der Gesamtstatistik ist nicht dokumentiert.

Beide Fälle zeigen, wie begrenzt die Prüfkapazität ist. KI beschleunigt die Suche nach Schwachstellen, ihre Validierung und Behebung bleiben dagegen aufwendig.

Die Zahlen der Google Threat Intelligence Group (GTIG) passen dazu. Die monatlich veröffentlichten Schwachstellen stiegen von 5.045 im Januar 2026 auf 10.740 im August. Bei 141 davon beobachtete GTIG bis August eine aktive Ausnutzung. Das sind mehr als die 127 im gesamten Jahr 2025, aber nur rund 0,23 Prozent. Allein auf CVEs mit Bezug zum Linux-Kernel entfielen rund 5.000, ohne beobachtete Zero-Day-Ausnutzung. Den Zuwachs bei Angriffen führt GTIG vor allem auf bereits veröffentlichte Lücken zurück.

Die reine Zahl der CVEs sagt damit wenig über das Risiko aus. Strengere Nachweise und Limits je Absender können Meldeprogramme entlasten. Ein funktionierender Proof of Concept zeigt allerdings nur, dass sich ein Fehler auslösen lässt. Ob er im realen Einsatz erreichbar und damit sicherheitsrelevant ist, bleibt offen. Aussagekräftiger ist, wie schnell ausgenutzte Lücken in betroffenen Systemen geschlossen werden, und welche weiteren Lücken wegen ihrer Erreichbarkeit Vorrang bekommen.

Was das kostet, zeigt die Bank of America. Laut CEO Brian Moynihan holte die Bank im zweiten Quartal 1.000 externe Kräfte, die bis heute gemeinsam mit 3.000 eigenen Leuten Lücken in eigener und zugekaufter Software schließen. Gefunden haben diese Lücken KI-Modelle wie Anthropics Mythos. Für die Softwarefixes und die Geldwäsche-Compliance zusammen fielen im dritten Quartal laut Moynihan „a couple hundred million plus“ an. Heikel ist, dass Mythos in Tests von Anthropic bereits mehrere kleine Fehler zu einem schweren Angriff verkettet hat. Moynihan erwartet trotzdem sinkende Kosten, denn „once you patch, you don’t have to patch as much“. Entscheidend ist also nicht die Zahl der Funde, sondern die Kapazität, sie zu priorisieren und zu schließen.

https://cloud.google.com/blog/topics/threat-intelligence/vulnerability-discovery-and-exploitation-trends-in-the-ai-era

https://www.bleepingcomputer.com/news/google/google-halts-open-source-bug-bounty-program-amid-ai-spam-surge

https://www.heise.de/en/news/Google-temporarily-suspends-bug-bounty-program-for-open-source-11477829.html

https://thehackernews.com/2026/10/anthropic-launches-free-ai.html

https://www.helpnetsecurity.com/2026/10/09/anthropic-oss-scanner-ai-security-scans

https://betanews.com/article/anthropic-oss-scanner-free-mythos-bug-scans

https://www.csoonline.com/article/4230247/ai-accelerates-n-day-attacks-as-flaw-disclosures-and-exploits-double.html

https://siliconangle.com/2026/09/30/google-finds-vulnerability-disclosures-doubled-as-ai-changes-which-flaws-get-discovered/

https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/

https://www.anthropic.com/research/launching-opt-in-vuln-finding-service-for-open-source

https://bughunters.google.com/blog/ossvrp-rule-updates-2026

https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/

https://cybernews.com/news/bank-of-america-mythos

https://www.cnbc.com/2026/10/14/anthropic-mythos-bank-of-america-hiring-cost.html

Kryptographie

Classic McEliece verliert nach 55 Tagen seine BSI-Empfehlung

Seit dem 1. Oktober 2026 rät das BSI davon ab, den Kryptoalgorithmus Classic McEliece für Neuentwicklungen einzusetzen. Auslöser war ein Preprint vom August (IACR ePrint 2026/1630). Die Forscher zeigen darin, dass sich öffentliche McEliece-Schlüssel mit deutlich weniger Aufwand als gedacht von reinen Zufallsdaten unterscheiden lassen. Damit wird eine verborgene Struktur sichtbar, die Angreifern einen Ansatzpunkt bietet. Folgearbeiten schätzen den Aufwand für eine Schlüsselrückgewinnung auf 2⁹⁴ bis 2¹⁰² Bitoperationen. Laut heise entspricht das ungefähr dem Sicherheitsniveau von AES-128 statt des angestrebten AES-256. Diese Werte stammen aus Preprints, die teilweise noch kein Peer Review durchlaufen haben. Einen praktischen Angriff auf die Parameter der TR-02102-1 gibt es laut BSI nicht. Das Amt rechnet aber mit weiteren Fortschritten in der Kryptoanalyse. Das Team um Daniel J. Bernstein hält die Schätzungen für zu pessimistisch. ML-KEM und FrodoKEM sind nicht betroffen.

Das BSI hatte Classic McEliece nur im Hybridbetrieb empfohlen, also immer zusammen mit einem klassischen Verfahren. Ein Angreifer müsste beide Verfahren brechen, deshalb fängt die klassische Komponente die Schwächung ab. Hybridnutzer sind aktuell nicht gefährdet, ihre Sicherheit hängt jetzt aber im Wesentlichen am klassischen Verfahren. Für sich genommen empfiehlt das BSI klassische Schlüsseleinigung nur noch bis Ende 2031, für höchstsensitive Anwendungen bis Ende 2030. Bis dahin muss der Wechsel auf ML-KEM oder FrodoKEM abgeschlossen sein.

Am 12. Oktober haben BMI, BMDS und BSI außerdem die nationale PQC-Leitlinie veröffentlicht. Anwendungen mit hohem Risiko sollen bis Ende 2030 umgestellt sein, alle übrigen weitgehend bis 2035. Für McEliece-Hybride gilt trotzdem die frühere Frist (2030/31) aus der TR-02102-1. Die Leitlinie fordert ausdrücklich Kryptoagilität.

Mit einem gepflegten Kryptoinventar finden Sie alle Einsatzorte von Classic McEliece schnell und können die Ablösung sofort planen. Ohne Inventar bleibt nur die manuelle Suche. Beginnen Sie bei Herstellerprodukten und Bibliotheken mit BSI-Policy-Profilen, denn dort hat ein Dritter das Verfahren für Sie ausgewählt. Für jeden Treffer legen Sie den Wechsel auf ML-KEM oder FrodoKEM im Hybridmodus fest.

Erst im Juni hatte ISO das Verfahren Classic McEliece standardisiert. Zwischen Preprint (IACR ePrint 2026/1630) und Abkündigung durch das BSI lagen dann trotzdem nur 55 Tage. Beschaffung und Releases werden dagegen in Jahren geplant. Kryptoagilität muss deshalb ein fester Betriebsprozess mit vollständigem Inventar und klarer Zuständigkeit sein. Ein einmaliger Algorithmentausch reicht nicht. Eine einfache Frage zeigt, wie es bei Ihnen steht. Wer hat den Hinweis vom 1. Oktober erhalten, und was ist seitdem passiert?

BSI Classic McEliece Hinweis vom 1. Oktober 2026:
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Crypto/Notes_Classic_McEliece.pdf

BSI-Pressemitteilung vom 11. Februar 2026 zu den Fristen 2030 und 2031:
https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/260211_Ende_klassischer_Verschluesselungsverfahren.html

Leitlinie von BMI, BMDS und BSI zur EU-PQC-Roadmap:
https://www.bmi.bund.de/SharedDocs/downloads/DE/publikationen/themen/sicherheit/BMI26024-pqc.html

IACR ePrint 2026/1630: https://eprint.iacr.org/2026/1630

heise zu den Aufwandsschätzungen:
https://www.heise.de/en/news/Post-Quantum-Crypto-BSI-Concerned-About-McEliece-11478462.html

postquantum.com zur Gegenposition und zur ISO-Aufnahme:
https://postquantum.com/security-pqc/classic-mceliece-key-recovery-bsi/

postquantum.com zu den 55 Tagen: https://postquantum.com/post-quantum/crypto-agility-program/

News

Angreifer erbeuten beim Zertifizierer GUTcert Auditunterlagen von KRITIS-Betreibern

Bei der Berliner Zertifizierungsgesellschaft GUTcert haben sich nach Unternehmensangaben am 5. September 2026 Unbekannte Zugriff auf die Systeme verschafft. Vom 6. bis 9. September flossen rund 640 GB Daten ab. Entdeckt wurde der Angriff erst in der Nacht zum 10. September. Betroffen sind laut GUTcert unter anderem Auditberichte und Netzstrukturpläne. Auch Angaben zu Schwachstellen gehören dazu. Laut Fachpresse sollen zudem Betriebsstättenlisten mit Standorten von Umspannwerken und Gasdruckregelanlagen darunter sein.

GUTcert hat den Vorfall am 11. September der Berliner Datenschutzbeauftragten und dem LKA gemeldet und zusätzlich freiwillig das BSI informiert. Auf mehrere Erpressungsversuche ist das Unternehmen nach eigenen Angaben nicht eingegangen. Am 20. September schrieben die Angreifer Kunden und Auditoren von GUTcert direkt an und verschickten Links zu den gestohlenen Daten. Ob die Daten darüber hinaus veröffentlicht wurden, kann GUTcert weder bestätigen noch ausschließen. Zu den Kunden gehört der Darmstädter Versorger ENTEGA. ENTEGA hat bestätigt, dass ihre Netztochter e-netz Südhessen und das von ihr betriebene Müllheizkraftwerk Darmstadt Zertifizierungen bei GUTcert beauftragt hatten. Der Versorger hat den Vorfall als KRITIS-Betreiber selbst an das BSI gemeldet und lässt mögliche Leak-Seiten überwachen.

Der Fall zeigt ein strukturelles Problem. Netzbetreiber müssen sich nach dem IT-Sicherheitskatalog gemäß EnWG zertifizieren lassen. Für das Audit reichen sie genau die Unterlagen ein, die ein Angreifer zur Vorbereitung eines Angriffs braucht. Beim Prüfer liegen dann diese Unterlagen vieler Betreiber gebündelt an einem Ort. Weil Prüfer als Kontrollinstanz gelten, werden sie bei der Bewertung von Lieferanten leicht übersehen.

Unternehmen, die GUTcert beauftragt haben, sollten zunächst ihre eigenen Meldepflichten nach BSIG, NIS-2 und DSGVO prüfen. Die Meldung von GUTcert ersetzt keine eigenen Meldungen. Eine dokumentierte Bewertung schafft Klarheit, auch wenn am Ende keine Meldung nötig ist. Bis GUTcert geklärt hat, welche Dokumente betroffen sind, ist es sinnvoll, alle übermittelten Unterlagen als kompromittiert zu behandeln. Zudem ist mit gezieltem Phishing zu rechnen, das sich auf GUTcert oder konkrete Auditfeststellungen bezieht. Dass die Angreifer Kunden bereits direkt angeschrieben haben, macht das wahrscheinlich. ENTEGA zeigt mit der eigenen BSI-Meldung und der Überwachung möglicher Leak-Seiten, wie eine angemessene Reaktion aussehen kann.

Die Frage nach dem Verbleib von Auditunterlagen betrifft allerdings jedes Unternehmen, das sich zertifizieren lässt. Erst ein Überblick darüber, welche Dokumente bei welchem Prüfer liegen, macht das Risiko überhaupt bewertbar. Vertraglich lässt sich regeln, dass abgeschlossene Audit-Artefakte zurückgegeben oder gelöscht werden. Noch weiter geht die Remote-Sichtung, bei der Prüfer Unterlagen einsehen, ohne eine Kopie zu erhalten.

Auch Compliance hat eine Lieferkette. Wer sich auditieren lässt, gibt einen Teil seines Sicherheitsdesigns aus der Hand. Steuern lässt sich danach nur noch, wo die Unterlagen liegen und wie lange. Netzpläne, die nach Abschluss eines Audits ohne festes Löschdatum bei einem Prüfer lagern, sind damit ein Risiko, das in Lieferantenbewertungen leicht übersehen wird.

GUTcert, Pressemitteilung zum Cyberangriff
https://www.pressebox.de/pressemitteilung/gut-certifizierungsgesellschaft-fuer-managementsysteme-mbh/cyberangriff-auf-die-gutcert-gmbh/boxid/1313139

ENTEGA, Pressemitteilung zum Angriff auf GUTcert
https://www.entega.ag/aktuelles-presse/pressemeldungen/pressemeldung/pressemitteilung-zum-cyberangriff-auf-die-gutcert-gmbh-1/

IT-Administrator zu Datenmenge und Datenarten
https://www.it-administrator.de/datenleck-gutcert-kritische-infrastruktur-energienetz

energate messenger zu den betroffenen Netzbetreibern
https://www.energate-messenger.de/news/267259/cyberattacke-verursacht-grosses-kritis-datenleck

Borns IT- und Windows-Blog zur Zeitleiste und zu den Betriebsstättenlisten
https://borncity.com/blog/2026/09/20/hackerangriff-auf-die-gutcert-kundendaten-abgeflossen/

DIESEC zur Zertifizierungspflicht und zur freiwilligen Information des BSI
https://diesec.com/de/2026/10/gutcert-datenschutzverletzung-kritische-infrastruktur/

PrimeITler zur ungeklärten Veröffentlichung
https://www.primeitler.de/newsroom/gutcert-angriff-beim-zertifizierer-was-betriebe-jetzt-pruefen

News

14 Millionen Abfragen und niemand hat es gemerkt

Unbefugte haben aus dem dänischen Melderegister CPR Namen, Adressen und Personennummern von rund 8,8 Millionen Menschen abgerufen. Das gab das dänische Ministerium für Forschung, Bildung und Digitalisierung am 5. Oktober bekannt. Betroffen sind Lebende wie Verstorbene, zusammen etwa 80 % der im CPR erfassten Personen. In das Register selbst ist niemand eingebrochen. Die Täter nutzten den gesetzlich erlaubten Abfragezugang der kleinen IT-Firma Pays von der Insel Fünen. Laut den vorliegenden Unterlagen stellten sie vom 10. bis 20. September rund 14 Millionen automatisierte Abfragen, um gültige Personennummern zu finden. Entdeckt wurde der Datenabfluss erst am 2. Oktober, als eine ungewöhnlich hohe Rechnung auffiel.

Ein mutmaßlicher Täter sagte der dänischen Zeitung Politiken, er habe das geleakte Passwort eines ehemaligen Mitarbeiters genutzt. Es lautete „123456“. Fachleute halten seine Beteiligung für wahrscheinlich, denn er legte eine Datei mit über 8,7 Millionen Personennummern vor. Offiziell bestätigt ist das nicht. Politiken deckte allerdings auf, dass bei Pays mindestens drei Konten dieses Passwort nutzten, darunter das Administratorkonto.

Das schwache Passwort liefert die Schlagzeile. Schwerer wiegt, dass 14 Millionen Abfragen einer kleinen Firma niemandem auffielen, bis die Rechnung kam. Wer Partnern Zugang zu Registern oder APIs gibt, kann für jeden Partner ein erwartbares Abfragevolumen festlegen und ihn bei Abweichungen automatisch sperren. Ebenfalls lassen sich MFA für Partnerkonten und die Sperrung der Konten ehemaliger Mitarbeitender vertraglich festschreiben.

Ein legaler Zugang schützt nicht vor illegaler Nutzung. Würden Sie es bemerken, wenn ein Partner morgen das Hundertfache seiner üblichen Abfragen ausführte?

https://www.theregister.com/security/2026/10/13/123456-password-linked-to-denmark-data-breach-affecting-88m-people/5302726

https://thehackernews.com/2026/10/denmark-says-attackers-accessed-cpr.html

https://cphpost.dk/2026-10-09/news/round-up/hacker-retained-access-to-danish-cpr-register-for-nearly-22-days-before-breach-was-discovered/

https://cphpost.dk/2026-10-09/news/round-up/hacker-claims-simple-password-allowed-access-to-8-8-million-danish-cpr-numbers/

https://cphpost.dk/2026-10-10/news/round-up/123456-password-used-in-massive-danish-cpr-data-breach/

https://www.thelocal.dk/20261009/cybercriminal-claims-to-have-used-simple-password-to-hack-danish-cpr-system

https://www.malwarebytes.com/blog/news/2026/10/how-123456-became-the-key-to-almost-9-million-personal-records

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.