1. Die Werkzeugkette der KI-Entwicklung wird zur Angriffsfläche

Seit Dienstag, 1. September 2026 · zuletzt aktualisiert Mittwoch, 2. September 2026 · Score 89

Drei voneinander unabhängige Vorgänge binnen zwei Tagen betreffen dieselbe Schicht: gestohlene Sitzungstoken bei Claude-Konten, automatische Codeausführung durch Coding-Agenten beim Öffnen eines Repositorys und die aktiv ausgenutzte Langflow-Lücke CVE-2026-0768.

Letzte Entwicklung: Neu aufgenommen. Die Verbindung ist nicht die Technik, sondern die Position: KI-Werkzeuge sitzen zwischen Entwickler und Ausführungsumgebung, laufen mit weitreichenden Rechten und werden noch selten wie Produktionssoftware behandelt. Als Muster verdient das eigene Beobachtung.

2. Berliner Landesnetz: Frist der Erpresser endet übermorgen

Seit Montag, 17. August 2026 · zuletzt aktualisiert Dienstag, 1. September 2026 · Score 86

Die Gruppe Rhysida fordert 30 Bitcoin und droht mit der Veröffentlichung von 5,8 Terabyte, darunter 80.000 Ordnungswidrigkeiten-Akten und 6.000 Dokumente mit Zugangsdaten.

Letzte Entwicklung: Keine neuen Erkenntnisse seit dem 1. September. Die Frist endet am 4. September, das Land zahlt nicht. Betroffene Organisationen sollten die verbleibenden zwei Tage nutzen, um Meldewege festzulegen und Beschäftigte darauf vorzubereiten, dass kommende Betrugsversuche echte Vorgangsdaten enthalten.

3. Exchange CVE-2026-62911: 85 Prozent der deutschen On-Prem-Server verwundbar

Seit Donnerstag, 27. August 2026 · zuletzt aktualisiert Montag, 31. August 2026 · Score 74

Nach Veröffentlichung des Angriffscodes hatte das BSI den Patchstand erhoben.

Letzte Entwicklung: Keine neuen Zahlen. Der Punkt läuft als Verlaufshinweis mit, weil sich an der Ausgangslage nichts geändert hat: Für Exchange 2016 und 2019 gibt es Korrekturen nur im kostenpflichtigen ESU-Programm.

1.1 Dropbox-Konten über neu angelegte Lenovo-IDs übernommen

02.09.2026 · heise online

Zusammenfassung: Zwischen dem 4. und 21. August 2026 haben Unbefugte rund 5.000 Dropbox-Konten übernommen, für die keine Zwei-Faktor-Anmeldung eingerichtet war. Der Angriffsweg lief über Lenovo: Dort war es offenbar möglich, Lenovo-IDs für fremde E-Mail-Adressen anzulegen, ohne dass die Eigentümerschaft an der Adresse bestätigt werden musste. Wer eine zu einem Dropbox-Konto gehörende Adresse kannte oder erriet, legte dort ein Konto an und meldete sich damit bei Dropbox an. Aus weniger als einem Drittel der betroffenen Konten wurden tatsächlich Dateien heruntergeladen. Bloomberg berichtete zuerst über den Vorfall, woraufhin die Dropbox-Aktie nachgab. Das Unternehmen hat die Betroffenen darüber informiert, ob auf ihre Daten zugegriffen wurde, und kündigt an, zum 1. Januar die Nutzungsbedingungen zu ändern: Die Haftung für Authentifizierungsdienste Dritter und für Konten ohne aktivierte Zwei-Faktor-Anmeldung soll ausgeschlossen werden.

