1. Cookieloses Tracking über die Audio-Schnittstelle des Browsers

Seit Donnerstag, 20. August 2026 · zuletzt aktualisiert Dienstag, 25. August 2026 · Score 79

AliExpress erzeugt über die Web Audio API ein lautloses Signal und leitet aus dessen Verarbeitung einen Geräte-Fingerabdruck ab. Verantwortlich sind zwei obfuskierte Alibaba-Skripte aus dem Antifraud-Werkzeugkasten, die zusätzlich Canvas-, WebGL-, Hardware- und WebRTC-Merkmale sowie Maus- und Touch-Verhalten sammeln.

Letzte Entwicklung: Nach der Veröffentlichung am 23. August bestätigten mehrere Analysten den Befund. Brave blockiert die identifizierten Skripte, Firefox verfügt über Gegenmaßnahmen. Die strukturelle Frage bleibt offen: Audio-Kontexte benötigen keine Nutzerfreigabe und lösen keinen sichtbaren Hinweis aus.

2. Schwachstellenflut in der Spring-Familie

Seit Freitag, 21. August 2026 · zuletzt aktualisiert Montag, 24. August 2026 · Score 72

VMware Tanzu hat am 24. August Sicherheitsupdates für zahlreiche Spring-Produkte veröffentlicht; über das Framework und verwandte Projekte hinweg werden inzwischen 91 CVEs geführt.

Letzte Entwicklung: Kritisch eingestuft ist CVE-2026-59270 im eingebetteten UnboundID-LDAP-Server von Spring Security. Für Spring AI erschien bereits am 21. August Version 2.0.1 mit sieben behobenen CVEs, darunter eine Prompt-Injection-Schwäche im Tool-Calling. Aktive Ausnutzung ist nicht bekannt; die Patches betreffen laut Analysen mehr als 200.000 Softwarekomponenten.

3. Countdown zur CRA-Meldepflicht — das Meldewerkzeug fehlt noch

Seit Montag, 29. Juni 2026 · zuletzt aktualisiert Freitag, 14. August 2026 · Score 68

Ab dem 11. September müssen Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen binnen 24 Stunden melden. Die dafür vorgesehene Single Reporting Platform der ENISA war Ende Juni noch nicht in Betrieb.

Letzte Entwicklung: Am 14. August veröffentlichte die ENISA Hinweise zur Schnittstelle für bevollmächtigte Vertreter — mit zwei bis dahin unbekannten Beschränkungen: Nicht verifizierte Konten dürfen nur zehn Meldungen einreichen, und Entwürfe sind zwischen Vertretern nicht einsehbar. Öffentliche URL und die Liste der koordinierenden CSIRTs stehen weiterhin aus.

1.1 AliExpress identifiziert Geräte über unhörbare Audiosignale

24.08.2026 · heise: AliExpress trackt Nutzer via unhörbarem Audio-Fingerprinting · gHacks: silent browser audio to fingerprint devices

Zusammenfassung: AliExpress nutzt die Web Audio API zur Geräteidentifikation. Aufgedeckt wurde das am 20. August durch einen Nebeneffekt: Die Multipoint-Bluetooth-Kopfhörer eines Entwicklers wechselten nicht mehr zwischen Rechner und Telefon, solange ein AliExpress-Tab geöffnet war; Stummschalten von Tab, Browser oder Betriebssystem half nicht, erst das Schließen der Seite. Ursache sind zwei obfuskierte Alibaba-Skripte, collina.js (Version 1.140.0) und fireyejs.js (Version 1.231.67), gehostet unter assets.aliexpress-media.com/g/AWSC/. Beide bauen denselben Web-Audio-Graphen auf: Ein Oszillator erzeugt eine bekannte Wellenform, ein Analyse-Knoten misst deren Frequenzeigenschaften, und ein auf null gesetzter Verstärkungsregler verhindert, dass etwas hörbar wird. Weil Prozessor, Treiber, Betriebssystem und Soundhardware dasselbe Signal jeweils minimal anders verarbeiten, entsteht ein Merkmal, das Wiedererkennung ohne Cookies ermöglicht. Dieselben Skripte sammeln außerdem Canvas-, WebGL-, Hardware- und WebRTC-Daten sowie Maus- und Touch-Verhalten und senden alles gebündelt an Alibabas Server. Brave blockiert die identifizierten Skripte; Firefox bietet Schutz über privacy.fingerprintingProtection; ein Inhaltsblocker stellt zugleich das normale Bluetooth-Verhalten wieder her.

