1. Cyberangriff auf das Berliner Landesnetz

Seit Freitag, 14. August 2026 · zuletzt aktualisiert Freitag, 21. August 2026 · Score 92

Zwei Senatsverwaltungen sind seit dem 17. August aus dem Landesnetz herausgetrennt, die Ermittlungen laufen unter Beteiligung von LKA, Staatsanwaltschaft und BSI. Der Vorfall trifft mit Wohngeld und „Bildung und Teilhabe“ unmittelbar sozialleistungsrelevante Verfahren.

Letzte Entwicklung: Am 21. August ist weiterhin offen, wann die Häuser wieder voll arbeitsfähig sind; die forensische Untersuchung dauert an. Nach Tagesspiegel-Informationen könnten weitere Häuser betroffen sein.

2. GitLab CVE-2026-19478 — von der Lücke zum laufenden Angriff

Seit Mittwoch, 19. August 2026 · zuletzt aktualisiert Donnerstag, 20. August 2026 · Score 84

Die am 19. August behandelte kritische GraphQL-Lücke wird inzwischen aktiv ausprobiert. Ein einziger HTTP-Aufruf ohne Anmeldedaten genügt, um in öffentlichen Projekten Repositories zu löschen, Merge-Einträge zu fälschen oder Maintainer zu entfernen.

Letzte Entwicklung: watchTowr meldet Angriffsversuche aus dem eigenen weltweiten Honeypot-Netz. Als Erkennungsmerkmal empfiehlt das Unternehmen die Suche nach der Zeichenkette @gl_introduced in den Web-Logs.

3. Aktiv ausgenutzte Lücken in Fernzugriffs- und Mail-Infrastruktur

Seit Freitag, 14. August 2026 · zuletzt aktualisiert Donnerstag, 20. August 2026 · Score 78

Der Schwerpunkt der laufenden Angriffe liegt weiterhin auf Systemen am Netzrand: macOS-Bildschirmfreigabe (CVE-2026-65400), VMware vCenter (CVE-2026-59310), Microsoft SharePoint und IKE.

Letzte Entwicklung: Neu hinzugekommen sind Zimbra Collaboration (CVE-2026-73570, seit dem 20. August bestätigt ausgenutzt) und TrueConf Server, das die CISA am 20. August mit zwei Einträgen in den KEV-Katalog aufgenommen hat. Für VMware vCenter ist inzwischen das Ausmaß bekannt: 361 kompromittierte Systeme in 47 Ländern, Deutschland an der Spitze.

1.1 E-Evidence-Verordnung seit 18. August vollständig anwendbar

18.08.2026 · Heuking: Der E-Evidence Act gilt · BfDI: E-Evidence-Verordnung

Zusammenfassung: Nach Ablauf der dreijährigen Übergangsfrist ist die Verordnung (EU) 2023/1543 seit dem 18. August 2026 unmittelbar in allen Mitgliedstaaten außer Dänemark anwendbar. Strafverfolgungsbehörden können elektronische Beweismittel über sogenannte EPOC- und EPOC-PR-Anordnungen direkt bei Diensteanbietern in anderen Mitgliedstaaten anfordern, ohne den Umweg über zwischenstaatliche Rechtshilfe. Adressaten sind Netzbetreiber, Internet-Anbieter, Hoster sowie Betreiber von Online-Shops und Plattformen. Die Reaktionsfristen sind teilweise sehr kurz; bei fehlender Umsetzungsbereitschaft drohen Bußgelder bis zu zwei Prozent des Jahresumsatzes. In Deutschland wurde das Ausführungsgesetz — das Elektronische-Beweismittel-Umsetzungs- und Durchführungsgesetz — im März 2026 verkündet.

Hintergrund & Einordnung: Die Verordnung ist bereits am 18. August 2023 in Kraft getreten; erst jetzt greift sie operativ. Zentrale Behörde in Deutschland ist das Bundesamt für Justiz, die technische Regulierung übernimmt die Bundesnetzagentur; der Datenaustausch läuft über einen interoperablen Zugangspunkt auf Basis des etablierten e-CODEX-Systems. Die flankierende Richtlinie (EU) 2023/1544 zur Benennung von Niederlassungen und Vertretern war bereits bis zum 18. Februar 2026 umzusetzen. Datenschutzrechtlich ist die Konstruktion nicht unumstritten: Eine Anordnung aus einem Mitgliedstaat wirkt unmittelbar gegenüber einem Anbieter in einem anderen, ohne dass dessen Behörden regelmäßig eingebunden sind — die Grundrechtsprüfung verlagert sich damit weitgehend in den anordnenden Staat.

Praxisfolgen / Handlungsempfehlung: Jeder Anbieter, der in der EU Kommunikations-, Hosting- oder Shop-Dienste erbringt, braucht jetzt einen definierten Prozess für eingehende Herausgabeanordnungen: benannte Empfangsstelle, Prüfschema für Zuständigkeit und Form, dokumentierte Fristenkontrolle und eine Eskalation für Fälle, in denen die Anordnung offensichtlich unverhältnismäßig ist. Wer Cloud-, Hosting- oder Kommunikationsdienste lediglich einkauft, sollte klären, welche seiner Daten bei welchem Anbieter liegen und wie dieser mit Anordnungen umgeht — das gehört in die Auftragsverarbeitungsvereinbarung und in die Transparenzinformationen nach Art. 13 und 14 DSGVO.

1.2 Österreichische Datenschutzbehörde verschickt Cookie-Sensibilisierungsschreiben

18.08.2026 · itwelt: Datenschutzbehörde kündigt amtswegige Überprüfung von Cookie-Bannern an

Zusammenfassung: Österreichische Unternehmen erhalten derzeit Schreiben der Datenschutzbehörde mit dem Betreff „Sensibilisierung durch die Datenschutzbehörde gemäß Art. 57 Abs. 1 lit. d DSGVO in Bezug auf Webseite …“. Die Behörde stützt sich auf ihre Zuständigkeit nach § 18 DSG sowie auf Art. 57 Abs. 1 lit. d und Art. 58 Abs. 1 lit. d DSGVO und weist darauf hin, dass ihr der Einsatz von Cookies und vergleichbaren Technologien auf der genannten Seite bekannt geworden sei. Für technisch nicht notwendige Cookies — Werbung, Tracking, Reichweitenmessung — sei eine wirksame Einwilligung erforderlich. Ein förmliches Prüfverfahren leitet die Behörde vorerst ausdrücklich nicht ein, sondern gibt Gelegenheit zur Selbstkorrektur.