Hintergrund & Einordnung: Datenschutzrechtlich ist der Fall lehrreich, weil er die Grenzen der Verantwortungszurechnung auslotet. Der Fehler lag nicht bei Dropbox, sondern in der Kontoanlage bei Lenovo — dennoch ist Dropbox derjenige Verantwortliche, in dessen Systemen die unbefugte Kenntnisnahme stattfand, und damit derjenige, den die Pflichten aus Art. 33 und 34 DSGVO treffen. Die Konstruktion föderierter Anmeldung verteilt die Prüfung, aber nicht die Verantwortung: Wer eine Fremdanmeldung akzeptiert, übernimmt implizit die Qualität der Identitätsprüfung des anderen Anbieters. Genau darauf zielt die angekündigte AGB-Änderung, und genau dort wird sie rechtlich angreifbar. Ein vertraglicher Haftungsausschluss kann die zivilrechtliche Schadensersatzhaftung teilweise begrenzen, aber weder die datenschutzrechtliche Verantwortlichkeit nach Art. 5 Abs. 2 DSGVO noch die Pflicht zu angemessenen Maßnahmen nach Art. 32 DSGVO abbedingen; der Anspruch aus Art. 82 DSGVO ist ohnehin nicht dispositiv. Hinzu kommt die AGB-Kontrolle: Nach § 309 Nr. 7 BGB sind Haftungsausschlüsse für Vorsatz und grobe Fahrlässigkeit gegenüber Verbrauchern unwirksam. Bemerkenswert ist auch die Zahl von unter einem Drittel: Dass die Angreifer nicht überall Dateien abzogen, deutet eher auf automatisiertes Durchprobieren als auf gezielte Auswahl hin.

Praxisfolgen / Handlungsempfehlung: Für Verantwortliche, die Fremdanmeldung anbieten, folgt daraus ein konkreter Prüfauftrag: Welche Identitätsanbieter sind zugelassen, und auf welche Zusicherungen zur Adressverifikation stützen Sie sich dabei? Ein Anbieter, der Konten ohne Bestätigung der E-Mail-Adresse anlegt, ist als Anmeldeweg untauglich — das lässt sich vertraglich absichern und technisch prüfen, etwa über die im Token übermittelte Angabe zur Verifikation der Adresse. Wer solche Angaben nicht auswertet, akzeptiert unbestätigte Identitäten. Für Nutzerorganisationen gilt umgekehrt: Inventarisieren Sie, welche Fremdanmeldungen für Ihre Geschäftskonten überhaupt aktiviert sind, und deaktivieren Sie ungenutzte — jeder zusätzliche Anmeldeweg ist ein zusätzlicher Angriffspfad, unabhängig davon, ob Sie ihn nutzen. Und erzwingen Sie den zweiten Faktor, statt ihn zu empfehlen; in diesem Fall war er der einzige Unterschied zwischen betroffenen und nicht betroffenen Konten. Schließlich lohnt es, Änderungsmitteilungen zu Nutzungsbedingungen künftig auf Haftungsklauseln zu Anmeldeverfahren zu prüfen — die Dropbox-Klausel dürfte Nachahmer finden.

2.1 KI-Coding-Agenten führen beim Öffnen eines Repositorys fremden Code aus

02.09.2026 · heise online · git-Dokumentation zu core.fsmonitor

Zusammenfassung: Die Sicherheitsfirma Manifold hat dokumentiert, dass verbreitete KI-Coding-Agenten — genannt werden unter anderem Claude Code, Qwen Code und Goose — beim Öffnen eines Repositorys automatisch git-Befehle wie git status und git diff ausführen, um sich einen Überblick über das Projekt zu verschaffen. Das geschieht nach Darstellung der Forscher außerhalb der Sandbox und vor der Vertrauensfreigabe durch den Nutzer. Angreifer nutzen das über den git-Konfigurationsparameter core.fsmonitor, der ein externes Programm benennt, das git bei einer Aktualisierung des Index aufruft; ein dort hinterlegter Befehl wird damit ausgeführt, sobald der Agent das Projekt öffnet. Nachgebessert haben zum Zeitpunkt der Veröffentlichung Anthropic für Claude Code sowie Codex und Cursor; für Qwen und Grok lag kein Patch vor. Bei Anthropic verbleibt nach Angabe der Forscher eine verwandte Schwachstelle im Zusammenhang mit claude ultraview. Manifold gibt an, das Problem in mehr Agenten gefunden zu haben als in der Veröffentlichung genannt. Eine CVE-Kennung war zum Zeitpunkt der Veröffentlichung nicht vergeben.