Hintergrund & Einordnung: Alibaba ordnet die Skripte der Betrugsprävention zu, und das dürfte teilweise zutreffen — Geräteerkennung ist ein legitimes Mittel gegen Kontoübernahmen und Bot-Bestellungen. Das eigentliche Problem liegt eine Ebene tiefer: Audio-Kontexte im Browser benötigen keine Nutzerfreigabe und lösen keinen sichtbaren Hinweis aus. Kamera und Mikrofon fragen, Standort fragt, Benachrichtigungen fragen — die Audio-Ausgabe fragt nicht. Damit existiert ein Erhebungskanal, den weder das Berechtigungsmodell des Webs noch die üblichen Consent-Banner abbilden. Hinzu kommt die Persistenz: Ein Cookie lässt sich löschen, eine Werbe-ID zurücksetzen; die Kombination aus Hardware-, Treiber- und Systemeigenheiten bleibt. Genau das macht Fingerprinting datenschutzrechtlich heikler als klassisches Tracking — es unterläuft die Betroffenenrechte, weil es kein Objekt gibt, das man entfernen könnte.

Praxisfolgen / Handlungsempfehlung: Datenschutzrechtlich ist Fingerprinting das Auslesen von Informationen aus der Endeinrichtung und damit nach § 25 TDDDG einwilligungsbedürftig — unabhängig davon, ob die Daten für Betrugsprävention oder Werbung genutzt werden; die Ausnahme für unbedingt erforderliche Vorgänge greift nur, soweit der Dienst ohne die Erhebung tatsächlich nicht funktioniert. Wer Antifraud-Bibliotheken Dritter einbindet — und das tun sehr viele Shops —, sollte dokumentieren, welche Gerätemerkmale diese erheben, das in der Datenschutzerklärung abbilden und die Einwilligung entsprechend einholen. Für die eigene Absicherung: Prüfen Sie die auf Ihren Seiten eingebundenen Skripte auf Web-Audio-, Canvas- und WebGL-Zugriffe; das lässt sich in den Entwicklerwerkzeugen des Browsers nachvollziehen. Anwenderseitig sind die genannten Browser-Einstellungen der einfachste Hebel, im Unternehmensumfeld eine zentral verteilte Blockliste.

1.2 CyberGovSecure: Bundeskabinett beschließt Sicherheitsprogramm für die Bundesverwaltung

Kabinettsbeschluss 22.07.2026, Einordnung 25.08.2026 · Dr. Datenschutz: CyberGovSecure

Zusammenfassung: Mit dem am 22. Juli 2026 vom Bundeskabinett beschlossenen ressortübergreifenden Programm CyberGovSecure will die Bundesregierung Cybersicherheit und Resilienz der Bundesverwaltung erhöhen und das Sicherheitsniveau zwischen den Behörden vereinheitlichen. Das Programm umfasst neun Handlungsfelder: sichere Systemkonfiguration und Härtung, Asset-Management, Schwachstellenmanagement, Protokollierung und Angriffserkennung, Netzwerksicherheit, Informationssicherheitsmaßnahmen, eine resiliente zentrale Dienstearchitektur, Daten- und Zugriffsschutz sowie modernes Mobile Device Management. Für 2026 hat das BSI vier Schwerpunkte priorisiert: belastbare Backup-Strategien mit regelmäßigen Tests, standardisierte Systemhärtung nach BSI-Vorgaben, kontinuierliche Identifikation und Behebung von Schwachstellen sowie verbesserte Protokollierung und Anomalieerkennung. Die Steuerung liegt bei einem Gremium unter Vorsitz des BMDS; der CISO des Bundes koordiniert die Umsetzung im Einvernehmen mit den Ressorts und mit Unterstützung des BSI.

