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

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

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

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.

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.

Meta-Fehler bei KI-Support: Angreifer kapern Instagram-Konten über automatisierte Kontowiederherstellung

Mehrere Quellen zeichnen ein konsistentes Bild: Angreifer nutzten Ende Mai und Anfang Juni 2026 eine Schwachstelle in Metas KI-gestütztem Account-Recovery- und Support-System für Instagram aus. Im Zentrum stand das interne bzw. erweiterte Support-Werkzeug „High Touch Support“ (HTS), das laut Meta als AI-assisted account recovery system fungierte. Statt eine klassische Sicherheitslücke in der Instagram-App selbst auszunutzen, zweckentfremdeten die Täter also den automatisierten Account-Wiederherstellungsprozess des KI-Chatbots.

Laut TechCrunch und 404 Media ließen sich die Angriffe offenbar dadurch durchführen, dass Metas AI-Support-Chatbot dazu gebracht wurde, eine neue E-Mail-Adresse zu einem Zielkonto hinzuzufügen beziehungsweise den Reset-Prozess anzustoßen. BleepingComputer berichtet ergänzend, dass HTS dabei unzureichend prüfte, ob die angegebene E-Mail-Adresse tatsächlich mit dem betroffenen Instagram-Konto verknüpft war. Das Problem lag also nicht nur in fehlender Verifikation, sondern in der Automatisierung einer hochsensiblen Entscheidung, die traditionell stärker abgesichert oder menschlich geprüft würde.

Der Vorfall fällt deshalb aus der Reihe, weil er weniger ein klassischer „Exploit“ als ein Beispiel für prozessuale Sicherheitsrisiken durch KI-gestützte Support-Automation ist. Wenn ein KI-System nicht nur informiert, sondern aktiv sicherheitsrelevante Kontofunktionen wie E-Mail-Änderungen oder Passwort-Resets anstoßen kann, wird der Support-Workflow selbst zur Angriffsfläche. Genau darin liegt die eigentliche sicherheitstechnische Relevanz des Falls: Nicht die KI „hackt“ das Konto, sondern sie wird zum fehlbaren Gatekeeper in einem Identity-Recovery-Prozess. Diese letzte Einordnung ist eine Schlussfolgerung aus den berichteten Abläufen. Ein schönes Bespiel für „Excessive Agency“ aus den „OWASP Top 10 LLM“.

Die Auswirkungen waren erheblich. Laut Meta wurden mehr als 20.000 Instagram-Konten kompromittiert; erste Berichte betrafen auch prominente oder begehrte Handles. BleepingComputer beschreibt zudem, dass betroffene Nutzer teils in automatisierten Recovery-Schleifen festhingen, weil auch die Wiedererlangung des Kontos stark auf automatisierte- und KI-gestützte Prozesse setzte. Meta erklärte, das Problem sei inzwischen behoben und betroffene Konten würden abgesichert.

Der Meta/Instagram-Fall ist vor allem deshalb bemerkenswert, weil er zeigt, dass KI-unterstützte Support- und Recovery-Systeme selbst zu einem sicherheitskritischen Vertrauensanker werden können. Für IT- und Security-Teams ist das ein Warnsignal: Sobald automatisierte Assistenten in Identitäts- oder Recovery-Prozesse eingebunden werden, müssen deren Prüfmechanismen genauso streng modelliert, getestet und abgesichert werden wie klassische Authentifizierungs- und Helpdesk-Prozesse.

https://www.bleepingcomputer.com/news/security/meta-ai-support-data-breach-affects-20-000-instagram-accounts/amp

https://www.404media.co/hackers-are-using-meta-ai-to-hijack-instagram-accounts

Weitere News im Juni

Dashlane-Angriff: Hacker erbeuten verschlüsselte Passwort-Tresore einzelner Nutzer

Dashlane ist ein Passwortmanager, der Passwörter, Passkeys, Zahlungsdaten und andere sensible Informationen in einem verschlüsselten digitalen Tresor speichert. Nutzer können damit Anmeldedaten geräteübergreifend verwalten und sich bei Websites und Apps sicher anmelden.