Hintergrund & Einordnung: Der entscheidende Punkt für die Risikobewertung ist der Übertragungsweg, und er entlastet an einer wichtigen Stelle: Über git clone, pull oder fetch lässt sich eine manipulierte lokale Konfiguration nicht einschleusen, weil git die Datei .git/config nicht mitüberträgt. Gefährlich wird es, wenn ein Projekt als ZIP-Archiv weitergegeben und lokal entpackt wird — dann kommt das gesamte .git-Verzeichnis samt Konfiguration mit — oder wenn mehrere Personen auf einem geteilten Arbeitsverzeichnis mit vorkonfigurierten Einstellungen arbeiten. Das schränkt den Massenangriff ein, macht den gezielten Angriff aber nicht weniger wirksam: Ein zugesandtes Archiv mit der Bitte, „einmal kurz draufzuschauen“, ist ein realistisches Szenario, gerade bei Bewerbungen, Code-Reviews und Auftragsarbeiten. Der eigentliche strukturelle Befund liegt tiefer. Agenten führen Vorbereitungsschritte aus, bevor der Nutzer dem Projekt vertraut — die Vertrauensabfrage kommt zu spät. Das ist kein Fehler in einem einzelnen Werkzeug, sondern eine Konsequenz daraus, dass Kontextbeschaffung und Freigabe in der falschen Reihenfolge stehen. Dass mehrere Hersteller unabhängig voneinander betroffen sind, stützt diese Lesart.

Praxisfolgen / Handlungsempfehlung: Kurzfristig hilft eine Prüfung, die sich automatisieren lässt: Suchen Sie in .git/config nach Einträgen, die Programme aufrufen — neben core.fsmonitor sind das etwa core.pager, core.editor, diff.external und filter.*.clean. Für Projekte aus fremder Hand gehört diese Prüfung vor das erste Öffnen im Editor oder Agenten, nicht danach. Wer eigene Werkzeuge um git baut, sollte die automatischen Aufrufe härten: git -c core.fsmonitor=false status ist die vom Bericht genannte Minimalmaßnahme, sinnvoller ist es, alle konfigurierbaren Programmaufrufe explizit zu neutralisieren. Organisatorisch lautet die Regel: Fremde Projekte kommen per git clone aus einer benannten Quelle ins Haus, nicht als Archiv per Mail. Wo das nicht geht, gehört das Entpacken und erste Öffnen in eine Wegwerf-Umgebung. Und für die Werkzeugauswahl ergibt sich ein neues Kriterium: Fragen Sie Anbieter, an welcher Stelle im Ablauf die Vertrauensfreigabe greift und was der Agent davor bereits ausführt.

3.1 Langflow: CVE-2026-0768 wird aktiv ausgenutzt, über 350 Versuche dokumentiert

02.09.2026 · heise online · NVD · ZDI-26-034

Zusammenfassung: Sicherheitsforscher von VulnCheck beobachten laufende Angriffe auf Instanzen des KI-Werkzeugs Langflow, mit dem sich Agenten und Arbeitsabläufe bauen und betreiben lassen. Ausgenutzt wird CVE-2026-0768, eine Codeeinschleusung im Umgang mit dem code-Parameter des validate-Endpunkts: Eine vom Nutzer übergebene Zeichenkette wird ohne ausreichende Prüfung als Python-Code ausgeführt. Eine Authentifizierung ist nicht erforderlich, die Ausführung erfolgt im Kontext von root. Die Zero Day Initiative, die die Lücke als CNA führt, bewertet sie mit CVSS 9,8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) und ordnet sie CWE-94 zu; die zugehörige Meldung ist ZDI-26-034, die NVD-Veröffentlichung datiert auf den 23. Januar 2026, als betroffene Version ist 1.4.2 eingetragen. VulnCheck dokumentiert über 350 Angriffsversuche mit steigender Tendenz. Ein Patch steht seit Monaten bereit; viele Instanzen sind gleichwohl unverändert im Netz erreichbar.

Hintergrund & Einordnung: Der Fall ist weniger wegen der Technik bemerkenswert als wegen der Zeitachse. Zwischen der Veröffentlichung im Januar und der jetzt beobachteten Angriffswelle liegen über sieben Monate, in denen ein Patch verfügbar war. Das passt zu einem Muster, das sich bei selbst gehosteten KI-Werkzeugen häuft: Sie werden für ein Projekt aufgesetzt, oft von Personen ohne Betriebsverantwortung, laufen anschließend unbeaufsichtigt weiter und tauchen in keinem Patch-Zyklus auf. Verschärfend kommt hinzu, dass solche Instanzen typischerweise Zugangsdaten für Modell-APIs, Datenbanken und angebundene Dienste vorhalten — die Codeausführung mit Root-Rechten ist damit nicht das Ende des Angriffs, sondern der Anfang. Und Langflow ist an dieser Stelle kein neuer Name: Hier waren seit Juli bereits CVE-2026-55255 (Zugriff auf fremde Flows samt gespeicherter API-Schlüssel), CVE-2026-0770 und CVE-2026-9198 (CVSS 9,8, unauthentifizierte Codeausführung) Thema — alle drei im KEV-Katalog der CISA, alle drei mit verfügbarem Patch. Das ist die vierte aktiv ausgenutzte Lücke desselben Produkts binnen vier Monaten. Die Häufung spricht inzwischen sowohl für ein Produktproblem als auch für die allgemeinere Beobachtung, dass die Werkzeugschicht der KI-Entwicklung sicherheitstechnisch hinter der Anwendungsschicht zurückliegt.