Hintergrund & Einordnung: Der Beschluss stammt aus dem Juli, gewinnt aber durch die Ereignisse der vergangenen zwei Wochen an Gewicht. In Berlin waren zwei Senatsverwaltungen zehn Tage lang aus dem Landesnetz getrennt, und der zuständige Staatssekretär räumte öffentlich „strukturelle Defizite in der IT“ ein. Das ist Landes-, nicht Bundesebene — aber die Diagnose ist dieselbe, und die vier priorisierten Maßnahmen lesen sich wie eine Antwort auf genau diesen Vorfall: Backups, Härtung, Schwachstellenmanagement, Angriffserkennung. Bemerkenswert ist, was das über den Ausgangszustand aussagt: Dass ein Kabinettsbeschluss nötig ist, um regelmäßig getestete Backups und standardisierte Härtung als Schwerpunkt zu setzen, beschreibt den Reifegrad ehrlicher als jede Fortschrittsmeldung. Für die Bewertung fehlt bislang das Entscheidende — Zeitpläne, Mittel und Erfolgskriterien sind öffentlich nicht hinterlegt.

Praxisfolgen / Handlungsempfehlung: Für private Unternehmen ist das Programm nicht bindend, taugt aber als Priorisierungsraster. Die vier Schwerpunkte sind genau die Maßnahmen mit dem besten Verhältnis von Aufwand zu Wirkung, und sie decken sich mit den Anforderungen, die über NIS-2 auf viele Unternehmen zukommen: Angriffsflächenreduktion, Resilienz und Sichtbarkeit. Wer eine Standortbestimmung braucht, kann die neun Handlungsfelder als Checkliste verwenden und für jedes Feld drei Fragen beantworten — gibt es eine verbindliche Vorgabe, wird ihre Einhaltung gemessen, und wer merkt es, wenn sie verletzt wird. Besonders lohnend ist der Punkt Backup: Eine Sicherung, deren Wiederherstellung nie getestet wurde, ist im Ernstfall eine Annahme, keine Maßnahme.

2.1 CRA-Meldepflichten ab dem 11. September — die ENISA-Plattform ist weiterhin nicht erreichbar

14.08.2026 · cyberresilienceact.eu: ENISA SRP AR Interface Functions · Single Reporting Platform is still not live · ENISA: Single Reporting Platform

Zusammenfassung: Ab dem 11. September 2026 greifen die Meldepflichten nach Artikel 14 des Cyber Resilience Act. Hersteller von Produkten mit digitalen Elementen müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle in einer dreistufigen Kaskade melden: Frühwarnung binnen 24 Stunden nach Kenntniserlangung, technische Meldung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen bei Schwachstellen beziehungsweise binnen eines Monats bei Vorfällen. Die Pflicht gilt für alle Produkte, die auf dem Unionsmarkt bereitgestellt wurden — auch für Bestandsprodukte. Gemeldet wird einmalig über die Single Reporting Platform an das CSIRT des Mitgliedstaats der Hauptniederlassung; die Meldung wird gleichzeitig der ENISA zur Verfügung gestellt. Die Plattform war Ende Juni noch nicht in Betrieb. Am 14. August veröffentlichte die ENISA Hinweise zur Schnittstelle für bevollmächtigte Vertreter und nannte dabei zwei bis dahin unbekannte Beschränkungen: Ein nicht verifiziertes Konto kann nur bis zu zehn Meldungen einreichen, und Entwürfe sind für andere Vertreter nicht einsehbar — der Vertretungsfall muss also außerhalb der Plattform dokumentiert werden. Öffentliche URL und die Liste der koordinierenden CSIRTs standen zum Redaktionsschluss weiterhin aus.

Hintergrund & Einordnung: Die Lücke zwischen Pflicht und Werkzeug ist das zentrale Planungsproblem. Anders als bei der DSGVO, wo die Meldung formfrei an eine bekannte Behörde geht, sieht der CRA einen einzigen elektronischen Zugangspunkt vor — steht der nicht bereit, fehlt der Meldeweg. Die beiden neuen Beschränkungen wirken technisch klein, haben aber operative Folgen: Das Zehn-Meldungen-Limit für nicht verifizierte Konten trifft genau die Unternehmen, die sich erst im Ernstfall registrieren, und die fehlende Sichtbarkeit von Entwürfen bricht das übliche Vier-Augen-Prinzip bei Vorfallmeldungen. Nicht zu unterschätzen ist außerdem der Begriffsumfang: „Produkte mit digitalen Elementen“ reicht weit über klassische Software hinaus und erfasst vernetzte Geräte ebenso wie eingebettete Komponenten. Wer bisher davon ausging, nicht betroffen zu sein, sollte das anhand des Produktportfolios prüfen und nicht anhand der Selbstwahrnehmung.