Hintergrund & Einordnung: Der Schritt fügt sich in eine Reihe strenger österreichischer Entscheidungen. Im April 2026 hatte das Bundesverwaltungsgericht in einem von noyb angestoßenen Verfahren das Cookie-Banner des ORF beanstandet, weil der Button „Alle Cookies akzeptieren“ optisch deutlich hervorstach, während Ablehnung und Präferenzen zurücktraten. Im Juni 2026 bestätigte dasselbe Gericht, dass die Optionen im Banner gleichwertig dargestellt sein müssen. Aufsichtsrechtlich ist das Sensibilisierungsschreiben die niedrigste Eskalationsstufe: Es ist kein Bescheid und keine Anweisung — aber es dokumentiert Kenntnis. Wer nicht reagiert, riskiert eine förmliche Anweisung nach Art. 58 Abs. 2 lit. d DSGVO, und deren Nichtbefolgung war in einem früheren österreichischen Bußgeldfall der ausschlaggebende Punkt.

Praxisfolgen / Handlungsempfehlung: Deutsche Unternehmen mit österreichischer Website-Reichweite sollten das als Vorwarnung lesen. Prüfen Sie die erste Bannerebene auf Gleichwertigkeit: „Akzeptieren“ und „Ablehnen“ in gleicher Größe, Farbe und Position, keine zusätzlichen Klicks für die Ablehnung, kein voreingestelltes Häkchen. Prüfen Sie zweitens, ob vor der Einwilligung tatsächlich keine nicht notwendigen Skripte laden — das ist der häufigste Befund. Wer ein solches Schreiben erhält, sollte fristgerecht und schriftlich antworten und die vorgenommenen Änderungen belegen; ein unbeantwortetes Sensibilisierungsschreiben ist der schlechteste denkbare Ausgangspunkt für ein späteres Verfahren.

1.3 „CoSnitch“: Prompt Injection gegen Microsoft 365 Copilot vollständig geschlossen

20.08.2026 · heise: Sicherheitslücke in Microsoft 365 Copilot

Zusammenfassung: Das Sicherheitsunternehmen Varonis hat eine Angriffskette gegen Microsoft 365 Copilot offengelegt, die es unter dem Namen „CoSnitch“ führt. Versteckte Anweisungen auf einer Webseite, die der Assistent zusammenfassen sollte, schrieben sich dauerhaft in dessen Speicher. Anschließend gab Copilot auf Nachfrage Inhalte preis, die ihm über angebundene Konten zugänglich waren — E-Mail-Inhalte, Kalendereinträge, Zugangsdaten sowie Daten aus Gmail und Google Drive. Die abgegriffenen Informationen wurden Base64-kodiert und als gewöhnlicher HTTP-Verkehr ausgeleitet. Varonis meldete die Schwachstelle im Dezember 2025, eine erste Teilkorrektur folgte im Februar 2026, die vollständige Behebung erst am 18. August 2026. Eine CVE-Nummer wurde nicht vergeben.

Hintergrund & Einordnung: Der Fall ist kein Programmierfehler im klassischen Sinn, sondern eine strukturelle Eigenschaft von Assistenten, die fremde Inhalte verarbeiten: Für ein Sprachmodell sind Anweisung und Datum dasselbe Zeichenmaterial. Verschärfend kam hinzu, dass gezielte Fragen nach den eigenen Schutzmechanismen trotz formaler Ablehnung technische Details zur internen Architektur preisgaben — Ablehnung als Sicherheitsmaßnahme funktioniert nicht, wenn die Begründung der Ablehnung bereits die Information enthält. Die Zeitspanne von acht Monaten zwischen Meldung und vollständigem Fix ist der zweite Befund; die Teilkorrektur vom Februar 2026 hielt der Prüfung nicht stand.

Praxisfolgen / Handlungsempfehlung: Datenschutzrechtlich ist das ein Vorfall in der Auftragsverarbeitung, nicht in der eigenen Infrastruktur — mit der Folge, dass Verantwortliche über die Meldepflicht nach Art. 33 DSGVO nachdenken müssen, sobald Betroffenendaten im Zugriff des Assistenten standen. Praktisch heißt das: Berechtigungsumfang des Assistenten inventarisieren und auf das Erforderliche zurückschneiden, Anbindungen an Drittkonten (Google Workspace, private Postfächer) unterbinden, Speicher- und Erinnerungsfunktionen der Assistenten bewusst konfigurieren und Prompt Injection als eigenständiges Risiko in der Datenschutz-Folgenabschätzung führen. Für den Betrieb gilt: Ausgehenden Verkehr von KI-Diensten protokollieren — Base64 in HTTP-Parametern ist ein brauchbares Erkennungsmerkmal.

2.1 Sammel-Leak mit 1.033 aktiven Stripe-Händlerschlüsseln

18.08.2026 · Hudson Rock: Analyzing Stripe Vendors Breach · Security Affairs: 50.000 Stripe secrets leaked in public code

Zusammenfassung: Am 18. August veröffentlichte ein Akteur unter dem Namen „Satanic“ in einem einschlägigen Forum einen Datenbestand von gut 33 Gigabyte, der aus den Konten von rund 669 Händlern stammt, die den Zahlungsdienstleister Stripe nutzen. Enthalten sind 1.033 API-Schlüssel, viele davon mit dem Präfix sk_live_ für die produktive Zahlungsumgebung, dazu Kundendatensätze, Rechnungen, Transaktions-Metadaten, gehostete Rechnungslinks, Gutscheincodes und Teilangaben zu Zahlungskarten. Betroffen sind etwa 688.000 Personen; die Händler verteilen sich auf 42 Länder, mit Schwerpunkten in den USA (212), Großbritannien (81), Frankreich (57), Kanada (38), Brasilien (30) und Australien (27). Die Datensätze reichen vom 4. Januar 2022 bis zum 1. Juni 2026 und verteilen sich auf 17.654 Dateien. Gegenüber Hudson Rock erklärte der Akteur, die Veröffentlichung sei nur ein Bruchteil und er verfüge über rund 20.000 kompromittierte Schlüssel.