Praxisfolgen / Handlungsempfehlung: Aktualisieren Sie auf die aktuelle Version und nehmen Sie die Instanz aus dem offenen Internet — für die meisten Einsatzzwecke genügt der Zugriff aus dem internen Netz oder über VPN. Weil die Ausnutzung Root-Rechte verschafft und seit Monaten läuft, ist bei einer exponierten, bislang ungepatchten Instanz von einer Kompromittierung auszugehen: Prüfen Sie auf unbekannte Prozesse, neu angelegte Benutzer, veränderte Startskripte und ausgehende Verbindungen, und rotieren Sie anschließend sämtliche in Langflow hinterlegten Zugangsdaten — Modell-APIs, Datenbankverbindungen, Webhooks. Unabhängig vom konkreten Produkt lohnt eine Bestandsaufnahme: Welche selbst gehosteten KI-Werkzeuge laufen in Ihrer Umgebung, wer betreibt sie, und sind sie im Patch-Management erfasst? Erfahrungsgemäß lautet die Antwort auf die letzte Frage nein.

3.2 Hoymiles schließt die unverschlüsselte Funkstrecke — auf Kosten offener Auslesewerkzeuge

01.09.2026 · heise online

Zusammenfassung: Der Chaos Computer Club hatte Anfang Juli offengelegt, dass die DTU-Implementierungen von Hoymiles keine Verschlüsselung umsetzen — weder im 868-MHz-Bereich noch bei den HM-Serien im 2,4-GHz-Band. Für den Zugriff auf einen Wechselrichter genügten die letzten acht Stellen der Seriennummer, und diese geben die Geräte auf Broadcast-Anfragen selbst preis. Der Hersteller liefert nun Sicherheitsupdates für die Mikrowechselrichter der HM- sowie der HMS/HMT-Serien aus, darunter Modelle wie HM-1000, HMS-600-2T und HMT-2000-4T. Wer sein Gerät mit der Cloud verbunden hat, erhält das Update nach Freigabe über die S-Miles-Home-App oder das Webportal innerhalb von zehn Werktagen automatisch; ohne Cloud-Anbindung ist ein Selbsthilfe-Formular auszufüllen. Nach dem Update ist die Kommunikation mit Drittanbieterprodukten für die offene Datenkommunikation wie OpenDTU oder AhoyDTU nicht mehr möglich. Eine künftige Zusammenarbeit mit diesen Projekten hat Hoymiles nicht angekündigt.

Hintergrund & Einordnung: Der Fall war hier am 17. Juli Thema, damals mit der Herstellerankündigung, das Update bis zum 30. August auszuliefern; dieser Termin wurde also im Wesentlichen gehalten. Neu und berichtenswert ist heute nicht das Update selbst, sondern seine Nebenwirkung. Die Lücke ist gravierender, als sie zunächst klingt. Wer ohne Authentifizierung mit einem Wechselrichter sprechen kann, kann ihn nicht nur auslesen, sondern beeinflussen — bei Anlagen im Verbund ist das eine Frage der Netzstabilität, nicht nur des Datenschutzes. Dass die Geräte ihre Seriennummer auf Broadcast-Anfragen selbst herausgeben, macht den zur Adressierung nötigen Schritt trivial. Der Konflikt, der jetzt entsteht, ist allerdings ein echter und nicht bloß ein Kommunikationsproblem: Die offene, unverschlüsselte Schnittstelle war zugleich die Grundlage dafür, dass quelloffene Werkzeuge Anlagendaten auslesen konnten, ohne den Umweg über die Hersteller-Cloud zu nehmen. Mit der Verschlüsselung entfällt diese Möglichkeit, und die Auswertung wandert zum Hersteller. Für Betreiber, die ihre Anlagendaten bewusst lokal halten wollten — ein durchaus datenschutzmotivierter Wunsch —, ist das Update deshalb kein reiner Gewinn. Besonders unangenehm ist die Lage für Anlagen ohne DTU-Anbindung: Dort braucht es zum Aktualisieren gegebenenfalls einen geliehenen oder gekauften Datensammler.