Praxisfolgen / Handlungsempfehlung: Vier Schritte lassen sich ohne die Plattform erledigen. Erstens: EU-Login-Konten für die vorgesehenen Personen anlegen und verifizieren lassen — das ist die Voraussetzung, um nicht in das Zehn-Meldungen-Limit zu laufen. Zweitens: Das zuständige CSIRT anhand der EU-Hauptniederlassung bestimmen, bei Herstellern aus Drittstaaten anhand des Bevollmächtigten. Drittens: Den Text der 24-Stunden-Frühwarnung als Vorlage außerhalb der Plattform vorformulieren, damit im Ernstfall nur noch Fakten eingesetzt werden müssen. Viertens: Ein überwachtes Postfach für Rückmeldungen einrichten. Ergänzend gehört ein interner Triage-Prozess aufgebaut, der aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle als solche erkennt — die Abgrenzung entscheidet darüber, ob die Uhr überhaupt läuft. Und ohne belastbare Stückliste der eigenen Softwarekomponenten lässt sich eine Meldung nicht begründen; SBOMs sind damit faktisch Pflichtbestandteil des Schwachstellenmanagements geworden.

3.1 Oracle-Proxy-Plug-in: CVSS-10-Lücke wird ausgenutzt

24.08.2026 · CISA: Adds One Known Exploited Vulnerability to Catalog · The Hacker News: Actively Exploited Oracle WebLogic Flaw

Zusammenfassung: Die CISA hat am 24. August CVE-2026-21962 in den Katalog bekannter ausgenutzter Schwachstellen aufgenommen. Es handelt sich um eine unzureichende Zugriffskontrolle (CWE-284) im Oracle HTTP Server und im Oracle WebLogic Server Proxy Plug-in, beides Komponenten der Oracle Fusion Middleware. Nicht authentifizierte Angreifer können über HTTP-Anfragen aus dem Netz die vorgesehenen Zugriffsbeschränkungen umgehen. Der CVSS-Basiswert beträgt 10,0 bei einem Vektor mit geändertem Wirkungsbereich — ein Angriff auf die Proxy-Komponente kann deren Sicherheitskontext verlassen und andere Produkte oder das darunterliegende Betriebssystem erreichen. Laut CISA ermöglicht die Lücke unbefugtes Erstellen, Löschen und Verändern kritischer Daten sowie unbefugten Zugriff darauf. Betroffen sind Oracle HTTP Server und WebLogic Server Proxy Plug-in (Apache) in den Versionen 12.2.1.4.0, 14.1.1.0.0 und 14.1.2.0.0 sowie das Proxy Plug-in für Microsoft IIS ausschließlich in Version 12.2.1.4.0. Oracle hatte die Schwachstelle im Critical Patch Update vom Januar 2026 offengelegt.

Hintergrund & Einordnung: Der Angriffspunkt ist nicht die Anwendung, sondern die Weiterleitungsschicht davor — jenes Plug-in auf Oracle HTTP Server, Apache oder Microsoft IIS, das HTTP-Verkehr in WebLogic-Cluster reicht. Solche Komponenten stehen typischerweise in der DMZ und sind damit unmittelbar exponiert; die Lücke gehört deshalb in die Kategorie Netzrand, nicht in die Kategorie Middleware-Wartung. Wichtig für die Bestandsaufnahme ist eine Abgrenzung, die in vielen Meldungen untergeht: Betroffen sind die Proxy-Plug-ins, nicht jede WebLogic-Installation. Dass der Produktname im CVE auftaucht, macht einen Anwendungsserver noch nicht verwundbar. Bemerkenswert ist der zeitliche Abstand: Der Patch liegt seit Januar vor, die Ausnutzung ist erst jetzt bestätigt — sieben Monate, in denen die Korrektur verfügbar war und offenkundig vielerorts nicht eingespielt wurde.