Hintergrund & Einordnung: Stripe selbst wurde nicht kompromittiert — die Schlüssel gehören den Händlern. Die Untersuchungen deuten darauf hin, dass sie aus öffentlich zugänglichem Code stammen: fest im Quelltext eingetragene Zugangsdaten in öffentlichen Repositories, unmaskierte Ausgaben in CI-Protokollen, frei erreichbare Konfigurationsdateien, schlecht geschützte Backups. Hudson Rock fand bei den untersuchten Händler-Domains keine Infostealer-Infektionen und vermutet automatisierte Werkzeuge, die das Netz nach erreichbaren .env-Dateien und Debug-Logs mit Klartext-Schlüsseln absuchen. Eine parallele Auswertung identifizierte insgesamt über 50.000 eindeutige Stripe-Schlüssel in öffentlichem Code, von denen ein relevanter Teil bei Stichproben noch aktiv war. Die Angaben zum Umfang schwanken je nach Quelle zwischen 33 und 35 Gigabyte sowie zwischen 659 und 669 Händlerkonten.

Praxisfolgen / Handlungsempfehlung: Wer Stripe einsetzt, sollte heute alle sk_live_-Schlüssel rotieren, das Dashboard auf unbekannte API-Aufrufe durchsehen und Git-Historie sowie CI-Protokolle nach eingecheckten Geheimnissen durchsuchen — eine gelöschte Datei entfernt den Schlüssel nicht aus der Historie. Strukturell gehört an diese Stelle ein Secret-Scanner im Repository und der Wechsel von Vollzugriffsschlüsseln auf eingeschränkte Schlüssel mit minimalem Umfang. Datenschutzrechtlich sind betroffene Händler Verantwortliche für die abgeflossenen Kundendaten: Prüfpflicht nach Art. 33 DSGVO binnen 72 Stunden, und angesichts der Kombination aus Name, Kontakt, Bestellung und Kartenfragmenten kommt eine Benachrichtigung der Betroffenen nach Art. 34 DSGVO ernsthaft in Betracht — die Daten eignen sich unmittelbar für zielgenaues Phishing.

2.2 Rust-Lieferkette: arrayref mit Build-Time-Dropper vergiftet

20.08.2026 · BleepingComputer: Hackers poison arrayref Rust crate · StepSecurity: Rust Supply-Chain Attack

Zusammenfassung: Angreifer haben das Veröffentlichungs-Konto hinter der Rust-Bibliothek arrayref übernommen und am 20. August die Version 0.3.10 publiziert. Diese brachte eine Abhängigkeit auf proc-macro1 1.0.107 mit — ein Typosquat der legitimen proc-macro2, das Beschreibung und Dokumentation des Originals kopierte. Über Rusts automatischen Build-Hook build.rs lud und startete das Paket während der Kompilierung eine entfernte Datei und führte damit Code auf Entwicklerrechnern aus. Innerhalb von 23 Minuten wurden zusätzlich append-only-vec und internment manipuliert. arrayref kommt über seine Lebenszeit auf rund 245 Millionen Downloads und steckt unter anderem unter tiny-skia, winit, blake3 sowie großen Teilen der Solana- und Ethereum-Werkzeugketten. Der Zeitablauf ist eng: 01:17 UTC Anlage eines GitHub-Kontos, das einen bekannten Rust-Entwickler nachahmt; 01:55 Veröffentlichung einer harmlosen proc-macro1-Kopie; 07:11 die bösartige Fassung; 07:15 arrayref 0.3.10; 07:54 Meldung; 08:03 Löschung von proc-macro1; 08:41 Entfernung von arrayref 0.3.10.

Hintergrund & Einordnung: Der Angriff ist deshalb bemerkenswert, weil der Kerncode der Bibliothek unverändert blieb. Wer den Quelltext las, sah nichts — die Bösartigkeit lag ausschließlich in der Abhängigkeit und im Build-Schritt. Damit versagt visuelle Code-Prüfung als Kontrolle vollständig; nur eine Abhängigkeits- und Build-Analyse hätte den Fund ergeben. Ziel war primär die Entwickler-Arbeitsstation: Ausgelesen wurden Anmeldedatenbanken von Chrome, Brave und Edge. CI/CD-Umgebungen, die im betroffenen Zeitfenster kompilierten, können Build-Zugangsdaten und Signaturschlüssel offengelegt haben. Forscher von Wiz weisen auf Überschneidungen der Infrastruktur mit jüngeren nordkoreanischen Lieferkettenangriffen hin, halten sich mit einer eindeutigen Zuordnung aber zurück. crates.io sperrte das betroffene Autorenkonto und geht davon aus, dass nicht der Betreuer selbst gehandelt hat, sondern dessen Rechner oder Zugangsdaten kompromittiert wurden. Die Quellenlage ist an einem Punkt widersprüchlich: Sie nennen unterschiedliche Betreuerkonten als kompromittiert.

Praxisfolgen / Handlungsempfehlung: Setzen Sie arrayref auf Versionen unterhalb 0.3.10 fest und prüfen Sie alle Builds aus dem Zeitfenster zwischen 07:15 und 08:41 UTC des 20. August. Rotieren Sie Anmeldedaten und Signaturschlüssel aus betroffenen Build-Umgebungen und lassen Sie Entwicklerrechner, die in diesem Fenster kompiliert haben, auf abgeflossene Browser-Zugangsdaten prüfen — die dort gespeicherten Passwörter gelten als offengelegt. Mittelfristig gehören zwei Maßnahmen in die Pipeline: verpflichtende Zwei-Faktor-Authentifizierung für alle Veröffentlichungs-Konten und eine Build-Isolierung, in der build.rs keinen Netzzugriff hat.

2.3 Password-Spraying: 155-facher Anstieg, MFA greift oft nicht

19.08.2026 · BleepingComputer: Password spraying attacks surge 155x · Huntress: Inside an Ongoing LSHIY Password Spray Attack