Praxisfolgen / Handlungsempfehlung: Für Betreiber ohne offene Auswertung ist die Sache einfach: Update freigeben und einspielen. Wer OpenDTU oder AhoyDTU einsetzt, sollte vorher entscheiden, wie es danach weitergehen soll — die Alternativen sind die Hersteller-Cloud, ein Auslesen an anderer Stelle im System, etwa am Wechselrichter-Ausgang oder über den Zähler, oder das bewusste Belassen auf dem alten Stand. Letzteres ist nur vertretbar, wenn die Funkstrecke räumlich schwer erreichbar ist, und auch dann eine Übergangslösung. Für Unternehmen mit größeren Anlagen gehört der Vorgang außerdem in die Lieferantenbewertung: Ein Hersteller, der eine offengelegte Lücke zwei Monate später schließt und dabei ohne Ankündigung eine etablierte Schnittstelle kappt, ist ein Planungsrisiko. Fragen Sie vor der nächsten Beschaffung nach dem Umgang mit offenen Protokollen und nach der Zusage, sie auch nach Sicherheitsupdates verfügbar zu halten.

3.3 Windows: außerplanmäßiges Baseline-Hotpatch im September erfordert Neustart

01.09.2026 · heise online

Zusammenfassung: Microsoft weicht beim Hotpatching vom veröffentlichten Zeitplan ab. Hotpatching erlaubt es, Sicherheitsupdates über mehrere Monate hinweg ohne Neustart einzuspielen; in regelmäßigen Abständen ist dafür ein Baseline-Update nötig, das einen Neustart erfordert. Ein solches war erst für Oktober 2026 vorgesehen. Nun hat Microsoft ein außerplanmäßiges Baseline-Update für September eingeschoben — das September-Update ist damit ein Standard-Update mit erforderlichem Neustart. Betroffen sind Organisationen, die Windows Autopatch mit aktiviertem Hotpatching einsetzen, sowie alle, die Hotpatches statt regulärer Updates beziehen. Die August-Updates waren ohne Neustart einspielbar; der nächste neustartfreie Patchday wird für November erwartet. Es ist die erste unplanmäßige Neustartpflicht seit Einführung des Verfahrens. Den Hotpatch-Kalender veröffentlicht Microsoft über die Windows-Release-Health-Kanäle.

Hintergrund & Einordnung: Die Meldung wirkt klein, hat aber eine Betriebsfolge, die leicht übersehen wird. Hotpatching wird gerade deshalb eingesetzt, weil Neustarts in bestimmten Umgebungen teuer sind — Terminalserver, Produktionssteuerung, Schichtbetrieb. Wartungsfenster werden entsprechend am veröffentlichten Kalender ausgerichtet und für neustartfreie Monate gar nicht erst eingeplant. Wenn eine unplanmäßige Neustartpflicht dazwischenkommt, ist das Ergebnis nicht ein verschobener Neustart, sondern ein nicht installiertes Sicherheitsupdate: Das Paket wartet auf einen Neustart, der nicht kommt, und die Systeme gelten in der Berichterstattung möglicherweise trotzdem als aktualisiert. Genau diese Diskrepanz zwischen „heruntergeladen“ und „wirksam“ ist der Punkt, an dem Patch-Management-Zahlen regelmäßig zu optimistisch ausfallen.

Praxisfolgen / Handlungsempfehlung: Prüfen Sie, ob Ihre Wartungsplanung für September ein Neustartfenster vorsieht, und ziehen Sie es nach, falls nicht. Kontrollieren Sie anschließend nicht den Installations-, sondern den Wirksamkeitsstand: Systeme, die auf einen ausstehenden Neustart warten, sind nicht geschützt. Grundsätzlich lohnt es, im eigenen Berichtswesen zwischen „Update heruntergeladen“, „Update installiert“ und „Neustart erfolgt“ zu unterscheiden — viele Auswertungen tun das nicht und melden dadurch eine Abdeckung, die es nicht gibt. Und behalten Sie den Hotpatch-Kalender in den Release-Health-Kanälen im Blick, statt sich auf den Rhythmus des Vorjahres zu verlassen; dieser Vorgang zeigt, dass er nicht garantiert ist.