Mehrere Berichte zeichnen ein konsistentes Bild: Dashlane wurde Ende Mai 2026 Ziel einer Brute-Force-Kampagne gegen bestimmte Nutzerkonten, bei der Angreifer offenbar versuchten, 2FA-Codes bzw. Registrierungsprozesse für neue Geräte zu missbrauchen. Infolge der Attacke sperrte Dashlane zahlreiche Konten vorsorglich automatisch, um unbefugte Zugriffe zu unterbinden.

Laut den übereinstimmenden Berichten gelang es den Angreifern bei weniger als 20 Personal-Plan-Konten, ein neues Gerät zu registrieren und Kopien der verschlüsselten Passwort-Vaults herunterzuladen. Dashlane betont jedoch, dass es keine Hinweise auf eine Kompromittierung interner Systeme gebe und die gestohlenen Tresore weiterhin durch das Master-Passwort verschlüsselt seien.

Selbst bei Passwortmanagern zählt nicht nur die Sicherheit des Anbieters, sondern auch die Stärke des Master-Passworts, robuste MFA-Mechanismen und eine sichere Gerätebindung bleiben entscheidend.

https://www.helpnetsecurity.com/2026/06/05/dashlane-brute-force-attack-vaults-customer-accounts

https://www.securityweek.com/dashlane-brute-force-attack-leads-to-limited-encrypted-vault-downloads

Let‘s Encrypt plant Post-Quantum-Zertifikate ohne aufgeblähte TLS-Handshakes

Let‘s Encrypt bereitet den Übergang zu post-quantenfester Web-Authentifizierung vor und setzt dabei nicht auf klassische, deutlich größere PQ-Zertifikate, sondern auf sogenannte Merkle Tree Certificates (MTCs). Ziel ist es, das Web gegen künftige Quantenangriffe abzusichern, ohne TLS-Verbindungen durch zu große Zertifikatsketten und langsamere Handshakes unpraktisch zu machen.

Let’s Encrypt sieht bei der PQ-Umstellung vor allem ein Problem auf der Authentifizierungsseite der Web-PKI und bevorzugt mit MTCs einen Ansatz, der öffentliche Nachweisstrukturen per Merkle-Baum nutzt. Das passt auch technisch zu bestehenden Transparenzmechanismen im Zertifikatsökosystem und wird bereits im IETF-Umfeld als konkreter Standardisierungsansatz beschrieben.

Kurzfristig ändert sich für Website-Betreiber noch nichts, denn Let‘s Encrypt spricht eher von einem mehrstufigen Fahrplan als von einer sofortigen Umstellung.

Laut Let‘s Encrypt ist für Ende 2026 eine Staging-Umgebung geplant; heise fasst das als Teststart Ende 2026 zusammen. Eine produktionsreife Umgebung peilt Let’s Encrypt für 2027 an.

Wer tiefer in das Thema einsteigen möchte, findet im HiSolutions-Research-Blog weiterführende Beiträge zur Post-Quanten-Migration, zu Post-Quantum Cryptography (PQC) sowie zu den organisatorischen Voraussetzungen wie Krypto-Agilität und Kryptoinventarisierung bzw. einem Kryptokataster.

https://letsencrypt.org/2026/06/03/pq-certs

https://www.heise.de/news/Post-Quantum-ohne-aufgeblaehte-Handshakes-Let-s-Encrypts-neuer-Weg-11318855.html

Copy Fail, Dirty Frag, Dirty Pipe – Warum SELinux Ihr bester Schutz gegen Local Privilege Escalation ist

Copy Fail, Dirty Frag, Dirty Pipe: Unterschiedliche Exploits mit dem gleichen Ziel: Local Privilege Escalation (LPE). Diese Klasse von Verwundbarkeiten ist häufig anzutreffen. Wenngleich sie nicht so problematisch wie Remote Code Execution (RCE)-Schwachstellen sind, ermöglichen sie Angreifenden durch die Erhöhung der Rechte weitere Möglichkeiten zur Ausbreitung und zur Ausführung von Schadsoftware. Daraus lassen sich nun, je nach Bedarf, unterschiedliche Blickwinkel betrachten. Wir könnten technisch auf die Verwundbarkeiten eingehen und sie beschreiben. Auch spannend ist die Methodik der Sicherheitsforschenden, und ob und wie „künstliche Intelligenz“ dafür eingesetzt wurde. Oder wir könnten Unterschiede zu anderen Schwachstellen dieser Art hervorheben.