Praxisfolgen / Handlungsempfehlung: Prüfen Sie, ob eine der genannten Proxy-Komponenten im Einsatz ist, und spielen Sie das Critical Patch Update vom Januar 2026 ein, falls das noch aussteht. Sichern Sie vorher die HTTP- und Anwendungsprotokolle des relevanten Zeitraums, bevor sie durch die Rotation überschrieben werden — bei einer bereits ausgenutzten Lücke ist die rückwirkende Prüfung ebenso wichtig wie der Patch. Suchen Sie in den Protokollen nach Zugriffen auf Pfade, die hinter der Zugriffskontrolle liegen sollten, und nach Anfragen ohne vorausgehende Authentifizierungsereignisse. Da der Wirkungsbereich geändert ist, sollte die Prüfung nicht bei der Proxy-Komponente enden, sondern die dahinterliegenden Systeme einschließen.

3.2 Spring-Familie: 91 CVEs, kritische Lücke in Spring Security

24.08.2026 · heise: Zahlreiche Sicherheitslücken bedrohen VMware-Tanzu-Spring-Software · SecurityWeek: 91 Vulnerabilities Patched in Spring

Zusammenfassung: VMware Tanzu hat am 24. August Sicherheitsupdates für zahlreiche Produkte der Spring-Familie veröffentlicht; über das Framework und verwandte Projekte hinweg werden inzwischen 91 CVEs geführt. Als kritisch eingestuft ist allein CVE-2026-59270: Sie betrifft den eingebetteten UnboundID-LDAP-Server von Spring Security und erlaubt Angreifern, sich zu authentifizieren und Einträge im In-Memory-Verzeichnis zu verändern. Hoch eingestuft sind unter anderem CVE-2026-47851 in Spring AI, bei der die Verarbeitung eines präparierten PDF-Dokuments den Zugriff auf nicht vorgesehene Speicherbereiche und damit Abstürze oder Codeausführung ermöglicht, CVE-2026-47841, ein WebAuthn-Fehler in Spring Security, sowie CVE-2026-59288 in Spring GraphQL, über die sich mit einer manipulierten URL abgeschottete Daten erreichen lassen. Bereits am 21. August war Spring AI 2.0.1 mit sieben behobenen CVEs erschienen. Hinweise auf aktive Ausnutzung liegen nach Herstellerangaben nicht vor; ungepatchte Systeme bleiben gefährdet. Analysen zufolge betreffen die Korrekturen mehr als 200.000 Softwarekomponenten.

Hintergrund & Einordnung: Aufschlussreich ist ein Eintrag in der Liste: CVE-2026-59318 (CVSS 6,5) betrifft die Werkzeugaufruf-Funktion von Spring AI. Die pro Anfrage freigegebene Werkzeugliste wird dem Modell zwar als Grenze angekündigt, aber nicht vollständig durchgesetzt — unter bestimmten Bedingungen kann eine Prompt Injection Spring AI dazu bringen, ein Werkzeug aufzurufen, das für die aktuelle Anfrage gar nicht freigegeben war. Das ist die strukturelle Schwäche von Werkzeugaufrufen in KI-Anwendungen auf den Punkt gebracht: Eine Grenze, die man dem Modell mitteilt, ist keine Grenze; durchgesetzt werden muss sie serverseitig. Zum Umfang: Broadcom meldete zwischen März und April einen Anstieg der monatlichen Spring-Security-Advisories um über 1.700 Prozent. Das spricht weniger für einen plötzlichen Qualitätsverfall als dafür, dass automatisierte, KI-gestützte Analyse inzwischen Fehler in Größenordnungen findet, die klassische Prozesse nicht erzeugt hätten — mit der Folge, dass Konsumenten von Bibliotheken eine Patch-Frequenz bewältigen müssen, auf die ihre Prozesse nicht ausgelegt sind.