Zusammenfassung: Huntress beziffert den Anstieg von Password-Spraying über die eigene Kundenbasis auf mehr als das 155-Fache binnen sechs Monaten, mit einem aktuellen Mittelwert von rund 1.964 fehlgeschlagenen Angriffen pro Monat und geschütztem Mandanten. Die dokumentierte Kampagne — nach dem beteiligten Hoster „LSHIY“ benannt — führte zwischen dem 12. und 26. Juni 2026 mehr als 81 Millionen Anmeldeversuche durch und kompromittierte mindestens 78 Microsoft-Konten in 64 Organisationen. Angriffsziel war Microsofts Azure CLI. Entscheidend ist der Befund zur Mehrfaktor-Authentifizierung: Von 23 untersuchten betroffenen Organisationen hatten 15 MFA falsch konfiguriert — auf einzelne Anwendungen statt auf alle Cloud-Anwendungen, nur für Administratorgruppen oder mit Ausnahmen für „vertrauenswürdige Standorte“ — und acht hatten überhaupt keine MFA-Richtlinie. Die verwendeten Passwörter stammten aus früheren Leaks und waren nie gewechselt worden.

Hintergrund & Einordnung: Der technische Kern ist der ROPC-Ablauf im OAuth-Protokoll: Er schickt das Passwort direkt an den Token-Endpunkt, ohne dass ein interaktiver MFA-Dialog erscheint. Wer MFA über eine Richtlinie für bedingten Zugriff nur auf bestimmte Anwendungen anwendet, lässt diesen Pfad offen. Die Kampagne zeigt außerdem, wie beweglich solche Operationen sind: Nachdem der erste Hoster den Nutzer wegen Verstößen gegen die Nutzungsbedingungen sperrte, wanderte die Aktivität zu einem zweiten Anbieter mit IPv6-Bereichen — 87 Prozent der dort angegriffenen Konten waren zuvor schon vom ersten aus attackiert worden. Seit dem 15. Juli läuft die Aktivität über einen dritten Anbieter, nun langsam und verteilt über rund 12.800 IPv4-Adressen mit maximal etwa 900 Versuchen pro Adresse — erkennbar zur Umgehung von Erkennungsschwellen. Ein Wartungseintrag im angreifenden IPv6-Bereich wurde einen Tag vor Kampagnenbeginn angelegt; die Infrastruktur wurde also eigens bereitgestellt.

Praxisfolgen / Handlungsempfehlung: Prüfen Sie Ihre Richtlinien für bedingten Zugriff auf drei Punkte: Gilt MFA für „All Cloud Apps“ statt für eine Auswahl? Sind Legacy-Authentifizierung und ROPC blockiert? Existieren Standort- oder Gruppenausnahmen, die im Ernstfall genau den angegriffenen Pfad freigeben? Ergänzend gehört ein Abgleich der eigenen Domains gegen bekannte Leak-Sammlungen in den Regelbetrieb, verbunden mit erzwungenem Passwortwechsel für Treffer — die Kampagne lebt ausschließlich von nie rotierten Altdaten. Für die Erkennung ist das langsame Muster relevant: Schwellenwerte, die auf Versuche pro IP-Adresse abstellen, greifen bei 900 Versuchen über 12.800 Adressen nicht; sinnvoller sind Auswertungen pro Konto und pro Autonomem System.

3.1 Citrix schließt kritische Anmeldungsumgehung in NetScaler ADC und Gateway

20.08.2026 · heise: Citrix stopft kritische Anmeldungsumgehung

Zusammenfassung: Citrix hat Aktualisierungen für NetScaler ADC und NetScaler Gateway veröffentlicht. Die schwerwiegendere Lücke CVE-2026-19490 (CVSS 9,3) erlaubt es, die Authentifizierung zu umgehen oder unvorhersehbares Verhalten auszulösen; betroffen sind Installationen mit bestimmten administrativen Konfigurationen, die SAML-basierte Identitätsprüfung für den Fernzugriff nutzen. Daneben wurde CVE-2026-19489 (CVSS 8,8) behoben, ein Speicherüberlauf bei aktiviertem SIP-ALG in Large-Scale-NAT-Konfigurationen, der zu Dienstverweigerung oder unerwartetem Systemverhalten führen kann. Fehlerbereinigt sind die Versionen 14.1-73.32 und 13.1-63.21, für die FIPS-Varianten 14.1-73.32 FIPS sowie 13.1-37.277. Cloud-gehostete Instanzen hat Citrix bereits aktualisiert; selbstverwaltete Installationen müssen manuell nachziehen.

Hintergrund & Einordnung: NetScaler-Systeme stehen seit Jahren im Zentrum von Angriffen auf Unternehmensnetze, weil sie den Fernzugriff terminieren und damit unmittelbar Zugang zu internen Ressourcen vermitteln. Zuletzt war im Juli eine Citrix-NetScaler-Lücke aktiv ausgenutzt worden, teils bereits vor Verfügbarkeit des Patches. Für die neuen Schwachstellen liegen bislang keine Berichte über Ausnutzung vor — das ist bei dieser Produktklasse jedoch erfahrungsgemäß eine Frage von Tagen, sobald Details öffentlich sind. Die Einschränkung auf SAML-Konfigurationen reduziert die Angriffsfläche nur scheinbar: Föderierte Anmeldung ist in größeren Umgebungen der Regelfall.

Praxisfolgen / Handlungsempfehlung: Aktualisieren Sie selbstverwaltete Installationen zeitnah auf die genannten Versionen und prüfen Sie, ob Ihre Konfiguration die in der Herstellermeldung genannten SAML-Voraussetzungen erfüllt. Unabhängig vom Patch-Stand empfiehlt sich eine Durchsicht der Sitzungsprotokolle auf Anmeldungen ohne vorangegangene Authentifizierungsereignisse sowie eine Rotation der Sitzungs- und Signaturschlüssel, falls Zweifel am Zeitpunkt der Kompromittierung bestehen. Für FIPS-Varianten gelten eigene Versionsstände — verwechseln Sie sie nicht mit den Standardbuilds.

3.2 GitLab CVE-2026-19478 wird angegriffen

20.08.2026 · heise: Angriffsversuche auf GitLab-Lücke beobachtet

Zusammenfassung: Die am 19. August behandelte kritische Lücke in der GraphQL-Schnittstelle von GitLab (CVE-2026-19478, CVSS 9,4) wird inzwischen real ausgenutzt. Nicht authentifizierte Angreifer können mit einer einzigen HTTP-Anfrage ohne Anmeldedaten und ohne Nutzerinteraktion in öffentlichen Projekten weitreichende Aktionen auslösen: Projekte löschen, deren Status ändern, ganze Repositories entfernen, Merge-Einträge fälschen und Maintainer entfernen. Das Sicherheitsunternehmen watchTowr bestätigt Angriffsversuche aus seinem weltweiten Honeypot-Netz. Als Erkennungsmerkmal nennt das Unternehmen die Zeichenkette @gl_introduced in Web-Logs, die auf Erkundung oder Angriffsaktivität hindeutet. Die außerplanmäßigen Updates erschienen am Montag, dem 20. August; die Angriffe waren am Mittwoch bestätigt. Eine zweite, hoch eingestufte Lücke (CVE-2026-19650, CVSS 7,1) betrifft ebenfalls GraphQL, erfordert aber eine Interaktion des Opfers.