Aber in diesem Digest (und in unserer täglichen Arbeit) sind wir pragmatischer und stellen uns die Frage: Wie geht man mit diesen Schwachstellen um? Die Ausnutzung von Schwachstellen ist – außer bei bewusst implementierten Backdoors – auf die Existenz von Defekten angewiesen, sogenannten Bugs. Die Sicherheit eines Systems ist daher darauf angewiesen, dass alle Bestandteile von Hardwarelogik bis Applikation „korrekt“ funktionieren. Eine Möglichkeit, Fehler aufzufangen, ist die Verwendung von Mandatory Access Control (MAC) in Form der SELinux-Erweiterung. Dadurch können Policies festgelegt werden, die den Zugriff auf Dateien und Systemkomponenten festlegen. In dieser Konstellation reicht dann die Korrektheit der eingestellten Policies (und der SELinux-Implementierung), um einen sicheren Betrieb des Systems zu ermöglichen. Ein praktisches Beispiel bietet ein Blick auf Mobil-Betriebssysteme. GrapheneOS hat dazu einige erläuternde Hinweise.

Aus unserer Sicht unterstützen die Lücken unsere in einem vorherigen Digest formulierte Erwartung, dass sich das Security-Modell im Desktop- und Serverbereich sukzessive an das aus dem Mobilbereich anpassen wird. Auch wenn das Thema SELinux eher in den Aufgabenbereich der eingesetzten Distribution fällt, können Sie durch kleine Konfigurationen viel Angriffsoberfläche reduzieren. Sprechen Sie uns gerne an, wenn wir Sie dabei unterstützen können.

https://discuss.grapheneos.org/d/35110-grapheneos-is-protected-against-copy-fail-and-similar-vulnerabilities-by-selinux

https://en.wikipedia.org/wiki/SELinux

https://copy.fail

https://github.com/V4bel/dirtyfrag

https://infosec.exchange/@jrt/116537982697417546

Weitere News im Mai

Keine Publikation ohne AI

Gespannt kann man verfolgen, wie Daniel Stenberg (@bagder@mastodon.social) und das Open-Source-Projekt curl die Interaktion von KI-gestützten Werkzeugen mit Open-Source-Projekten erleben. Nach einer Welle von AI „Slop“, also KI-generierten Bugmeldungen ohne substanziellen Gehalt, welche zum temporären Schließen des Bug-Bounty-Programms führte, verzeichnet curl nun viele qualitativ hochwertige Meldungen. Im gleichen Post weist Daniel Stenberg aber auch darauf hin, dass dies ebenfalls eine höhere Last für Maintainer darstellt. Nutzen Sie dies doch als Motivation, in von Ihnen genutzten Projekten mitzuwirken oder finanziell zu unterstützen, um diese Belastung aufzufangen und die Möglichkeiten zur Verbesserung der Lösungen nutzbar zu machen.

Mythos, die von Anthropic hochgepriesene KI-basierte Exploit-Maschine, überzeugte beim Einsatz für curl weniger, vermutlich weil vorher verfügbare Werkzeuge schon viele Schwachstellen finden konnten. Für Entwickelnde und Interessierte eine empfehlenswerte Lektüre.

DE-Zone für DNSSEC nicht verfügbar

Am 05.05. kam es zu einem kurzzeitigen Ausfall innerhalb der DE-Zone (im DNS-Jargon sind damit die „.de“-Domains gemeint) aufgrund eines Konfigurationsfehlers beim Signieren. Blackfort-tec hat eine gute Zusammenfassung, und auch DENIC hat derweil ein Post-Mortem veröffentlicht. Eine schöne Erinnerung, welche Abhängigkeiten in unserer zentralisierten Infrastruktur bestehen. Frohes Threat-Modelling!