Praxisfolgen / Handlungsempfehlung: Beginnen Sie mit der Bestandsaufnahme, nicht mit dem Patchen: Ohne belastbare Stückliste bleiben transitive Abhängigkeiten unsichtbar, und genau dort steckt Spring meist. Priorisieren Sie internetseitige Dienste, GraphQL-Deployments und Anwendungen, die KI-Werkzeuge exponieren. Für Spring AI gilt die Aktualisierung auf 2.0.1 als Mindestmaß; ergänzend sollten Sie in der eigenen Architektur nachvollziehen, ob die Werkzeugfreigabe je Anfrage tatsächlich serverseitig erzwungen wird — verlassen Sie sich nicht darauf, dass das Framework das für Sie erledigt. Und behandeln Sie die PDF-Verarbeitung in Spring AI als Angriffsfläche: Wo Nutzer Dokumente hochladen können, gehört die Verarbeitung isoliert.

4.1 BVwG Österreich: Art. 15 DSGVO gibt kein Recht auf das Dokument, wenn Rechte Dritter überwiegen

Bundesverwaltungsgericht Österreich · 30.07.2026 · W298 2328672-1/9E · CSA-Aufbereitung ur-644 · RIS Judikatur BVwG

Sachverhalt: Eine Betroffene richtete an eine Verantwortliche — nach der Sachverhaltsschilderung im Umfeld der Filmakademie Wien — ein datenschutzrechtliches Auskunftsbegehren und wollte im Kern wissen, was in einem bestimmten Aktenvermerk über sie steht. Sie brauche den genauen Inhalt, um gegen sie gerichtete Maßnahmen nachvollziehen zu können, und gehe davon aus, dass der Vermerk weitergeleitet worden sei. Die Verantwortliche erteilte Auskunft über Speicherdauer, Empfänger, Datenkategorien, Betroffenenrechte, Verantwortliche und Rechtsgrundlage der Verarbeitung, gab den Inhalt des Vermerks jedoch nicht heraus. Die Datenschutzbehörde wies die Beschwerde am 27. Oktober 2025 ab.

Entscheidung: Das Bundesverwaltungsgericht wies die Beschwerde am 30. Juli 2026 als unbegründet ab. Die Revision ist nach Art. 133 Abs. 4 B-VG nicht zulässig. Eine mündliche Verhandlung unterblieb trotz Antrags, weil ausschließlich eine Rechtsfrage zu klären war (§ 24 Abs. 4 VwGVG).

Begründungs-Kernpunkte: Der Senat referiert zunächst die Linie des EuGH aus C-487/21: Das Recht auf Kopie ist aus Art. 15 DSGVO ableitbar und weit auszulegen, bezieht sich aber nicht auf das Dokument als solches, sondern auf die darin enthaltenen personenbezogenen Daten; der Anspruch auf eine originalgetreue Reproduktion besteht nur, soweit die Kopie unerlässlich ist, um der betroffenen Person die wirksame Ausübung ihrer Rechte zu ermöglichen. Bei Kollision mit Rechten Dritter ist eine Interessenabwägung durchzuführen (EuGH C-154/21). Ausdrücklich zugunsten der Betroffenen stellt der Senat fest, dass das Auskunftsrecht „unter keinen Voraussetzungen“ steht: Es muss nicht mit einem Rechtsschutzinteresse begründet werden, und ein Antrag darf nicht allein deshalb abgelehnt werden, weil primär Beweismittelbeschaffung beabsichtigt ist — unter Berufung auf EuGH C-307/22 und mehrere österreichische Oberlandesgerichte. Die Abweisung stützt sich stattdessen auf zwei Erwägungen. Erstens hat die Verantwortliche die Auskunft nicht verweigert, sondern nur so weit beschränkt, dass nicht erkennbar wird, wer den Vermerk verfasst hat und wer daran beteiligt war; damit sei die datenschutzrechtliche Kontrolle durch Behörde und Gericht ermöglicht worden. Zweitens blieb die Annahme, der Vermerk sei an Dritte weitergegeben worden, unbegründet — gerade dazu war beauskunftet worden, dass er internen Zwecken dient. Prozessual verknüpft der Senat das mit der Rechtsprechung des VwGH zum eingeschränkten Parteiengehör: Einzelne Aktenbestandteile dürfen zum Schutz der Grundrechte Dritter von der Akteneinsicht ausgenommen werden, solange Behörde und Gericht vollumfänglich darüber verfügen. Liegen diese strengen Voraussetzungen vor, sei „eine diesem Zweck zuwiderlaufende Auskunft ebenso nicht zu erteilen“.