Hintergrund & Einordnung: Bemerkenswert ist die Entstehungsgeschichte des Angriffswissens: watchTowr rekonstruierte die Lücke nach eigenen Angaben mit einem KI-Werkzeug allein aus der Fehlerbeschreibung und den Code-Änderungen zum Zeitpunkt der Veröffentlichung — bevor öffentliche Exploits existierten. Damit verkürzt sich das Zeitfenster zwischen Patch-Veröffentlichung und funktionsfähigem Angriff erneut, und zwar systematisch: Der Patch selbst ist die Anleitung. Für Verteidiger heißt das, dass die alte Faustregel „patchen, bevor ein Exploit existiert“ praktisch keinen Vorlauf mehr bietet.

Praxisfolgen / Handlungsempfehlung: Spielen Sie die außerplanmäßigen Updates sofort ein, falls das noch aussteht. Durchsuchen Sie anschließend rückwirkend die Web-Logs nach @gl_introduced und prüfen Sie in öffentlichen Projekten die Integrität: gelöschte oder umbenannte Repositories, unerwartete Änderungen an der Maintainer-Liste, Merge-Einträge ohne zugehörigen Review. Da ein einziger Aufruf genügt, ist die Wahrscheinlichkeit hoch, dass Erkundungsversuche bereits vor der bestätigten Ausnutzung stattgefunden haben. Wo Repositories nicht öffentlich sein müssen, ist der schnellste wirksame Schritt, sie auf privat zu stellen.

3.3 Zimbra Collaboration: SNMP-Lücke wird aktiv ausgenutzt

20.08.2026 · BleepingComputer: Critical Zimbra RCE flaw now actively exploited · The Hacker News: Attackers Exploit Zimbra SNMP Flaw

Zusammenfassung: CERT Polska meldet die aktive Ausnutzung von CVE-2026-73570 (CVSS 8,9) in Zimbra Collaboration. Die Schwachstelle liegt in der SNMP-Überwachungskomponente: Wegen unzureichender Bereinigung nicht vertrauenswürdiger Eingaben bei der Verarbeitung von SNMP-Benachrichtigungen kann ein nicht authentifizierter Angreifer über speziell gestaltete SMTP-Anfragen beliebige Betriebssystembefehle mit den Rechten des Nutzers zimbra ausführen. Betroffen sind Installationen vor Version 10.1.20, bei denen das optionale Paket zimbra-snmp installiert und SNMP-Benachrichtigungen über den Parameter snmp_notify aktiviert sind sowie der Dienst swatchdog läuft — letzterer ist standardmäßig aktiv. Zimbra hatte die Lücke bereits am 20. Juli mit Version 10.1.20 geschlossen. CERT Polska hatte am 17. August die Warnung 145/2026 veröffentlicht und meldete am 20. August die Ausnutzung samt Kompromittierungsindikatoren. Shadowserver zählt über 12.100 aus dem Internet erreichbare Zimbra-Server, davon 4.382 in Europa und 4.492 in Asien.

Hintergrund & Einordnung: Zimbra-Server sind ein wiederkehrendes Ziel staatlich gestützter Akteure — dokumentiert sind Kampagnen russisch und chinesisch zugeordneter Gruppen gegen Militär- und Regierungseinrichtungen — sowie finanziell motivierter Krimineller. Der KEV-Katalog der CISA führt bereits 18 Zimbra-Schwachstellen, vier davon in diesem Jahr aufgenommen; CVE-2026-73570 ist bislang nicht darunter. Die Konstellation ist typisch für den Fall „Patch da, Systeme nicht“: Zwischen Verfügbarkeit des Updates am 20. Juli und der bestätigten Ausnutzung am 20. August lag ein voller Monat.

Praxisfolgen / Handlungsempfehlung: Aktualisieren Sie auf 10.1.20 oder neuer. Wo das nicht sofort möglich ist, deaktivieren Sie SNMP-Benachrichtigungen als Übergangsmaßnahme. Zur Kompromittierungsprüfung empfiehlt CERT Polska: Suche nach unerwarteten Dateien, die der Nutzer zimbra in den letzten 30 Tagen in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ oder /tmp/ angelegt hat, sowie Auswertung von /var/log/zimbra.log auf Dienststatus-Meldungen, bei denen eine Komponente von „stopped“ auf „running“ oder umgekehrt wechselt. Unerwartete Dateien in den Jetty-Pfaden sind ein starkes Indiz für Web-Shells.

3.4 CISA nimmt zwei TrueConf-Server-Lücken in den KEV-Katalog auf

20.08.2026 · CISA: Adds Two Known Exploited Vulnerabilities to Catalog

Zusammenfassung: Die US-Cybersicherheitsbehörde CISA hat am 20. August zwei Schwachstellen im TrueConf Server in den Katalog bekannter ausgenutzter Schwachstellen aufgenommen: CVE-2026-72529 (fehlende Authentifizierung bei einer kritischen Funktion) und CVE-2026-72530 (Code Injection). Grundlage sind Belege für aktive Ausnutzung. Die Behörde weist darauf hin, dass diese Schwachstellentypen ein häufiger Angriffsvektor sind und ein erhebliches Risiko für Bundesbehörden darstellen. Insgesamt kamen im Katalog in den letzten 30 Tagen 24 neue Einträge hinzu; die Remediation-Fristen sind unter der Direktive BOD 26-04 zuletzt sehr kurz bemessen — teilweise nur drei Tage.

Hintergrund & Einordnung: TrueConf ist eine Konferenz- und Kollaborationsplattform, die häufig on-premises betrieben wird, um Videokonferenzen nicht über externe Cloud-Dienste laufen zu lassen — also gerade in Umgebungen mit erhöhtem Vertraulichkeitsanspruch. Die Kombination aus fehlender Authentifizierung und Code Injection ist die ungünstigste denkbare: Der erste Fehler öffnet die Tür, der zweite erlaubt die Ausführung. Für europäische Betreiber ist der KEV-Eintrag kein rechtlich bindendes Signal, wohl aber ein belastbarer Nachweis dafür, dass die Ausnutzung nicht theoretisch ist.