https://blackfort-tec.de/insights/dnssec-denic-servfail-nsec3-fehler-de-zone

https://blog.denic.de/analyse-des-dns-ausfalls-vom-5-mai-2026

Android Intrusion Logging: Mehr Visibility in der Mobile-Vorfallsbehandlung

Alle Jahre wieder spendiert Google seinem Betriebssystem eine neue Version. Mit den jährlichen Versionssprüngen kommen auch regelmäßig neue Security- und Privatsphäre-Funktionen hinzu.

Neben verbesserter Betrugserkennung bei Anrufen erweitert Google in diesem Jahr Androids Advanced Protection Mode (AAPM), vergleichbar mit Apples Lockdown Mode, um neue Funktionen für die forensische Analyse von Mobilgeräten. Historisch sind die Logdaten von Androiden nicht für die forensische Analyse entwickelt, sondern für das Beheben von Fehlern. Diese Zweckentfremdung hat einige Nachteile. Logs sind im Regelfall nicht manipulationssicher, und möglicherweise relevante Ereignisse aus Forensikperspektive werden nicht geloggt, wenn sie für die Fehlerbehandlung nicht wichtig sind. Mit Android Intrusion Logging schafft Android eine neue Datenquelle für die Analyse von Mobilgeräten. Wir empfehlen besonders exponierten Personen und Organisationen mit erhöhtem Schutzbedarf die Aktivierung des Android Advanced Protction Mode (AAPM). Organisationen können über den DevicePolicyManager das Logging ebenfalls aktivieren und an eine Applikation delegieren.

https://blog.google/security/whats-new-in-android-security-privacy-2026

https://security.googleblog.com/2025/05/advanced-protection-mobile-devices.html

https://developer.android.com/reference/android/app/admin/DevicePolicyManager#DELEGATION_SECURITY_LOGGING

Weitere News im April

BrowserGate: Clientseitige Telemetrie trifft Compliance

Die Webseite BrowserGate der Organisation Fairlinked wirft LinkedIn vor, beim Aufruf der Website systematisch auf installierte Browser-Erweiterungen zu prüfen und dabei zusätzliche Browser- bzw. Geräteinformationen zu erfassen und daraus ein weitreichendes Nutzerprofil abzuleiten. BleepingComputer hat wesentliche Teile der technischen Praxis unabhängig nachvollzogen. Demnach wurde beim Seitenaufruf ein Script geladen, das in Tests 6.236 Extensions per Resource-Probing prüfte und weitere Merkmale wie CPU-Kerne, Speicher, Bildschirmauflösung, Zeitzone, Spracheinstellungen und Batteriestatus erfasste. Nicht unabhängig verifiziert wurden dagegen die von Fairlinked behauptete konkrete Weitergabe der Ergebnisse an Dritte oder deren spezifische Nutzung.

LinkedIn bestreitet die Missbrauchs- bzw. „Spionage“-Deutung und erklärt, die Erkennung bestimmter Extensions diene dem Schutz der Plattform, der Durchsetzung der Nutzungsbedingungen, der Abwehr von Scraping sowie der Stabilität des Dienstes. Das Unternehmen erklärte außerdem, die Daten nicht zur Ableitung sensibler Eigenschaften von Mitgliedern zu verwenden.

In Europa wird in diesem Zusammenhang vor allem die Frage aufgeworfen, ob LinkedIn nach dem Digital Markets Act als „Gatekeeper“, also als Technologiekonzern mit besonderer Marktmacht, einzustufen ist, für den besondere regulatorische Vorgaben gelten. Diese Einordnung stammt bislang insbesondere aus dem Fairlinked/BrowserGate-Umfeld. Ob und in welchem Umfang daraus formelle Verfahren oder weitergehende Klagen entstehen, geben die Quellen nicht her.

Aus Compliance- und Security-Sicht zeigt der Fall, dass Extension-Scanning und Browser-Fingerprinting auch dann erhebliche Privacy-, Transparenz- und Governance-Risiken erzeugen können, wenn sie technisch mit Anti-Abuse-Zielen begründet werden. Ähnliche Techniken können zur Profilbildung und zum Tracking beitragen.