Praxisfolgen: Für Verantwortliche ergibt sich ein dreistufiges Vorgehen bei Auskunftsersuchen, die auf ein bestimmtes Dokument zielen. Erstens die Pflichtangaben nach Art. 15 Abs. 1 vollständig erteilen — Zwecke, Kategorien, Empfänger, Speicherdauer, Herkunft, Rechte; daran scheitern die meisten Verfahren, nicht an der Dokumentenfrage. Zweitens prüfen, ob die Daten aus dem Dokument nötig sind, damit die betroffene Person ihre Rechte wirksam ausüben kann, und ob eine geschwärzte Fassung dafür ausreicht. Der Senat löst den Fall bewusst nicht über Schwärzung, weil hier schon die Schilderung des Inhalts Rückschlüsse auf die Beteiligten erlaubt hätte — wo Schwärzen genügt, ist zu schwärzen. Drittens die Abwägung dokumentieren und der betroffenen Person mitteilen, warum beschränkt wurde; die pauschale Verweigerung ohne Begründung, die hier ursprünglich gerügt wurde, ist der praktisch häufigste Fehler. Für die deutsche Praxis bindet die Entscheidung nicht, ihre Argumentation stützt sich aber fast vollständig auf EuGH-Rechtsprechung. Wer mit internen Vermerken, Compliance-Berichten oder Gesprächsnotizen konfrontiert ist, findet hier eine belastbare Argumentationshilfe — und die Warnung, dass sie nur trägt, wenn die übrigen Auskunftspflichten sauber erfüllt sind.

5.1 Warum die Sanktionspraxis wochenlang unsichtbar bleibt

Stand 25.08.2026 · Hintergrundquelle (undatierte Einordnung, nicht tagesaktuell): Dr. Datenschutz: Die verborgenen deutschen Bußgelder

Behörde: deutsche und europäische Aufsichtsbehörden · Adressat: — · Höhe: —

Verstoß / Rechtsgrundlage: Keine neue veröffentlichte Einzelentscheidung im Berichtszeitraum.

Begründung: Für die Sichtbarkeit der Aufsichtspraxis sind drei Faktoren maßgeblich. Erstens veröffentlichen die deutschen Aufsichtsbehörden Bußgelder nicht routinemäßig — eine Pflicht dazu besteht nicht, und in der Praxis erscheinen nur besonders hohe Beträge in Pressemitteilungen oder erst mit einem Jahr Verzögerung im Tätigkeitsbericht. Zweitens veröffentlichen mehrere europäische Aufsichten ihre Bescheide gebündelt und mit erheblichem zeitlichem Abstand zur Entscheidung; die italienische Aufsicht etwa stellt Provvedimenti häufig erst Wochen nach ihrem Erlass ein. Drittens fällt die Sommerperiode in eine Phase, in der weder die Datenschutzkonferenz noch der Europäische Datenschutzausschuss tagen — die nächste Zwischenkonferenz der DSK ist für den 23. September angesetzt, die 112. Konferenz für den 24. bis 26. November.

Praxisfolgen: Wer die eigene Risikoeinschätzung an veröffentlichten Bußgeldern ausrichtet, arbeitet mit einem verzerrten Bild — und zwar systematisch zugunsten der Annahme, es passiere wenig. Für die interne Argumentation ist das ein bekanntes Problem: Ein Vorstand, der nach deutschen Präzedenzfällen fragt, bekommt eine kurze Liste, weil die lange Liste nicht veröffentlicht wird. Belastbarer sind zwei andere Signale. Erstens die Prüfschwerpunkte, die Aufsichtsbehörden aktiv ankündigen — dort ist ablesbar, worauf in den nächsten Monaten geschaut wird. Zweitens die europäische Gesamtentwicklung, die zuletzt eine deutliche Verschiebung weg von den traditionellen Schwerpunktländern gezeigt hat. Praktisch heißt das: Die Frage „wurde das schon einmal geahndet?“ ist der falsche Maßstab; die Frage „würde unsere Verarbeitung einer Prüfung standhalten?“ ist der richtige. Die nächste Monatsübersicht für August ist Anfang September zu erwarten.