Praxisfolgen / Handlungsempfehlung: Prüfen Sie, ob TrueConf Server in Ihrer Umgebung betrieben wird — solche Systeme laufen häufig unter der Verantwortung von Fachabteilungen und tauchen in zentralen Inventaren nicht auf. Falls ja: Herstellerupdates einspielen, die Erreichbarkeit aus dem Internet prüfen und, wo möglich, den Zugriff auf VPN oder bekannte Netzbereiche einschränken. Nutzen Sie den KEV-Katalog generell als Priorisierungsgrundlage — er ist die belastbarste öffentlich verfügbare Liste tatsächlich angegriffener Schwachstellen.

4.1 OLG Koblenz: „Unübliches Verbrauchsverhalten“ taugt weder zur Drosselung noch zur Kündigung

OLG Koblenz · 30.07.2026 · 2 UKl 4/25 · CSA-Aufbereitung ur-627 · Urteils-PDF · Verbraucherzentrale NRW

Sachverhalt: Die 1&1 Telecom GmbH bewirbt Mobilfunktarife mit „Unbegrenztes Datenvolumen“, „Surfen, Chatten, Mailen – ohne Limit“ und „Unlimitierte GB“. In der Leistungsbeschreibung sagt Ziffer 14 zunächst ein monatliches Volumen von mindestens 50 Gigabyte zu. Ziffer 15.3 unter der Überschrift „Exzessive Nutzung des Datenvolumens“ bestimmt jedoch, dass diese Tarife „ausschließlich der üblichen Nutzung von Endkunden bei 1&1 mit demselben Tarif“ dienen; bei „unüblichem Verbrauchsverhalten“ folgt zunächst ein Hinweis, bei erneuter Überschreitung die Drosselung oder Einstellung der Datenübertragung. Ein zweiter Absatz erlaubt ab dem Zehnfachen der „üblichen Nutzung“ die außerordentliche Kündigung. Die Verbraucherzentrale Nordrhein-Westfalen mahnte im März 2025 ab und klagte nach ausbleibender Reaktion nach dem Unterlassungsklagengesetz; verhandelt wurde am 9. Juli 2026.

Entscheidung: Der 2. Zivilsenat verurteilte 1&1, beide Absätze der Klausel gegenüber Verbrauchern nicht mehr zu verwenden — bei Meidung eines Ordnungsgelds bis 250.000 Euro — und zur Erstattung von 260 Euro Abmahnkosten nebst Zinsen. Der Streitwert wurde auf 5.000 Euro festgesetzt, 2.500 Euro je selbständiger Teil-Klausel. Die Revision ließ der Senat nicht zu; das Urteil ist rechtskräftig.

Begründungs-Kernpunkte: Erstens Intransparenz nach § 307 Abs. 1 Satz 2 BGB: Aus der Klausel geht nicht hervor, welches Datenvolumen dem Verbraucher zusteht und ab wann ihm Drosselung droht. Eine Regelung, wie die „übliche Nutzung“ ermittelt wird, fehlt; 1&1 verstand darunter den laufend schwankenden Durchschnitt der eigenen Kunden im selben Tarif. Der Senat weist auf einen Widerspruch im eigenen Klauselwerk hin: Liegt der Durchschnitt unter den in Ziffer 14 zugesagten 50 Gigabyte, wäre schon die Nutzung des vertraglich Versprochenen „unüblich“. Der vorgesehene Hinweis heilt nichts — „der Kunde muss bereits bei Abschluss des Vertrages erkennen können, welches Datenvolumen ihm jedenfalls zur Verfügung steht“. Zweitens ist die Klausel überraschend nach § 305c Abs. 1 BGB und damit schon nicht Vertragsbestandteil: Wer in Ziffer 14 unlimitiertes Volumen verspricht, darf die Zusage nicht im Folgeabschnitt unter der beschwichtigenden Überschrift „Exzessive Nutzung“ auf den Durchschnitt zusammenziehen. Drittens gefährdet sie die Erreichung des Vertragszwecks (§ 307 Abs. 2 Nr. 2 i.V.m. § 308 Nr. 4 BGB); der Senat verneint ausdrücklich, dass es sich um eine kontrollfreie Leistungsbeschreibung handelt — es ist eine Einschränkung der Hauptleistung. Für den Kündigungsvorbehalt kommt ein eigenständiger Mangel hinzu: Die Regelung weicht von wesentlichen Grundgedanken des § 314 BGB ab (§ 307 Abs. 2 Nr. 1 BGB), weil sie weder eine Interessenabwägung noch eine vorherige Abmahnung vorsieht und den wichtigen Grund allein aus dem Datenvolumen unwiderleglich vermutet — womit der Verwender vom Nachweis eines tatsächlichen Missbrauchs befreit wäre.

Praxisfolgen: Fair-Use-Vorbehalte bleiben zulässig — verboten ist die Unbestimmtheit. Wer drosseln will, muss eine feste, bei Vertragsschluss erkennbare Schwelle nennen, keinen dynamischen Vergleichswert aus dem eigenen Kundenbestand. Ein Kündigungsvorbehalt braucht die Systematik des § 314 BGB: Abmahnung, Einzelfallabwägung, Beweislast beim Kündigenden. Und die Platzierung zählt: Eine Einschränkung der Hauptleistung, die einen Abschnitt nach der Leistungszusage steht, ist überraschend. Für Datenschutz- und Compliance-Praktiker liegt die Übertragbarkeit im Muster — auch Einwilligungstexte und Verarbeitungsvorbehalte scheitern regelmäßig daran, dass der Betroffene im Entscheidungszeitpunkt nicht erkennen kann, worauf er sich einlässt; das Transparenzgebot des § 307 Abs. 1 Satz 2 BGB und das Bestimmtheitserfordernis nach Art. 4 Nr. 11 DSGVO laufen hier parallel. Die Signalwirkung reicht über 1&1 hinaus: Telekom, Vodafone und O2 arbeiten mit vergleichbaren Klauseln, und das OLG Bamberg hatte wenige Wochen zuvor der Telefónica eine ähnliche Kündigungsregelung untersagt.