6.1 Die Werkzeugkette der KI-Entwicklung als eigene Angriffsfläche

01.–02.09.2026 · Anthropic/Infostealer · KI-Agenten und git · Langflow

Zusammenfassung: Innerhalb von zwei Tagen sind drei voneinander unabhängige Vorgänge bekannt geworden, die dieselbe Schicht betreffen — nicht die Modelle, nicht die Anwendungen, sondern die Werkzeuge dazwischen. Erstens der Diebstahl von Anmelde-Sitzungen bei Claude-Konten durch Infostealer, mit der Folge, dass Anthropic Konten zwangsweise abmelden und hinterlegte Zahlungsmittel entfernen musste. Zweitens die Feststellung, dass Coding-Agenten beim Öffnen eines Repositorys git-Befehle außerhalb der Sandbox und vor der Vertrauensfreigabe ausführen und dadurch über einen präparierten Konfigurationseintrag fremden Code starten. Drittens die aktiv ausgenutzte Langflow-Lücke CVE-2026-0768, die ohne Authentifizierung zur Codeausführung mit Root-Rechten führt und für die seit Monaten ein Patch bereitsteht.

Hintergrund & Einordnung: Was die drei Fälle verbindet, ist nicht die Technik — Sitzungsdiebstahl, unsichere Voreinstellung und eine Codeeinschleusung haben wenig miteinander zu tun. Verbindend ist die Position im Aufbau. KI-Werkzeuge sitzen zwischen dem Menschen und der Ausführungsumgebung, sie brauchen dafür weitreichende Rechte, und sie werden in vielen Organisationen noch nicht wie Produktionssoftware behandelt. Ein Coding-Agent liest und schreibt Quelltext, führt Befehle aus und hat Zugriff auf Zugangsdaten der Entwicklungsumgebung. Ein Werkzeug wie Langflow hält Modell-Schlüssel, Datenbankverbindungen und Webhooks vor. Ein Chat-Konto trägt eine Zahlungsverbindung und einen Kontingentrahmen. Jedes dieser Elemente ist einzeln unspektakulär und zusammen ein lohnendes Ziel. Hinzu kommt die Geschwindigkeit der Verbreitung: Diese Werkzeuge kommen typischerweise über einzelne Entwickler ins Haus, nicht über Beschaffungsprozesse, und tauchen deshalb in Inventaren, Patch-Zyklen und Berechtigungskonzepten oft gar nicht auf. Die Langflow-Zahlen illustrieren das: sieben Monate zwischen Patch und Angriffswelle, und die Angriffe laufen trotzdem erfolgreich.

Praxisfolgen / Handlungsempfehlung: Der sinnvollste erste Schritt ist eine Bestandsaufnahme, nicht eine Maßnahme. Erfassen Sie, welche KI-Werkzeuge in Ihrer Organisation tatsächlich im Einsatz sind — Coding-Agenten, Workflow-Plattformen, lokale Modellserver, Browser-Erweiterungen —, wer sie betreibt und mit welchen Rechten sie laufen. Ordnen Sie diese Werkzeuge anschließend denselben Prozessen zu, die für andere Software gelten: Patch-Management, Zugriffskontrolle, Protokollierung, Offboarding. Drei Punkte verdienen dabei besondere Aufmerksamkeit, weil sie in allen drei Fällen dieser Woche eine Rolle spielten. Erstens die hinterlegten Geheimnisse: Welche Zugangsdaten liegen in diesen Werkzeugen, und lassen sie sich einzeln rotieren? Zweitens die Erreichbarkeit: Selbst gehostete KI-Werkzeuge gehören nicht ins offene Internet, auch nicht „vorübergehend zum Testen“. Drittens die Reihenfolge von Kontext und Freigabe: Werkzeuge, die Daten verarbeiten, bevor der Nutzer zustimmt, verlagern die Vertrauensentscheidung nach hinten — das ist bei der Auswahl abzufragen. Für die Bewertung insgesamt gilt: Drei Vorgänge in zwei Tagen sind eine Häufung, kein Beleg für eine Trendwende. Ob daraus ein dauerhaftes Muster wird, lässt sich erst über mehrere Wochen beurteilen; ich beobachte es hier weiter.