https://browsergate.eu

https://www.bleepingcomputer.com/news/security/linkedin-secretly-scans-for-6-000-plus-chrome-extensions-collects-data

https://www.linkedin.com/pulse/linkedin-accused-extensive-browser-surveillance-pdfze

https://www.msn.com/en-us/news/technology/browsergate-report-alleges-linkedin-scans-extensions-and-devices/ar-AA20kK5c

https://pipelab.org/blog/linkedin-browsergate-agent-fingerprinting

Quanten-Computer: Der Wendepunkt für Public-Key-Kryptografie ist erreicht

Noch vor wenigen Jahren galt der „quantum break of ECC“ als theoretisches Langzeitrisiko. Diese Einschätzung hat sich im März und April 2026 grundlegend geändert.

Auslöser ist eine ungewöhnlich dichte Abfolge belastbarer Signale aus Forschung und Industrie, zusammengefasst und klar eingeordnet von Filippo Valsorda (Kryptografie-Pionier und Betreuer der Kryptografie-Standardbibliothek der Programmiersprache Go). Seine zentrale Botschaft ist unmissverständlich: Die Migration zu Post‑Quantum‑Kryptografie ist kein strategisches Planungsprojekt mehr, sondern ein akutes Shipping‑Problem.

Nach Einschätzung von Filippo Valsorda erleben wir einen Risikokipppunkt. Selbst wenn sich einzelne Prognosen im Rückblick als zu pessimistisch erweisen sollten, ist Untätigkeit inzwischen die riskantere Entscheidung. Post‑Quantum‑Kryptografie ist seit 2026 weder Forschungs‑ noch Vorbereitungsthema – sie ist operative Sicherheitsarbeit.

https://words.filippo.io/crqc-timeline

Aktive Ausnutzung der Langflow-Schwachstelle CVE-2026-33017

In der Open-Source-Plattform Langflow, einem weitverbreiteten Werkzeug zum visuellen Erstellen und Betreiben von KI-Agenten und KI-Workflows, wurde im März 2026 eine kritische Sicherheitslücke unter der Kennung CVE-2026-33017 öffentlich bekannt. Die Schwachstelle ermöglicht es Angreifenden, ohne jegliche Authentifizierung beliebigen Programmcode auf betroffenen Servern auszuführen – ein Szenario, das in der Informationssicherheit als unauthentifizierte Remote Code Execution (RCE) klassifiziert wird und die höchste Risikostufe darstellt. Die US-amerikanische Cybersicherheitsbehörde CISA hat die Schwachstelle in ihren Katalog der nachweislich aktiv ausgenutzten Sicherheitslücken (Known Exploited Vulnerabilities, KEV) aufgenommen, was bedeutet, dass reale Angriffe in freier Wildbahn beobachtet wurden, und nicht lediglich ein theoretisches Risiko besteht.

Der technische Kern der Schwachstelle liegt in einem fundamentalen Design- und Implementierungsfehler im Zusammenspiel zwischen öffentlich zugänglichen Funktionen und der internen Code-Ausführung. Langflow bietet einen sogenannten „Public Flow Build“-Endpunkt an, der bewusst ohne Anmeldung erreichbar ist, damit öffentliche Flows – also vorgefertigte KI-Workflows – von externen Nutzern angestoßen werden können. Der Endpunkt ist absichtlich öffentlich gestaltet, weil er eine legitime Geschäftsfunktion – das Teilen und Ausführen öffentlicher Flows – bedient. Das eigentliche Versäumnis liegt darin, dass eine öffentlich zugängliche Funktion ausführbare, von außen kontrollierbare Definitionen annimmt und diese ohne ausreichende Validierung oder Isolation zur Ausführung bringt. Es handelt sich also um ein architektonisches Problem an der Schnittstelle zwischen Offenheit und Sicherheit.

Öffentlich zugängliche Funktionen, die „Code als Daten“ entgegennehmen und verarbeiten, stellen ein inhärent hohes Risiko dar. Die Kombination aus einem unauthentifizierten Endpunkt, der Annahme ausführbarer Definitionen von außen und einer fehlenden Sandbox bei der Code-Ausführung bildet genau jenes toxische Muster, das CVE-2026-33017 so gefährlich und so einfach ausnutzbar macht.