5.1 AEPD: 10.000 Euro wegen Werbeanrufen — erstmals auf Grundlage einer Audio-Aufzeichnung

05.08.2026 · Moncloa: Multa AEPD por spam a Más Sol Energía

Behörde: Agencia Española de Protección de Datos (AEPD) · Adressat: Más Sol Energía (Vertrieb von Solaranlagen) · Höhe: 10.000 Euro

Verstoß / Rechtsgrundlage: Werbeanrufe ohne wirksame Einwilligung — Verarbeitung personenbezogener Daten zu Direktwerbezwecken ohne tragfähige Rechtsgrundlage.

Begründung: Bemerkenswert ist nicht die Höhe, sondern das Beweismittel: Es ist die erste Sanktion der spanischen Aufsicht, die sich auf eine Tonaufzeichnung des beanstandeten Anrufs stützt. Eine 46 Sekunden lange Aufnahme widerlegte die Einlassungen des Unternehmens. Die Behörde hatte betroffenen Personen bereits 2023 empfohlen, unerwünschte Werbeanrufe mitzuschneiden, um Beschwerden belegen zu können — dieser Fall ist die Bestätigung, dass die Empfehlung trägt.

Praxisfolgen: Für Unternehmen mit Telefonvertrieb verschiebt sich damit die Beweislage. Bisher stand bei Beschwerden regelmäßig Aussage gegen Aussage, was Verfahren häufig ins Leere laufen ließ. Wer Telefonwerbung betreibt, braucht deshalb eine lückenlose, pro Anruf zuordenbare Dokumentation der Einwilligung mit Zeitpunkt, Quelle und Wortlaut — und sollte Vertriebsdienstleister vertraglich darauf verpflichten. Für die deutsche Praxis gilt der Fall nicht unmittelbar, weil hier andere Maßstäbe für die Zulässigkeit heimlicher Aufnahmen gelten; der Trend zu belastbaren Beschwerdebelegen ist aber europäisch. Unabhängig davon bleibt die Beobachtung des Tages bestehen: Deutsche Aufsichtsbehörden sind zur Veröffentlichung von Bußgeldern nicht verpflichtet, weshalb die sichtbare Sanktionspraxis systematisch verzerrt ist und deutsche Fälle in Übersichten unterrepräsentiert bleiben.

6.1 Berliner Landesnetz: zwei Senatsverwaltungen seit fünf Tagen isoliert

21.08.2026 · heise: Berliner Verwaltungen weiter vom Netz getrennt · Tagesspiegel: Wohngeld an über 50.000 Haushalte in Gefahr · Behörden Spiegel

Zusammenfassung: Der IT-Angriff wurde am Freitag, dem 14. August, entdeckt; forensische Untersuchungen ergaben eine „Inkriminierung des Landesnetzes Berlin“. Am 17. August wurden die Senatsverwaltung für Stadtentwicklung, Bauen und Wohnen sowie die Senatsverwaltung für Mobilität, Verkehr, Umwelt und Klimaschutz vorsorglich vom Landesnetz getrennt und ein Krisenstab eingerichtet. Am 18. August untersagte die Stadtentwicklungsverwaltung ihren Beschäftigten die Arbeit von zu Hause; Internetverbindungen und externer E-Mail-Verkehr wurden vollständig gekappt. Am 21. August ist weiterhin offen, wann die Häuser wieder voll arbeitsfähig sind. Die Auszahlung des Wohngelds an über 50.000 berechtigte Haushalte ist gefährdet, ebenso die Leistung „Bildung und Teilhabe“. Landeskriminalamt, Staatsanwaltschaft Berlin und das BSI sind eingebunden; die Leitung des IKT-Notfallkrisenstabs liegt beim Landesbevollmächtigten für Informationssicherheit. Nach ersten Erkenntnissen sollen Daten abgeflossen sein, dabei aber öffentlich verfügbare Geoinformationsdaten. Eine Lösegeldforderung ist nicht bekannt.

Hintergrund & Einordnung: Das Berliner Landesnetz verbindet rund 600 behördliche und öffentliche Standorte und ist damit die zentrale digitale Infrastruktur der Hauptstadtverwaltung. Der Chief Digital Officer des Landes sprach von einem „sehr ernsten Angriff“, hier seien keine Amateure am Werk gewesen. Aufschlussreich ist ein Nebeneffekt, der die Kopplungsdichte solcher Netze illustriert: Die laufenden Sicherheitsanalysen beanspruchen so viel Kapazität, dass auch nicht unmittelbar betroffene digitale Angebote der Stadt langsam laufen oder zeitweise nicht erreichbar sind. Die Verantwortlichen betonen, dass die anstehenden Wahlen nicht gefährdet seien. Zu Umfang und Urheberschaft schweigt der Senat aus ermittlungstaktischen Gründen — nach Tagesspiegel-Informationen könnten weitere Häuser betroffen sein.

Praxisfolgen / Handlungsempfehlung: Der Fall ist eine Lehrstunde in Netzsegmentierung: Dass eine Kompromittierung die vorsorgliche Trennung ganzer Ressorts vom zentralen Netz erzwingt, spricht dafür, dass eine feinere Abschottung nicht verfügbar war. Für vergleichbare Organisationen heißt das: Prüfen Sie, ob Ihre Segmentierung eine Isolierung einzelner Bereiche erlaubt, ohne dass ganze Häuser offline gehen müssen, und ob Ihre Notfallkommunikation ohne das betroffene Netz funktioniert — in Berlin läuft die externe Kommunikation derzeit überwiegend telefonisch. Zweitens gehört die Kapazitätsfrage in den Notfallplan: Forensik im laufenden Betrieb kostet Bandbreite und Rechenleistung, was ohne Vorplanung unbeteiligte Dienste mit ausbremst. Drittens: Wo Sozialleistungsprozesse von einem einzigen Netz abhängen, braucht es einen dokumentierten Rückfallweg — die Zahlungsverpflichtung entfällt nicht, weil das Netz ausfällt.

6.2 VMware vCenter: 361 kompromittierte Systeme in 47 Ländern, Deutschland an der Spitze

20.08.2026 · BleepingComputer: vCenter RCE flaw exploited for reverse SSH access · The Hacker News: Persistent Remote Access · Infosecurity Magazine: Exploited Five Days After Disclosure