6.1 Gesellschaft für Informatik legt Whitepaper zur Reform des Computerstrafrechts vor

25.08.2026 · heise: Informatiker fordern Rechtsschutz für Sicherheitsforscher

Zusammenfassung: Die Gesellschaft für Informatik hat gemeinsam mit Partnern aus Wirtschaft, Cybersicherheitsforschung und digitalpolitischen Organisationen ein Whitepaper zur Reform des Computerstrafrechts vorgelegt und appelliert an die Bundesregierung, das Versprechen aus dem Koalitionsvertrag einzulösen. Kern der Kritik sind die 2007 eingeführten §§ 202a bis 202c StGB, die zwischen schädigender Absicht und legitimer Sicherheitsarbeit nicht unterscheiden. Besonders problematisch sei § 202c StGB, der die Bereitstellung und Nutzung von Werkzeugen unter Strafe stellt, die für eine fundierte Sicherheitsanalyse erforderlich sind. Das Whitepaper fordert, eine spezifische Schädigungsabsicht als Tatbestandsmerkmal aufzunehmen, Forschende zu schützen, die eine Schwachstelle ordnungsgemäß an den Hersteller melden, sowie flankierend Urheberrecht, Geschäftsgeheimnisschutz und Datenschutzrecht anzupassen und standardisierte Meldeprozesse nach dem Modell der Coordinated Vulnerability Disclosure zu etablieren. Die GI betont, dass ein ganzheitlicher Ansatz nötig sei statt punktueller Korrekturen, und verweist auf funktionierende Regelungen in Polen und Belgien.

Hintergrund & Einordnung: Die Debatte ist alt, der Anlass neu. Neu ist erstens, dass ein Referentenentwurf vorliegt, den die GI zwar als Schritt in die richtige Richtung bewertet, dessen Konstruktion sie aber für praxisuntauglich hält: Er verlangt von Forschenden den Nachweis, dass ihr Handeln der Verbesserung der Cybersicherheit dient, ohne zu klären, wie dieser Nachweis zu führen wäre — und er lässt § 202c unangetastet, also genau die Norm, die das Werkzeug kriminalisiert, bevor überhaupt jemand etwas untersucht hat. Neu ist zweitens der Maßstab, an dem sich die Rechtslage messen lassen muss: Wenn KI-gestützte Werkzeuge Schwachstellen in einer Geschwindigkeit finden, die klassische Prozesse nicht mehr einholen, wird die Frage, wer legal suchen darf, zur Verteidigungsfrage. Der praktische Befund ist unverändert eindeutig: Das Amtsgericht Jülich verurteilte einen IT-Fachmann zu 3.000 Euro Strafe, nachdem er 2021 eine Sicherheitslücke bei einem Online-Dienstleister aufgedeckt, das Unternehmen informiert und den Vorfall öffentlich gemacht hatte. Solange dieses Signal steht, ist die rationale Entscheidung für einen Finder, zu schweigen — oder den Fund anderweitig zu verwerten.

Praxisfolgen / Handlungsempfehlung: Unternehmen können die Rechtslage nicht ändern, aber ihre Wirkung abfedern. Richten Sie einen definierten Meldekanal ein und machen Sie ihn auffindbar: eine security.txt im Standardpfad und ein überwachtes Postfach kosten fast nichts — das BSI hatte zuletzt beklagt, dass nur 1,8 Prozent der geprüften Seiten überhaupt eine hinterlegen. Formulieren Sie zweitens eine schriftliche Zusage, gutgläubige Meldungen nicht zur Anzeige zu bringen, solange definierte Regeln eingehalten werden; das ist der Kern jeder brauchbaren Disclosure-Richtlinie und nimmt dem Finder das Risiko, das ihn sonst zum Schweigen bringt. Definieren Sie drittens intern, wer eine eingehende Meldung binnen 24 Stunden bewertet — ein unbeantworteter Hinweis ist der häufigste Grund dafür, dass eine Lücke am Ende öffentlich wird. Für Sicherheitsforschende bleibt der Rat unbequem: Ohne ausdrückliche schriftliche Erlaubnis des Betreibers bleibt jede Prüfung fremder Systeme in Deutschland rechtlich riskant, unabhängig von der Motivation.