https://www.heise.de/news/Jetzt-patchen-Schadcode-Attacken-auf-KI-Tool-Langflow-beobachtet-11226852.html

https://www.cve.org/CVERecord?id=CVE-2026-33017

https://github.com/langflow-ai/langflow/security/advisories/GHSA-vwmf-pq79-vjvx

https://github.com/advisories/GHSA-rvqx-wpfh-mfx7

Iranische Hacker veröffentlichen private E-Mails von FBI-Direktor Kash Patel

Eine dem iranischen Staat zugerechnete Hackergruppe hat private E-Mail-Konten von FBI-Direktor Kash Patel kompromittiert und Teile der erbeuteten Korrespondenz öffentlich ins Netz gestellt. Das FBI hält technische Details zum konkreten Vorfall bislang zurück. Das US-Außenministerium reagierte mit einer öffentlichen Auslobung einer Belohnung von bis zu zehn Millionen US-Dollar für Hinweise, die zur Identifizierung oder Lokalisierung der verantwortlichen iranischen Cyber-Akteure führen.

Der Vorfall unterstreicht, wie staatlich gesteuerte Hackergruppen zunehmend persönliche Kommunikationskanäle hochrangiger Beamter ins Visier nehmen, um politischen Druck auszuüben. Selbst private Accounts von Entscheidungsträgern sind inzwischen ein erstrangiges Ziel geopolitisch motivierter Cyberoperationen.

https://therecord.media/fbi-confirms-theft-of-directors-personal-emails-iran-group

https://therecord.media/iran-hackers-state-department-reward

EU Top Officials & Signal

Politico berichtet, dass die Kommission eine Signal‑Gruppe hochrangiger Beamter auflösen ließ – präventiv, ohne bestätigte Kompromittierung.

Doch warum ist ausgerechnet Signal ein Problem – ein Messenger, der für seine starke Verschlüsselung bekannt ist? Die Antwort gilt nicht nur für Signal, sondern für nahezu alle privaten Messenger-Apps: Sie wurden für den persönlichen Gebrauch entwickelt und optimiert. Für den Einsatz in institutionellen Umgebungen – insbesondere in Regierungen und Behörden – fehlen ihnen entscheidende Funktionen:

  • zentrales User Management – Es gibt kein Onboarding/Offboarding durch IT-Administratoren.
  • Audit Trail – Es besteht keine nachvollziehbare Protokollierung von Aktivitäten.
  • Compliance-Archivierung – Es existiert keine rechtskonforme Aufbewahrung dienstlicher Kommunikation.
  • MDM-Integration – Private Messenger-Apps lassen sich als App per MDM verteilen, bieten aber keine nativen Enterprise‑Admin‑Funktionen wie zentrales User‑Management, Audit/Archive oder eDiscovery.
  • Geräte-Policy-Enforcement – Private Messenger-Apps selbst erzwingen keine institutionellen Richtlinien. Diese lassen sich nur über Geräte‑ und App‑Policies der MDM/EMM‑Plattform abbilden.
  • Sicherheitsfreigabe-Verknüpfung – Es erfolgt keine Kopplung an Freigabestufen oder Berechtigungskonzepte.
  • Kontrollierte Gruppenverwaltung – Es liegt keine abgesicherte Steuerung von Gruppenmitgliedschaften vor.
  • Forensische Auditierbarkeit – Es fehlt eine zentrale Auditierbarkeit/Archivierung. Forensik ist auf Endpoint‑Ebene möglich, aber stark vom Gerät und den Governance‑Rahmenbedingungen abhängig.

Kurz gesagt: Das Signal-Protokoll ist nicht das Problem. Das Problem ist, dass ein Werkzeug, das Einzelpersonen vor Überwachung schützen soll, für die gesteuerte und rechenschaftspflichtige Kommunikation einer Institution schlicht nicht vorgesehen ist.

https://www.politico.eu/article/top-eu-officials-signal-group-chat-hacking-fears