Zusammenfassung: Zur am 18. August in den KEV-Katalog aufgenommenen Path-Traversal-Lücke im Syslog-Server von VMware vCenter (CVE-2026-59310, CVSS 9,8) liegen nun Details zur laufenden Kampagne vor. Das deutsche Sicherheitsunternehmen QUIRSO stieß im Rahmen einer Incident Response auf die Aktivität eines fortgeschrittenen Angreifers: Nach der Ausnutzung wird per Cron-Job das quelloffene Werkzeug reverse_ssh eingerichtet, das einen von innen nach außen aufgebauten Steuerkanal hält und damit eingehende Netzwerkkontrollen umgeht. Bis zum 7. August identifizierte QUIRSO 361 betroffene IP-Adressen in 47 Ländern — angeführt von Deutschland, vor den USA, der Türkei, dem Iran und Frankreich. Die Ausnutzung begann am 3. August, fünf Tage nach der Offenlegung durch VMware (VMSA-2026-0006 vom 29. Juli, aktualisiert am 3. August), erreichte am 4. August mit 151 neuen Opfer-IPs ihren Höhepunkt und war bis zum 5. August zu rund 95 Prozent abgeschlossen. Shadowserver benachrichtigt die Betroffenen in einem Sonderbericht und weist ausdrücklich darauf hin, dass die Persistenz bei allen gemeldeten Opfern nachgewiesen wurde — sie sind als vollständig kompromittiert zu behandeln. Behoben ist die Lücke in vCenter 9.1.0.0300, 9.0.2.0100 sowie 8.0 U3k beziehungsweise U2f; ein Workaround existiert nicht.

Hintergrund & Einordnung: Der Zeitverlauf ist das eigentliche Signal: Die Kampagne startete fünf Tage nach der Herstellermeldung und war binnen 48 Stunden im Wesentlichen durch. Wer nicht innerhalb weniger Tage patchte, war bereits betroffen — Patch-Zyklen im Wochenrhythmus greifen bei dieser Klasse von Systemen nicht mehr. vCenter ist die Verwaltungsebene für Virtualisierungsumgebungen; wer sie kontrolliert, kontrolliert mittelbar alle darauf laufenden Systeme, einschließlich der Möglichkeit, Datenträger zu klonen oder Sicherungen zu manipulieren. Dieselben Updates schließen mit CVE-2026-59309 zusätzlich eine Authentifizierungsumgehung im VMware Directory Service. Kritisch anzumerken ist die Herstellerkommunikation: Broadcoms FAQ enthält weiterhin die frühere Aussage, es lägen keine Hinweise auf Ausnutzung vor — die Angaben des Herstellers hinken den Erkenntnissen der Incident-Response-Praxis hinterher. QUIRSO hält angreiferspezifische Indikatoren wegen laufender Strafverfolgungskoordination zurück.

Praxisfolgen / Handlungsempfehlung: Nachpatchen genügt hier nicht — ein bereits gesetztes Implantat überlebt das Update. Behandeln Sie jedes aus dem Internet erreichbare, nicht rechtzeitig gepatchte vCenter als vermutlich kompromittiert und suchen Sie aktiv: Cron-Jobs der Appliance auf unautorisierte Einträge prüfen, ausgehende Verbindungen zu unbekannten Zielen auswerten, Prozessausführungen und autorisierte SSH-Schlüssel kontrollieren. Beschränken Sie ausgehenden Verkehr der Verwaltungsebene grundsätzlich auf definierte Ziele — ein vCenter braucht keinen freien Internetzugang. Bei Kompromittierungsverdacht gehören Zugangsdaten und Zertifikate der Verwaltungsebene rotiert, bevor die Systeme wieder ins Regelnetz gehen. Warten Sie nicht auf eine Herstellerbestätigung.

6.3 41 gefälschte Download-Seiten mit manipulierten Klick-Zielen

20.08.2026 · heise: Gefälschte Seiten jubeln falsche Software unter

Zusammenfassung: Virenanalysten von Malwarebytes haben 41 gefälschte Webseiten dokumentiert, die als Download-Angebot für populäre Programme und Spiele auftreten. Genannt werden unter anderem Counter-Strike, Half-Life, Fallout, Roblox, PUBG, The Witcher und GTA 6 sowie auf der Anwendungsseite 7-Zip, Foxit PDF, Paint.NET, Total Commander, VLC und VMware. Die Besonderheit liegt in der Klickbehandlung: Im Quelltext steht das legitime Ziel, sodass der Browser beim Überfahren des Links etwa Steam anzeigt; ein JavaScript fängt den Klick jedoch ab und leitet über Partnerlinks auf eine fremde Installationssoftware um. Diese Anwendung ist für sich genommen keine Schadsoftware, wird aber über Provisionsmodelle verbreitet; 2020 hatte ein Update davon versehentlich Malware nachinstalliert. Malwarebytes hat eine Liste von Kompromittierungsindikatoren veröffentlicht.

Hintergrund & Einordnung: Die Masche unterläuft die verbreitetste Nutzerschulung überhaupt — „Fahren Sie mit der Maus über den Link und prüfen Sie das Ziel“. Genau diese Prüfung liefert hier ein falsch-positives Ergebnis, weil die Umleitung erst zur Klickzeit im Skript entsteht. Damit reiht sich der Fall in eine Entwicklung ein, bei der Angreifer nicht mehr Signale fälschen, sondern die Prüfmechanismen selbst adressieren. Wirtschaftlich ist die Kampagne kein Malware-, sondern ein Affiliate-Betrugsmodell — was sie für Betreiber attraktiv und für Strafverfolgung sperrig macht.

Praxisfolgen / Handlungsempfehlung: In der Anwenderkommunikation sollte der Rat „Link-Ziel prüfen“ um „Adresse selbst eintippen“ ergänzt werden — für Software-Bezug ist nur letzteres verlässlich. Technisch helfen zwei Maßnahmen: die Prüfung digitaler Signaturen heruntergeladener Dateien als verpflichtender Schritt und, im Unternehmensumfeld, die Beschränkung von Software-Installationen auf einen internen Verteilungsweg. Übernehmen Sie die veröffentlichten Indikatoren in Ihre Filterlisten. Ergänzend gilt der Klassiker: Werbeanzeigen in Suchergebnissen sind für Software-Downloads grundsätzlich nicht der richtige Weg.