Autor: Marcel Peter

  • Wie erkennt man einen versteckten Microsoft/Azure/.NET-Stack?
    Symbolbild, KI-generiert

    Wie erkennt man einen versteckten Microsoft/Azure/.NET-Stack?

    Ein Cookie mit dem Namen .AspNetCore.Cookies beendet die Diskussion, bevor sie angefangen hat. Wer dieses Cookie im Entwicklertools-Fenster einer Website sieht, weiß mit Sicherheit: Hier läuft ASP.NET Core. Keine Vermutung, kein Bauchgefühl, sondern ein Beweis, der sich in Sekunden prüfen lässt, ohne einen einzigen Scan zu starten. Die meisten Fragen zum eingesetzten Tech-Stack sind allerdings nicht so eindeutig zu beantworten, und genau darum geht es hier: um die vielen kleinen Spuren, die ein Microsoft-Stack im Alltag hinterlässt, und um die Frage, wie belastbar jede einzelne davon eigentlich ist.

    Warum das überhaupt jemanden interessiert

    Für IT-Verantwortliche ist die Antwort naheliegend: Was von außen über die eigene Infrastruktur erkennbar ist, sollten sie kennen, bevor es jemand anderes für sie herausfindet. Wer weiß, dass sein Server-Header offenherzig Kestrel verrät, kann eine bewusste Entscheidung treffen, ob das so bleiben soll. Für Auditoren und technisch Interessierte ist die Fragestellung aus einem anderen Grund relevant: Stack-Erkennung ist die Grundlage jeder seriösen technischen Bestandsaufnahme, und die Qualität dieser Erkennung hängt komplett davon ab, wie gut man zwischen sicherem Beweis und bloßer Vermutung unterscheidet.

    Klartext für Geschäftsführer: Ihre Website verrät im Hintergrund technische Details, die für Sie unsichtbar sind, aber für jeden, der sie ansieht, öffentlich einsehbar. Das ist erst einmal kein Sicherheitsproblem, viele dieser Signale lassen sich mit vertretbarem Aufwand reduzieren, ohne dass ein Techniker die Seite umbauen muss. Ein Signal aus diesem Artikel ist allerdings kein bloßes Detail, sondern ein handfestes Risiko: eine öffentlich sichtbare Fehlerseite mit Stacktrace, dazu gleich mehr.

    Die direkten Spuren: Header, Cookies, Pfade

    Ein Response-Header ist der ehrlichste Ort, um nach einem Microsoft-Stack zu suchen, weil der Server hier oft ungefragt Auskunft gibt. Server: Kestrel oder Microsoft-IIS/10.0 steht in vielen Fällen einfach so im Klartext in der Antwort, X-Powered-By: ASP.NET ebenso. Etwas versteckter, aber genauso aussagekräftig sind X-AspNet-Version und X-AspNetMvc-Version, die konkrete Framework-Versionen preisgeben, sowie x-ms-request-id und x-azure-ref, zwei Header, die praktisch nur bei Azure-gehosteten Diensten auftauchen. Der Header Request-Context: appId=cid-v1:xxxxxxxx gehört zu Application Insights, Microsofts Telemetrie-Dienst, und verrät damit gleich zwei Dinge auf einmal: den Stack und das Monitoring-Setup dahinter.

    Cookies sind die zweite große Kategorie direkter Spuren, und sie sind oft noch eindeutiger als Header, weil sie an sehr spezifische Frameworks gebunden sind. .AspNetCore.Cookies, .AspNetCore.Antiforgery oder .AspNetCore.Session bedeuten ASP.NET Core, Punkt. ARRAffinity und die zugehörige ARRAffinitySameSite-Variante gehören zum Load Balancing von Azure App Service. ai_user und ai_session stammen vom Browser-SDK von Application Insights. Und ein Cookie namens idsrv deutet auf Duende IdentityServer oder dessen Vorgänger hin, den De-facto-Standard für Identity- und Auth-Server im .NET-Ökosystem.

    Bei den Pfaden und Assets wird es noch konkreter, weil hier ganze Frameworks ihre Fingerabdrücke im Verzeichnisbaum hinterlassen. /_framework/blazor.web.js gehört zu Blazor, Microsofts Web-UI-Framework, /_framework/dotnet.js speziell zur WebAssembly-Variante davon, und /_blazor markiert einen Blazor-Server-Endpunkt mit einer dauerhaften SignalR-Verbindung zum Server. Endet ein Pfad auf /negotiate, handelt es sich fast immer um SignalR, Microsofts Echtzeit-Kommunikationsbibliothek. Und wo /swagger oder /openapi.json erreichbar sind, liegt darunter fast immer eine ASP.NET-Core-Web-API, die ihre eigene Dokumentation öffentlich mitliefert.

    Eine vierte, oft übersehene Signalquelle ist das Telemetrie-JavaScript selbst. Skripte mit Namen wie ai.2.min.js oder Referenzen auf applicationinsights im Quellcode, Requests an dc.services.visualstudio.com oder an *.in.applicationinsights.azure.com, der traceparent-Header nach dem W3C-Trace-Context-Standard, und ein globales window.appInsights-Objekt im Browser-Kontext: All das läuft unter der Haube, sobald eine Seite Application Insights zum Monitoring einsetzt, und ist mit den Bordmitteln jedes Browsers sichtbar.

    Indirekte Spuren: DNS und Zertifikat

    Wo direkte Spuren fehlen, hilft ein Blick auf die Infrastruktur dahinter. Ein CNAME-Eintrag, der auf eine Subdomain unter azurewebsites.net zeigt, verrät App Service, azure-api.net steht für API Management, azurefd.net für Azure Front Door, blob.core.windows.net für Blob Storage und azureedge.net für das CDN. Auch ein TLS-Zertifikat kann sprechen: Taucht im Subject Alternative Name eine interne azurewebsites.net-Subdomain auf, die eigentlich nicht für die Öffentlichkeit gedacht war, ist das ein klarer Hinweis auf die zugrunde liegende Hosting-Plattform, unabhängig davon, welcher Domainname vorne im Browser steht.

    Verhaltens-Signale: wie der Server auf Fehler reagiert

    Manchmal verrät sich ein Stack nicht durch das, was er sendet, sondern durch das, wie er auf Fehler reagiert. Eine 400er-Antwort im ProblemDetails-Format nach RFC 7807, erkennbar am charakteristischen JSON mit den Feldern type, title, status und detail, ist das Standard-Fehlerformat von ASP.NET Core. Ein Endpunkt unter /health oder /healthz, der mit dem einzelnen Wort „Healthy“ antwortet, folgt der Namenskonvention der .NET-Health-Checks-Bibliothek.

    Der wichtigste Punkt in dieser Kategorie ist aber keine reine Erkennungshilfe, sondern ein eigenständiges Sicherheitsproblem: eine öffentlich erreichbare Developer-Exception-Page. Diese Seite ist in ASP.NET Core standardmäßig für die Entwicklungsumgebung gedacht und zeigt im Fehlerfall den vollständigen Stacktrace, interne Dateipfade und teilweise sogar Umgebungsvariablen an. Landet sie versehentlich in der Produktion, verrät sie nicht nur den Stack, sondern liefert einem Angreifer eine Bauanleitung für die eigene Infrastruktur frei Haus. Wer diese Seite bei einem eigenen Dienst öffentlich erreichbar findet, sollte das nicht als Kuriosität behandeln, sondern als High-Finding in jedem ernst gemeinten Bericht.

    Klartext für Techniker: Die Developer-Exception-Page lässt sich mit einer einzigen Zeile in Program.cs abschalten (app.UseExceptionHandler statt app.UseDeveloperExceptionPage() außerhalb der Development-Umgebung). Trotzdem taucht sie in der Praxis immer wieder produktiv auf, meist weil eine Umgebungsvariable falsch gesetzt ist oder ein Staging-Deployment versehentlich zum Live-System wurde.

    Wie sicher ist ein Fund wirklich? Die vier Stufen

    Nicht jedes Signal ist gleich viel wert, und genau hier passiert der häufigste Fehler bei technischer Bestandsaufnahme: ein einzelnes schwaches Indiz wird als Gewissheit verkauft. Vier Stufen helfen, das sauber zu trennen.

    Sicher ist ein Fund, wenn ein einzelnes Signal keine andere Erklärung zulässt. Das Cookie .AspNetCore.Cookies gehört in diese Kategorie: Es existiert nur, wenn ASP.NET Core Authentication tatsächlich läuft.

    Stark indiziert ist ein Fund, wenn mehrere unabhängige Signale in dieselbe Richtung zeigen, aber theoretisch auch anders erklärbar wären. Ein ARRAffinity-Cookie zusammen mit einem CNAME auf eine azurewebsites.net-Domain ergibt zusammen ein sehr stimmiges Bild, auch wenn keines der beiden Signale für sich allein hundertprozentig wäre.

    Bloße Vermutung ist ein Fund, wenn sich eine Website wie eine typische ASP.NET-Core-Anwendung verhält, ohne dass ein einziger harter Marker auftaucht, kein passendes Cookie, kein verräterischer Header. Solche Vermutungen gehören in einen Bericht, aber klar als Vermutung gekennzeichnet, nicht als Tatsache formuliert.

    Intern bestätigt ist die höchste Stufe, aber sie erfordert einen Blick hinter die Fassade, der von außen gar nicht möglich ist: Ein Eintrag wie Microsoft.ApplicationInsights.AspNetCore in der .csproj-Datei des Projekts belegt den Stack zweifelsfrei, setzt aber internen Zugriff auf den Quellcode voraus. Für externe Betrachter bleibt diese Stufe unerreichbar, und genau das ist der entscheidende Unterschied zu den ersten drei Stufen.

    Klartext für Geschäftsführer: Wenn Ihnen jemand sagt „Ihre Seite läuft auf Azure“, fragen Sie nach, worauf sich das stützt. Ein Cookie-Name ist ein Beweis. Ein „sieht danach aus“ ist eine Meinung. Der Unterschied entscheidet darüber, ob eine Aussage in einem Bericht Gewicht hat oder nicht.

    Die Grenze, die zählt: nur passiv, nie ohne Freigabe

    Alle bisher genannten Signale lassen sich beobachten, ohne einen einzigen ungewöhnlichen Request abzusetzen. Ein Header lesen, ein Cookie im Browser ansehen, einen DNS-Eintrag abfragen, eine ohnehin öffentlich erreichbare Seite mit ihrem regulären Aufruf laden: Das sind passive, nicht-invasive Checks, die technisch nicht anders aussehen als ein gewöhnlicher Website-Besuch.

    Damit endet aber auch die Grenze dessen, was ohne Zustimmung des Betreibers vertretbar ist. Wer testet, ob ein /swagger-Endpunkt existiert, bewegt sich noch im passiven Bereich. Wer beginnt, Pfade systematisch durchzuprobieren, Authentifizierung zu umgehen oder gezielt nach ausnutzbaren Schwachstellen zu suchen, verlässt diesen Bereich und braucht eine ausdrückliche Freigabe des Betreibers. Brute-Forcing, Fuzzing oder gar der Versuch, eine erkannte Schwäche tatsächlich auszunutzen, sind ohne diese Freigabe nicht bloß eine Stilfrage, sondern strafrechtlich relevant. Diese Grenze gilt unabhängig davon, wie interessant ein gefundenes Signal aussieht.

    Was das für die eigene Website bedeutet

    Wer diese Signale kennt, kann sie an der eigenen Infrastruktur gegenprüfen. Bei vielen Unternehmens-Webseiten, die auf Azure App Service laufen, reicht schon ein Blick in die Browser-Entwicklertools, um ARRAffinity, einen x-azure-ref-Header und mitunter sogar den Application-Insights-Instrumentation-Key im Quelltext zu finden, ganz ohne dass jemand danach gesucht hätte. Keines dieser Signale ist für sich genommen ein Sicherheitsproblem, aber in der Summe zeichnen sie ein Bild der eingesetzten Technik, das nicht jeder Betreiber bewusst so öffentlich stehen lassen wollte. Wer die eigene Angriffsfläche kennt, kann selbst entscheiden, welche Header verzichtbar sind und welche Fehlerseite in der Produktionsumgebung wirklich nichts zu suchen hat.


    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 26.07.2026. Aktives Testen fremder Systeme ohne Zustimmung des Betreibers kann strafrechtlich relevant sein (§ 202a ff. StGB).

  • .NET-Sicherheitsluecken bei Unternehmens-Webseiten: Vom geleakten Machine Key zum kritischen Framework-Bug
    Symbolbild, KI-generiert

    .NET-Sicherheitsluecken bei Unternehmens-Webseiten: Vom geleakten Machine Key zum kritischen Framework-Bug

    Am 6. Februar 2025 veröffentlichte Microsoft einen Security-Blog-Eintrag mit einer Zahl, die aufhorchen lässt: mehr als 3.000 öffentlich exponierte ASP.NET Machine Keys, mit denen Angreifer zwischen dem 11. und 19. Dezember 2024 gefälschte ViewState-Pakete in fremde IIS-Server einschleusten und darüber Code im Kontext des Worker-Prozesses w3wp.exe ausführten. Kein Zero-Day, kein exotischer Exploit. Nur ein kryptografischer Schlüssel, der eigentlich geheim sein sollte und es nicht war.

    Ein Schlüssel aus der Doku ist kein Schlüssel mehr

    Der Mechanismus dahinter ist unspektakulär, gerade deshalb gefährlich. ASP.NET verschlüsselt und signiert den sogenannten ViewState, den Zustand einer Webseite zwischen Formular-Postbacks, mit einem Machine Key aus der web.config. Wer diesen Key kennt, kann eigene ViewState-Pakete bauen und signieren, die der Server als legitim akzeptiert, samt eingeschleustem Code. Das Problem: Viele Entwickler übernehmen Beispiel-Keys direkt aus Tutorials, Stack-Overflow-Antworten oder Doku-Snippets, statt sich selbst zufällige Werte generieren zu lassen. Ein Key, der einmal öffentlich in einem Code-Repository oder einer Anleitung stand, bleibt öffentlich, egal wie viele Jahre seitdem vergangen sind. Die Angreifer, die Microsoft im Februar 2025 beschrieb, setzten anschließend das Post-Exploitation-Framework Godzilla ein, komplett mit Shellcode-Injection und persistenter Command-Execution.

    Wie real dieses Muster ist, zeigte sich noch einmal im September 2025 an einem völlig anderen Fall: Bei einem verbreiteten .NET-basierten CMS wurde eine kritische ViewState-Deserialisierungslücke bekannt, CVSS 9,0, deren Ursache ein Beispiel-Key aus der eigenen Dokumentation von vor 2017 war, der in Produktivsystemen weiterlief. Die Angriffskette folgte demselben Schema wie beim Massenangriff: Sondierung eines exponierten ViewState-Formulars, Payload mit bekanntem Key, Remote Code Execution, danach Post-Exploitation-Tools zur Rechteausweitung und Aufklärung im Netzwerk. Es geht hier nicht um das Produkt selbst, das reagierte mit einem eigenen Advisory und Patches. Es geht um den Beleg, dass diese Angriffsklasse nicht theoretisch ist, sondern in freier Wildbahn ausgenutzt wird, sobald ein Machine Key öffentlich auffindbar ist.

    Klartext für Geschäftsführer: Wenn Ihre Webseite oder Ihr Kundenportal auf ASP.NET läuft, lohnt sich eine einzige Frage an Ihre Entwicklung oder Ihren Dienstleister: Wurde der Machine Key jemals selbst generiert, oder stammt er noch aus einer Vorlage? Diese Frage kostet fünf Minuten und schließt eine der am aktivsten ausgenutzten Lücken der letzten anderthalb Jahre.

    Zwei kritische Lücken direkt im Framework, nicht im Altbestand

    Das Machine-Key-Problem ist ein Legacy-Thema, entstanden aus Copy-Paste-Gewohnheiten über Jahre. Wer daraus schließt, aktuelle .NET-Versionen seien automatisch sicherer, sollte zwei Fälle aus 2025 und 2026 kennen.

    CVE-2025-55315 betrifft Kestrel, den Webserver, den praktisch jede ASP.NET-Core-Anwendung unter der Haube nutzt. CVSS 3.1: 9,9, laut NVD verursacht durch uneinheitliches Parsing von HTTP-Requests zwischen vorgeschalteten Proxys oder Load-Balancern und Kestrel selbst, eine klassische Request-Smuggling-Schwäche, mit der sich eine zweite, versteckte Anfrage in eine legitime einschmuggeln lässt und dadurch Sicherheitsprüfungen umgeht. Betroffen waren ASP.NET Core 2.3 vor Version 2.3.6, 8.0 vor 8.0.21 sowie 9.0 vor 9.0.10. Microsoft veröffentlichte den Patch am 14. Oktober 2025. Laut Presseberichten, unter anderem CSO Online, war es der höchste je an eine ASP.NET-Core-Lücke vergebene Schweregrad. Diese Einordnung stammt nicht aus dem MSRC-Blog selbst, aber der CVSS-Wert von 9,9 ist NVD-belegt und spricht für sich.

    Ein halbes Jahr später, am 21. April 2026, folgte CVE-2026-40372: eine Regression in den Microsoft.AspNetCore.DataProtection-NuGet-Paketen, Versionen 10.0.0 bis 10.0.6, CVSS 9,1. Der managed authenticated encryptor berechnete die HMAC-Prüfsumme über die falschen Bytes der Nutzlast, teils wurde der berechnete Hash sogar verworfen. Damit ließen sich signierte Payloads fälschen, darunter Auth-Cookies. Microsoft wurde nach eigener Darstellung über Nutzerberichte aufmerksam, die nach dem Update auf .NET 10.0.6 von fehlgeschlagenen Entschlüsselungen berichteten. Der Fix folgte einen Tag später, am 22. April, mit Version 10.0.7.

    Ein drittes, kleineres Beispiel rundet das Bild ab: CVE-2025-24070, CVSS 7,0, ein Logikfehler in RefreshSignInAsync, der bei unzureichend authentifiziertem User-Parameter dazu führen konnte, dass sich ein Angreifer faktisch als anderer Nutzer anmelden ließ. Betroffen waren ASP.NET Core 8.0 (bis 8.0.13) und 9.0 (bis 9.0.2). Ein Presseartikel von TuxCare behauptet zusätzlich, auch .NET 6 sei trotz fehlender offizieller Dokumentation betroffen. Diese Zusatzbehauptung lässt sich am offiziellen GitHub-Security-Advisory nicht direkt nachvollziehen, sie steht hier nur der Vollständigkeit halber und mit klarer Quellenangabe.

    Klartext für Techniker: Alle drei Lücken wurden über Patches geschlossen, keine davon erfordert Architekturänderungen. Der eigentliche Risikofaktor ist die Zeit zwischen Advisory und Update-Einspielung. Bei CVE-2025-55315 lagen zwischen Bekanntwerden und breiter Ausnutzung in der Praxis wenige Wochen, das ist der Zeitraum, in dem Patch-Management über Kompromittierung entscheidet.

    Der Klassiker, der einfach nicht sterben will

    Neben den CVE-nummerierten Lücken gibt es eine strukturelle Schwäche, die seit weit über zehn Jahren dokumentiert ist und trotzdem regelmäßig in aktuellen Scans auftaucht: die IIS-Tilde-Enumeration. Windows-Dateisysteme generieren für lange Dateinamen automatisch kurze 8.3-Namen. IIS beantwortet speziell präparierte Tilde-Requests mit unterschiedlichen HTTP-Statuscodes, je nachdem, ob eine Datei oder ein Ordner mit passendem Kurznamen existiert. Aus diesem Unterschied lässt sich systematisch ableiten, welche Dateien und Verzeichnisse auf dem Server liegen, einschließlich Konfigurations- und Wartungsskripten, die eigentlich nicht auffindbar sein sollten. Kein CVE, keine Versionsnummer, keine Ausnutzung eines Bugs im eigentlichen Sinn, nur ein seit Jahren bekanntes Verhalten, das schlicht nie deaktiviert wurde. Genau das macht es interessant: Während CVE-Lücken irgendwann gepatcht sind, bleibt diese Schwäche so lange bestehen, bis sie jemand aktiv abschaltet.

    Was tatsächlich zu tun ist

    Vier Punkte lassen sich ohne größeren Aufwand prüfen, unabhängig davon, welches CMS oder Framework konkret im Einsatz ist.

    Erstens, Machine-Key-Herkunft klären. Ein Key aus Doku, Tutorial oder Beispielprojekt gehört ersetzt, unabhängig vom Alter der Anwendung. Microsoft empfiehlt zusätzlich regelmäßige Rotation und Verschlüsselung der web.config-Sektionen, in denen der Key liegt.

    Zweitens, Patch-Stand der ASP.NET-Core-Version gegen die aktuellen Advisories prüfen, nicht nur einmalig, sondern als wiederkehrenden Termin. CVE-2025-55315 und CVE-2026-40372 zeigen, dass selbst brandneue, gerade erst veröffentlichte Paketversionen kritische Lücken enthalten können.

    Drittens, 8.3-Kurznamen-Generierung auf dem IIS-Server per fsutil deaktivieren, wo technisch möglich, alternativ Tilde- und Wildcard-Muster über IIS Request Filtering oder eine vorgeschaltete Web Application Firewall blockieren.

    Viertens, und das lässt sich nicht outsourcen: eine Liste führen, welche .NET- und ASP.NET-Core-Version auf welchem System läuft. Ohne diese Übersicht bleibt jede der drei genannten CVE-Nummern eine abstrakte Meldung statt einer konkreten, prüfbaren Frage.

    Wer diese vier Punkte nicht selbst beantworten kann, hat damit bereits die erste, wichtigste Erkenntnis dieses Artikels: eine offene Frage, die vor dem nächsten Deployment geklärt gehört, nicht danach.


    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 26.07.2026. Er ersetzt keine anwaltliche oder technische Prüfung des konkreten Sachverhalts und begründet keine Zusicherung von Rechtssicherheit oder IT-Sicherheit.

  • Cookie-Einwilligung vor Gericht: Von Planet49 bis zum Schutzgesetz § 25 TDDDG
    Symbolbild, KI-generiert

    Cookie-Einwilligung vor Gericht: Von Planet49 bis zum Schutzgesetz § 25 TDDDG

    Ein vorangekreuztes Kästchen unter einem Gewinnspielformular hat 2019 den EuGH beschäftigt. Sechs Jahre später ist aus diesem einen Kästchen eine eigenständige zivilrechtliche Haftungsgrundlage geworden, die längst nicht mehr nur den Websitebetreiber selbst trifft. Fünf Entscheidungen zeichnen diesen Weg nach: von der Frage, ob eine IP-Adresse überhaupt personenbezogen ist, über das eigentliche Einwilligungserfordernis bei Cookies, bis zur aktuellen Frage, wer haftet, wenn mehrere Akteure gleichzeitig am Setzen eines Cookies mitwirken.

    Der Unterbau: ist eine IP-Adresse überhaupt personenbezogen?

    Bevor es um Einwilligung gehen kann, muss geklärt sein, ob Tracking-Daten überhaupt dem Datenschutzrecht unterliegen. Am 19. Oktober 2016 beantwortete der EuGH (C-582/14, ECLI:EU:C:2016:779) im Verfahren Breyer/Bundesrepublik Deutschland eine Frage, die heute selbstverständlich klingt, es damals aber nicht war: Eine dynamische IP-Adresse kann für den Websitebetreiber personenbezogen sein, wenn rechtliche Mittel zur Identifizierung bestehen, also wenn er selbst oder ein Dritter (etwa der Access-Provider) die Person mit zumutbarem Aufwand ermitteln könnte. Der bloße Umstand, dass der Websitebetreiber die IP-Adresse allein nicht direkt einer Person zuordnen kann, reicht demnach nicht, um sie aus dem Anwendungsbereich herauszunehmen.

    Breyer beantwortet damit die Vorfrage, ab wann Tracking-Daten überhaupt Personenbezug haben, und damit, wann neben dem Einwilligungserfordernis für den Endgeräte-Zugriff auch die Pflichten der DSGVO greifen, bis hin zum Schadensersatz nach Art. 82 DSGVO. Das Einwilligungserfordernis für Cookies selbst gilt dagegen unabhängig vom Personenbezug, weil es an den Zugriff auf das Endgerät anknüpft, nicht an die Frage, ob die dabei verarbeiteten Daten personenbezogen sind.

    Planet49: das vorangekreuzte Kästchen fällt

    Drei Jahre später, am 1. Oktober 2019, entschied der EuGH (C-673/17, ECLI:EU:C:2019:801) im Fall Planet49: Ein vorangekreuztes Cookie-Kästchen stellt keine wirksame Einwilligung dar. Nutzer müssen zudem über Speicherdauer und Drittzugriff informiert werden, bevor sie einwilligen, nicht danach und nicht nur auf Nachfrage. Wer eine Zustimmung durch ein bereits gesetztes Häkchen simuliert, das der Nutzer lediglich stehen lassen oder aktiv entfernen kann, holt keine Einwilligung ein, sondern unterstellt sie.

    Der BGH musste die deutsche Umsetzung dieser Linie noch selbst nachvollziehen: Am 28. Mai 2020 stellte er klar (I ZR 7/16, ECLI:DE:BGH:2020:280520UIZR7.16.0), dass ein voreingestelltes Häkchen für nicht funktionale Cookies auch nach deutschem Recht keine wirksame Einwilligung darstellt. § 15 Abs. 3 TMG a. F., die damalige Vorgängernorm zur heutigen Cookie-Regelung, war richtlinienkonform als Opt-in-Regelung auszulegen, nicht als Opt-out. Wer sich also darauf verlassen hatte, dass deutsches Recht laxer sei als die EU-Vorgabe, bekam vom eigenen Bundesgerichtshof eine klare Antwort: nein.

    Klartext für Geschäftsführer: Diese beiden Urteile sind der Grund, warum es heute überhaupt Cookie-Banner mit echten „Ablehnen“-Buttons gibt. Ein Banner, das Zustimmung durch Nichtstun unterstellt, lieferte schon 2019/2020 keine wirksame Einwilligung, die Datenverarbeitung stand damit von Anfang an ohne Rechtsgrundlage da, nicht erst seit der aktuellen Generation von Bannerprüfungen.

    VG Köln: Verantwortlichkeit ist nicht automatisch geteilt

    Fünf Jahre nach dem BGH-Urteil stellte sich eine neue Frage: Wenn beim Setzen eines Cookies mehrere Akteure technisch mitwirken, wer trägt dann die datenschutzrechtliche Verantwortung? Am 17. Juli 2025 entschied das VG Köln (13 K 1419/23, ECLI:DE:VGK:2025:0717.13K1419.23.00): Cookie-Zugriff auf ein Endgerät kann mehrere Akteure gleichzeitig zur datenschutzrechtlichen Verantwortlichkeit verpflichten. Im konkreten Fall, einer Facebook-Fanpage des Bundespresseamts, kam das Gericht aber zu einem differenzierten Ergebnis: Mangels gemeinsamer Zweck- und Mittelbestimmung war das Bundespresseamt hier gerade nicht gemeinsam Verantwortlicher mit dem Plattformanbieter. Der entsprechende Bescheid wurde aufgehoben. Das Urteil ist nicht rechtskräftig.

    Das ist bewusst kein Automatismus. Wer eine Plattform-Funktion nutzt, wird nicht allein dadurch automatisch Mitverantwortlicher für jedes Cookie, das die Plattform im Hintergrund setzt, es kommt auf die konkrete Ausgestaltung an, ob Zweck und Mittel gemeinsam festgelegt werden. Das steht nicht im Widerspruch zum bereits veröffentlichten Urteil zu den Meta Business Tools (OLG Hamm, 8 U 21/25), in dem eine gemeinsame Verantwortlichkeit gerade bejaht wurde, weil dort die konkrete Ausgestaltung anders lag. Beide Urteile im Detail: Meta Business Tools und Tracking-Haftung.

    Klartext für Techniker: „Wir sind nur Nutzer der Plattform, nicht der Cookie-Betreiber“ ist keine automatische Ausrede, aber auch keine automatische Haftungsfalle. Entscheidend ist, ob die konkrete Einbindung eine gemeinsame Zweck- und Mittelbestimmung mit dem Plattformanbieter begründet. Annahme: Je enger eine Funktion in eigene Marketingzwecke eingebettet wird (etwa gezieltes Ansprechen bestimmter Nutzergruppen über Plattform-Werkzeuge), desto eher liegt eine solche gemeinsame Festlegung nahe, dieser Schluss geht über die reine Urteilsaussage hinaus.

    OLG Frankfurt: § 25 TDDDG wird zum Schutzgesetz für alle Mitwirkenden

    Den bislang weitreichendsten Schritt dieser Linie machte das OLG Frankfurt am 11. Dezember 2025 (6 U 81/23, ECLI:DE:OLGHE:2025:1211.6U81.23.00): § 25 TDDDG ist Schutzgesetz, gemeint ist ein Schutzgesetz im Sinne von § 823 Abs. 2 BGB, das dem Einzelnen einen eigenen zivilrechtlichen Anspruch gibt, und nicht auf den Websitebetreiber beschränkt. Jeder am Setzen von Cookies Mitwirkende, ausdrücklich auch Drittanbieter, kann unmittelbar auf Unterlassung und Schadensersatz nach Art. 82 DSGVO haften. Wer bislang dachte, nur der Websitebetreiber selbst müsse sich um die Cookie-Einwilligung sorgen und Drittanbieter könnten sich hinter dem Betreiber verstecken, muss dieses Urteil ernst nehmen.

    Anmerkung zur Normbezeichnung: Das VG-Köln-Verfahren zitiert § 25 TTDSG, das OLG-Frankfurt-Verfahren § 25 TDDDG. Dahinter steht dieselbe Vorschrift: Das TTDSG wurde zum 14. Mai 2024 durch das Digitale-Dienste-Gesetz in TDDDG umbenannt, § 25 blieb inhaltlich unverändert. Ältere Entscheidungen und Muster-Datenschutzerklärungen tragen deshalb noch die alte Bezeichnung, ohne dass sich die Rechtslage geändert hätte.

    Was heißt das nun für die eigene Website? Ein Websitebetreiber, der Cookies über Werbenetzwerke oder Analyse-Dienstleister setzen lässt, bleibt für die Einwilligung selbst verantwortlich, nach dem OLG Frankfurt kann der Dienstleister daneben aber unmittelbar selbst in Anspruch genommen werden. Annahme: Wie weit das auf Consent-Management-Plattformen durchschlägt, die selbst technisch Zugriff auf das Endgerät nehmen, ist damit noch nicht entschieden, dieser Schluss geht über die Urteilsaussage hinaus. Wie genau ein Banner gestaltet sein darf, ohne die Einwilligung durch Design zu verzerren, war bereits Gegenstand eines anderen, bereits veröffentlichten Urteils: Cookie-Banner-Nudging vor dem VG Hannover.

    Die Urteile im Überblick

    DatumGerichtAz.Kernaussage
    19.10.2016EuGHC-582/14Dynamische IP-Adresse kann personenbezogen sein (Breyer)
    01.10.2019EuGHC-673/17Vorangekreuztes Kästchen ist keine wirksame Einwilligung (Planet49)
    28.05.2020BGHI ZR 7/16§ 15 Abs. 3 TMG a. F. richtlinienkonform als Opt-in auszulegen
    17.07.2025VG Köln13 K 1419/23Mehrere Akteure können gleichzeitig verantwortlich sein, aber nicht automatisch
    11.12.2025OLG Frankfurt6 U 81/23§ 25 TDDDG ist Schutzgesetz, gilt auch für Drittanbieter

    Was für die Geschäftsführung zählt: Die Cookie-Einwilligung ist längst kein reines Consent-Banner-Thema mehr, das man einmal einrichtet und dann vergisst. Zwischen Planet49 und dem OLG-Frankfurt-Urteil liegt eine Entwicklung von „der Websitebetreiber muss richtig fragen“ zu „jeder Mitwirkende kann direkt haften“. Wer Werbenetzwerke, Tracking-Pixel oder Drittanbieter-Skripte einsetzt, sollte diese Kette kennen, weil sie das eigene Haftungsrisiko unmittelbar mitbestimmt.

    Was für die Technik zählt: Aus den Urteilen selbst folgt unmittelbar nur eines: eine echte Opt-in-Logik ohne vorangekreuzte Kästchen, mit Information über Speicherdauer und Drittzugriff vor der Einwilligung. Annahme, über die Urteile hinaus: Wer die Risiken aus VG Köln und OLG Frankfurt praktisch beherrschen will, sollte zusätzlich je Drittanbieter festhalten, ob eine gemeinsame Zweck- und Mittelfestlegung im Sinne von Art. 26 DSGVO vorliegt, und ob der Anbieter selbst am Setzen von Cookies mitwirkt. Ist einer dieser Punkte offen, bleibt ein Haftungsrisiko bestehen, das nicht mehr nur beim Websitebetreiber landet.

    Diese Serie endet mit diesem fünften Teil. Wer die vorherigen vier Teile noch nicht kennt, findet sie oben unter „Serien-Hinweis“ verlinkt.


    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 23.07.2026.

  • Über 100 Patientenakten in einem Bauschutt-Schrank: Wie ein Krankenhaus in Mecklenburg-Vorpommern ein Bußgeld kassierte
    Symbolbild, KI-generiert

    Über 100 Patientenakten in einem Bauschutt-Schrank: Wie ein Krankenhaus in Mecklenburg-Vorpommern ein Bußgeld kassierte

    969 Beschwerden und Eingaben gingen 2024 beim Landesbeauftragten für Datenschutz und Informationsfreiheit Mecklenburg-Vorpommern (LfDI MV) ein, ein Anstieg gegenüber 898 im Vorjahr. Am 3. Februar 2026 legte Sebastian Schmidt seinen 20. Tätigkeitsbericht vor und betonte vor allem den Rückgang der Datenpannenmeldungen nach Art. 33 DSGVO (von 401 auf 290) sowie die gestiegene Zahl an Beschwerden zur Videoüberwachung. Die drei einprägsamsten Einzelfälle des Berichts liegen jedoch abseits dieser Schwerpunkte: ein Krankenhaus, das über 100 Patientenakten in einem kaputten Aktenschrank auf einer frei zugänglichen Baustelle vergaß, ein Polizist, der dienstliche Datenbanken für politisch motivierte Einschüchterung missbrauchte, und ein gemeinnütziger Verein, der als erster seiner Art eine förmliche Verwarnung kassierte.

    Der Aktenschrank auf der Baustelle

    Eine anonyme Beschwerde brachte den LfDI MV auf die Spur: In einem frei zugänglichen Baustellenbereich eines Krankenhauses solle ein unverschlossener Schrank mit Patientenakten stehen. Die Behörde beschreibt, was ihre Kontrolleure vor Ort, begleitet von einer Beschäftigten des Krankenhauses, vorfanden: „Wir konnten unbehelligt ein älteres und offenes Gemäuer betreten und fanden in der zweiten Etage auf einer Baustelle tatsächlich einen in die Jahre gekommenen, defekten Aktenschrank mit über 100 Patientenakten. Daneben lag eine Matratze, die sehr wahrscheinlich keinem Beschäftigten des Krankenhauses, sondern unbefugten Dritten in eher jüngerer Vergangenheit als Schlafplatz gedient haben dürfte.“ Eine kursorische Durchsicht der Akten, mit Zustimmung des Krankenhauses, ergab zudem, dass „nicht nur der Schrank, sondern auch die Fälle in den Akten recht alt waren und längst hätten vernichtet sein müssen“.

    Das Krankenhaus reagierte nach Angaben des Berichts sofort: Die Akten wurden geborgen, gesichtet und vernichtet, zudem sicherte die Einrichtung eine Verbesserung der Prozesse zu. Die Behörde zieht daraus trotzdem eine klare Konsequenz: „Gleichwohl ist nach der DS-GVO in solchen Fällen der Erlass eines Bußgeldes die Regel. Durch die Vor-Ort-Kontrolle wurden aber die besonderen Gegebenheiten und Herausforderungen, vor denen das Krankenhaus stand, sowie vor allem auch dessen sofortige Kooperationsbereitschaft sichtbar. Diese Umstände flossen unmittelbar in die Bemessung des Bußgeldes ein und führten deutlich zu dessen Reduzierung.“

    Klartext für Geschäftsführer: Der entscheidende Satz in diesem Fall ist nicht der über den Aktenschrank, sondern der über das Bußgeld, es fiel trotz sofortiger Kooperation, nicht wegen ihrer Abwesenheit. Die Behörde macht deutlich, dass Kooperation die Höhe mildert, die Verhängung aber nicht verhindert. Für jedes Unternehmen mit physischen Akten (Personalakten, Kundendaten, Patientendaten, Verträge) heißt das: Löschfristen sind keine Kür, sondern eine Bußgeld-Vermeidung. Wer Papierakten auslagert, sei es bei einer Renovierung, einem Umzug oder einer Zwischenlagerung während eines Umbaus, muss denselben Sicherheitsstandard einhalten wie am regulären Standort. Eine Baustelle ist kein rechtsfreier Zwischenzustand.

    Klartext für Techniker: Dieser Fall betrifft physische, nicht digitale Sicherheit, ein Erinnerungsposten, der in reinen IT-Sicherheitskonzepten oft fehlt. Die zwei technischen Lehren: Erstens, Löschkonzepte (Art. 5 Abs. 1 lit. e DSGVO, Speicherbegrenzung, eigene rechtliche Einordnung, kein Behördenzitat) müssen auch für Papierakten dokumentierte Fristen und Vernichtungsnachweise vorsehen, nicht nur für Datenbanken. Zweitens: Bei jeder Standortverlagerung von Akten (Umzug, Umbau, Zwischenlagerung) braucht es eine geprüfte Übergabe- und Verwahrungskette, wer verantwortet den Schrank, wer hat Zugriff, wann wird er kontrolliert. Der Fund einer Matratze neben dem Schrank deutet darauf hin, dass unbefugte Dritte über einen längeren Zeitraum ungehinderten Zugang zum Gebäudeteil hatten, das ist kein reines Datenschutzproblem, sondern zugleich eine Zutrittskontroll-Lücke nach Art. 32 DSGVO.

    Der Polizist mit der besonderen Nähe zu einer politischen Partei

    Deutlich politischer ist ein zweiter, im Bericht unter Ziffer 11.2 kurz eingeordneter Fall, der sich in einer eigenen Pressemitteilung vom 5. September 2024 ausführlicher nachvollziehen lässt. Der Bericht beschreibt das Muster so: „Rechtskräftig werden angefochtene Bußgelder aber häufig nur dann, wenn uns der Nachweis gelingt, dass die oder der Betroffene die Daten auch tatsächlich weiterverwendet hat. Geschehen ist dies beispielsweise im Fall eines Polizisten, der eine besondere Nähe zu einer politischen Partei aufwies und politisch anders Denkende auf Facebook mit seinem widerrechtlich erlangten Spezialwissen über diese Personen unter Druck gesetzt hat.“

    Die zugehörige Pressemitteilung liefert den vollen Sachverhalt: Ein Polizist aus Mecklenburg-Vorpommern soll „aus polizeilichen Systemen Daten politisch Andersdenkender abgefragt und an Rechtsextreme weitergegeben haben“. Strafrechtlich blieb das folgenlos, „die Generalstaatsanwaltschaft sah es als nicht nachweisbar an, dass tatsächlich Daten weitergegeben worden sind“, und im Januar 2023 scheiterten die betroffenen Personen selbst vor dem Bundesverfassungsgericht mit dem Versuch, eine strafrechtliche Verfolgung zu erzwingen. Der LfDI MV nahm daraufhin das ruhende Ordnungswidrigkeitsverfahren wieder auf: „Der rechtswidrige Abruf personenbezogener Daten stellt regelmäßig keine Straftat jedoch eine Ordnungswidrigkeit dar, für deren Verfolgung der LfDI MV zuständig ist.“ Der zunächst eingelegte Einspruch gegen den Bußgeldbescheid wurde in der Verhandlung vor dem Amtsgericht Schwerin zurückgenommen, der Bescheid ist seither rechtskräftig.

    Sebastian Schmidt kommentierte den Fall deutlich: „Der Staat verarbeitet sensible Daten seiner Bürgerinnen und Bürger. […] Im Gegenzug muss jedoch alles dafür unternommen werden, dass diese Daten auch sicher und vor illegalen Zugriffen geschützt sind. Es darf kein Zweifel daran bestehen, dass der Staat auch sanktioniert, wenn Beschäftigte im öffentlichen Dienst ihnen zu dienstlichen Zwecken zur Verfügung stehende Datenbanken nutzen, um andere auszuspionieren.“ Und weiter: „Wer nunmehr ohne dienstlichen Anlass Datenabrufe tätigt, muss mit einem Bußgeld rechnen.“

    Klartext für Geschäftsführer: Auch wenn dieser Fall im öffentlichen Dienst spielt, gilt dasselbe Prinzip in jedem Unternehmen mit sensiblen internen Datenbanken (Personalakten, Kundendaten, Gesundheitsdaten): Ein fehlgeschlagenes Strafverfahren beendet nicht automatisch das datenschutzrechtliche Verfahren, beide laufen unabhängig voneinander, mit unterschiedlichen Beweismaßstäben. Der Bericht nennt dafür an anderer Stelle (Einleitung zu Ziffer 11.2) den gesetzlichen Rahmen: Für unbefugte Datenabfragen durch Beschäftigte sieht das Datenschutzgesetz M-V (DSG M-V) ebenso wie das Landeskrankenhausgesetz M-V (LKHG M-V) eigene Bußgeldtatbestände mit einem Bußgeldrahmen von bis zu 50.000 Euro vor. Das ist die gesetzliche Obergrenze, kein in diesem Fall verhängter Betrag, aber ein Signal dafür, in welcher Größenordnung sich Verstöße durch einzelne Beschäftigte bewegen können.

    Klartext für Techniker: Der Bericht beschreibt an anderer Stelle im selben Abschnitt, wie Zugriffe in der Praxis unautorisiert erfolgen, nicht durch technisches Hacking, sondern durch schlichte Nachlässigkeit: weitergegebene Passwörter, umgangene Bildschirmsperren, unterlassenes Abmelden beim Verlassen des Arbeitsplatzes. Der entscheidende Beweis-Hebel im Polizisten-Fall war laut Pressemitteilung nicht der Abruf selbst, sondern die nachweisbare Weiterverwendung der Daten über Social-Media-Kanäle, Protokolldaten allein reichen der Behörde offenbar oft nicht für ein rechtskräftiges Bußgeld, wenn Beschuldigte (wie im Bericht beschrieben) Zugriff auf ein geteiltes Passwort behaupten. Der Bericht empfiehlt ausdrücklich, „die internen Authentifizierungsprozesse zu überprüfen“ und verschiedene, stärkere Authentifizierungsmöglichkeiten einzusetzen, „um eine eindeutige Zuordnung der abrufenden Person“ zu ermöglichen, eine wörtliche Empfehlung zur Zwei-Faktor-Authentifizierung enthält der Bericht nicht. Wer Zugriffsprotokolle als Beweismittel nutzbar halten will, sollte diese Empfehlung als das lesen, was sie ist: ein Auftrag zur eindeutigen Personenzuordnung beim Login, für den 2FA die naheliegende eigene Konkretisierung ist, keine Bericht-Vorgabe.

    Der Verein mit der ersten Verwarnung seiner Art

    Der dritte Fall ist kleiner im Ausmaß, aber bemerkenswert, weil er laut Bericht ein Novum ist. Ein gemeinnütziger Verein soll Personaldaten einer ehemaligen Minijobberin an die Rechtsanwältin ihres leiblichen Vaters weitergegeben haben, die in einem familiengerichtlichen Sorgerechtsstreit aus dem Personalfragebogen der Frau zitierte. Der Bericht schildert den Weg zur Aufklärung ausführlich: Der Verein habe zunächst „jede Verantwortung von sich“ gewiesen, bis ihn der LfDI MV mit Auszügen aus den Gerichtsakten konfrontierte. Die vom Verein daraufhin präsentierte Verteidigung, die neue Ehefrau des leiblichen Vaters habe bei einem Vereinsbesuch „unter dem Vorwand, zur Toilette zu gehen, die Personalunterlagen der Beschwerdeführerin offen einsehbar herumliegen sehen und unbemerkt kopiert“, hielt die Behörde für unglaubwürdig, unter anderem weil Vater und neue Partnerin „in einem anderen Teil Deutschlands“ lebten.

    Die rechtliche Bewertung bleibt davon aber unberührt: „Selbst wenn jedoch davon ausgegangen wird, dass die Schilderung des Beschwerdegegners zutrifft, muss der Verein die datenschutzrechtlichen Anforderungen erfüllen. Z. B. muss auch der Verein angemessene technische und organisatorische Maßnahmen zum Schutz von Beschäftigtendaten gemäß Art. 32 DS-GVO ergreifen. Bei der Offenlegung des Personalfragebogens ehemaliger Beschäftigter mit der Möglichkeit zur Einsicht und Erstellung einer Kopie auf dem Weg zur Toilette kann von solchen Schutzmaßnahmen jedoch keine Rede sein.“ Das Ergebnis: „Unter Berücksichtigung der Umstände des Vereins und der Schäden, die durch die unrechtmäßige Offenlegung der Beschäftigtendaten entstanden sind, hat der LfDI MV erstmals eine Verwarnung gegen einen Verein erlassen. Von einem Bußgeldverfahren wurde vorliegend abgesehen. Das Klageverfahren des Vereins gegen den LfDI MV ist noch anhängig.“

    Klartext für Geschäftsführer: Dieser Fall zeigt eine Stufe unterhalb des Bußgelds, die in der öffentlichen Wahrnehmung oft übergangen wird: die förmliche Verwarnung nach Art. 58 Abs. 2 DSGVO (eigene Einordnung, der Bericht nennt an dieser Stelle keine konkrete Absatz-/Buchstaben-Norm für die Verwarnung selbst, nur Art. 32 DS-GVO als verletzte Pflicht). Sie ist kein Bußgeld, aber ein rechtsverbindlicher aufsichtsbehördlicher Verwaltungsakt, der anfechtbar und, wie hier, auch tatsächlich beklagt werden kann. Für Vereine, Stiftungen und andere Non-Profit-Organisationen ist die Botschaft eindeutig: Die DSGVO unterscheidet nicht zwischen gemeinnützig und gewinnorientiert. Ein offen zugänglicher Aktenordner mit Personaldaten ehemaliger Beschäftigter ist ebenso ein Verstoß in einem Sportverein wie in einem Konzern.

    Was der Bericht nicht ausdrücklich sagt, aber naheliegt

    Weder im Krankenhaus-Fall noch im Polizisten-Fall benennt der Bericht die einschlägige DSGVO-Bußgeldnorm ausdrücklich, die folgende Einordnung ist daher eigene rechtliche Kontextualisierung, kein Behördenzitat: Für Verstöße gegen die Sicherheit der Verarbeitung (Art. 32 DSGVO, hier: der ungesicherte Aktenschrank) sowie gegen die Grundsätze der Speicherbegrenzung (Art. 5 Abs. 1 lit. e DSGVO, hier: längst zu vernichtende Akten) ist die einschlägige Bußgeldnorm regelmäßig Art. 83 Abs. 4 lit. a DSGVO (bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes). Für den Polizisten-Fall verweist der Bericht selbst auf die spezielleren, landesrechtlichen Bußgeldtatbestände aus DSG M-V und LKHG M-V mit der genannten Obergrenze von 50.000 Euro, dieser Rahmen gilt speziell für unbefugte Datenabfragen durch Beschäftigte des öffentlichen Dienstes und ist enger gefasst als die allgemeine DSGVO-Bußgeldnorm.

    Was für die Praxis zählt

    Alle drei Fälle, der Aktenschrank auf der Baustelle, der Polizist mit politischer Agenda, der Verein mit der ersten Verwarnung seiner Art, haben eines gemeinsam: Keiner beruht auf einer komplexen technischen Schwachstelle. Der Krankenhaus-Fall ist eine physische Aufbewahrungslücke, der Polizisten-Fall ein Autorisierungs- und Protokollierungsproblem, der Vereins-Fall eine schlicht fehlende Zugriffskontrolle auf Personalunterlagen. Der Bericht selbst zieht daraus keine zusammenfassende Statistik, anders als der Bremer Jahresbericht (Teil 3 dieser Serie) verzichtet der 20. Tätigkeitsbericht MV auf eine Jahresgesamtzahl aller Bußgeldbescheide und -summen. Die wiederkehrende Linie in den drei Einzelfällen ist stattdessen eine praktische: Kooperation mit der Behörde mildert die Sanktion, verhindert sie aber nicht, und wo aufsichtsrechtliche Schritte angefochten werden (wie im Vereinsfall), bleibt der Ausgang offen.


    Dies ist der vierte und vorerst letzte Beitrag der Vertiefungs-Serie zu weiteren Landes-Tätigkeitsberichten 2025/2026 nach dem Muster der bereits erschienenen BlnBDI-Serie (Teil 1: LDI NRW, Personalvermittlung, über 35.000 Euro Bußgeld; Teil 2: SDTB Sachsen, 72 Kameras in einer Flüchtlingsunterkunft ohne Rechtsgrundlage; Teil 3: LfDI Bremen, GPS-Tracking-Serie gegen eine Ex-Partnerin). Damit sind alle vier ursprünglich angedachten Länder (NRW, Sachsen, Bremen, Mecklenburg-Vorpommern) mit je einem belastbaren, primärquellen- geprüften Einzelfall abgedeckt.


    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 20.07.2026.

  • Zehn Bußgelder für einen GPS-Tracker: Wie Bremens Datenschutzbeauftragter eine Überwachungs-Serie gegen eine Ex-Partnerin aufdeckte
    Symbolbild, KI-generiert

    Zehn Bußgelder für einen GPS-Tracker: Wie Bremens Datenschutzbeauftragter eine Überwachungs-Serie gegen eine Ex-Partnerin aufdeckte

    765 Beschwerden gingen 2025 beim Landesbeauftragten für Datenschutz und Informationsfreiheit der Freien Hansestadt Bremen ein, ein Plus von 48 Prozent gegenüber dem Vorjahr. Am 16. März 2026 stellte Dr. Timo Utermark seinen 8. Jahresbericht seit Einführung der Datenschutzgrundverordnung vor und warb dabei vor allem für mehr „Digitale Souveränität“: „Digitale Souveränität gewinnt dafür, personenbezogene Daten effektiv zu schützen, eine immer größere Bedeutung. Die Nutzung von Clouddiensten, bei denen nicht der Verbleib personenbezogener Daten im Anwendungsbereich der Datenschutzgrundverordnung garantiert ist, bleibt ein ernstzunehmendes Problem.“ Der drastischste Einzelfall des Berichts hat mit Cloud-Diensten allerdings nichts zu tun: Ein Mann überwachte seine ehemalige Lebenspartnerin monatelang per heimlich am Auto befestigten GPS-Trackern, die Behörde verhängte gegen ihn deswegen zehn Geldbußen auf einmal.

    Zwei Tracker am Auto der Ex-Partnerin

    Der Bericht beschreibt den Fall so: „Der Landesbeauftragte für Datenschutz und Informationsfreiheit setzte im Berichtsjahr zehn Geldbußen gegen einen Mann fest, der die Bewegungsaktivitäten seiner ehemaligen Lebenspartnerin mittels GPS-Tracker […] überwachte. Dazu befestigte er heimlich zwei GPS-Tracker an ihrem Auto. Immer wenn das Auto fortbewegt wurde, wurden die Bewegungsaktivitäten aufgezeichnet und konnten später in einem Online-Portal angesehen werden.“ Aus den so entstandenen Bewegungsprotokollen ließen sich laut Bericht „die GPS-Koordinaten, das Datum, die Uhrzeit und die Geschwindigkeit einzelner Bewegungen des Wagens nachvollzogen werden und somit auch Rückschlüsse auf das Privatleben der betroffenen ehemaligen Lebensgefährtin gezogen werden“.

    Die Behörde ordnet das rechtlich unmissverständlich ein: „Eine heimliche GPS-Überwachung aufgrund einer privat durchgeführten Beweiserhebung ist grundsätzlich verboten, weil dies einen schwerwiegenden Eingriff in das allgemeine Persönlichkeitsrecht der GPS-überwachten Personen darstellt. Grundrechtsbeeinträchtigende Ermittlungsmaßnahmen dürfen nur unter strengen gesetzlichen Voraussetzungen von den zuständigen Ermittlungsorganen, wie Polizei oder Staatsanwaltschaft, durchgeführt werden.“

    Klartext für Geschäftsführer: Dieser Fall betrifft auf den ersten Blick eine rein private Auseinandersetzung, er hat aber eine unternehmerische Kehrseite, die häufig übersehen wird. Wer als Arbeitgeber Fahrzeugortungssysteme in Firmenwagen einsetzt (Flottenmanagement, Diebstahlschutz, Auslastungsplanung), bewegt sich in derselben Kategorie von Datenverarbeitung, die der Bericht hier beschreibt: Standort-, Bewegungs- und Zeitdaten sind grundsätzlich legitimationsbedürftig. Der entscheidende Unterschied zum geschilderten Fall ist die fehlende Heimlichkeit und die fehlende Rechtsgrundlage beim Täter, als Arbeitgeber braucht man beides: eine dokumentierte, verhältnismäßige Rechtsgrundlage und eine transparente Information der betroffenen Mitarbeitenden, bevor ein Ortungssystem aktiviert wird, nicht erst, wenn eine Beschwerde eingeht.

    Was der Bericht nicht ausdrücklich sagt, aber naheliegt

    Die Pressemeldung und der Berichtsabschnitt selbst verwenden weder den Begriff „Stalking“ noch verweisen sie auf § 238 des Strafgesetzbuchs (Nachstellung), die folgende Einordnung ist daher eigene rechtliche Kontextualisierung, kein Behördenzitat: Heimliches GPS-Tracking einer Ex-Partnerin über einen längeren Zeitraum ist ein klassisches Muster digitaler Nachstellung und kann parallel zu den datenschutzrechtlichen Geldbußen auch strafrechtlich relevant sein. Der Bericht selbst befasst sich ausschließlich mit der datenschutzrechtlichen Seite (Verarbeitung personenbezogener Standort- und Bewegungsdaten ohne Rechtsgrundlage) und trifft keine Aussage dazu, ob es daneben zu einem Strafverfahren kam.

    Der zweite Schwerpunkt: Beschäftigte, die ihre Zugriffsrechte missbrauchen

    Neben dem GPS-Fall widmet der Bericht einen eigenen Abschnitt (Ziffer 3.3) dem, was er als Dauerthema beschreibt: „Auch im Jahr 2025 […] ahndete der Landesbeauftragte für Datenschutz und Informationsfreiheit mehrere Fälle des unberechtigten Zugriffes auf personenbezogene Daten durch Personen, die aufgrund ihrer beruflichen Stellung Zugang zu diesen Daten hatten. Privatmotivierte unbefugte Abfragen durch Beschäftigte öffentlicher Stellen sind in hohem Maße dazu geeignet, das Vertrauen der Allgemeinheit in den Umgang öffentlicher Stellen mit personenbezogenen Daten zu beeinträchtigen und das Ansehen der öffentlichen Verwaltung empfindlich zu schädigen.“

    Konkret verhängte die Behörde drei Geldbußen wegen „des Ausnutzens der Zugriffsberechtigung für den Online-Service zur Einholung von Melderegisterauskünften „OLMERA““. Der gravierendste der drei Fälle: Eine Mitarbeiterin des Gesundheitsamts Bremerhaven „tätigte über einen beträchtlichen Zeitraum von über einem Jahr wiederholt Melderegisterabfragen ohne dienstliche Gründe“, sie fragte Personen aus ihrem familiären und beruflichen Umfeld ab. Der Bericht nennt dabei eine Zahl, die den Umfang des Vorfalls verdeutlicht: „Ferner erhielt sie durch Eingabe der Adresse einer Justizvollzugsanstalt den Zugriff auf personenbezogene Daten von 86 dort gemeldeten Insassen.“ Aufgedeckt wurde der Fall nicht durch die Aufsichtsbehörde selbst, sondern durch den Arbeitgeber: Das Gesundheitsamt Bremerhaven bemerkte den Vorfall und meldete ihn von sich aus.

    Die beiden weiteren Fälle sind kleiner, folgen aber demselben Muster: Eine Mitarbeiterin einer Krankenkasse versuchte erfolglos, die neue Anschrift ihres Ex-Ehemanns und dessen neuer Partnerin abzufragen (die Abfrage scheiterte an einer eingetragenen Auskunftssperre, der Bericht stellt aber klar, dass bereits der Abfrageversuch als Datenverarbeitung zählt). Ein Polizist wiederum führte eine Melderegisterabfrage zu einer Kollegin unter seiner dienstlichen Nutzerkennung durch, aus den Protokolldaten ergab sich dabei jedoch kein „dienstlicher Abfrageanlass“, der einem dienstlichen Sachverhalt zugeordnet werden konnte. Aufgeflogen, weil für die Kollegin selbst eine Auskunftssperre griff und die Ortspolizeibehörde Bremerhaven den Fall meldete.

    Klartext für Techniker: Alle drei Fälle wurden nicht durch die Aufsichtsbehörde selbst aufgespürt, sondern durch interne Meldewege oder durch Schutzmechanismen wie die Auskunftssperre der Betroffenen. Das zeigt eine Lücke, die technisch schließbar ist: Wer Systeme mit Zugriff auf sensible Register betreibt (Melderegister, Patientenverwaltung, Personalakten), sollte nicht auf Zufallsfunde warten, sondern automatisierte Anomalie-Erkennung auf Protokolldaten einsetzen, zum Beispiel Alarmierung bei Abfragen von Namen mit gleichem Nachnamen wie der abfragenden Person, bei Abfragen außerhalb der üblichen Dienstzeit, oder bei ungewöhnlich vielen Abfragen desselben Nutzerkontos in kurzer Zeit. Der 86-Insassen-Fall zeigt zusätzlich: Eine einzelne Adresseingabe kann bei schlecht segmentierten Systemen Zugriff auf einen ganzen Personenkreis freigeben, nicht nur auf eine gesuchte Person, das ist ein Berechtigungs-Design-Fehler, kein reines Verhaltensproblem der Mitarbeiterin.

    Der besonders unangenehme Fall: das eigene Gericht

    Bemerkenswert ist ein weiterer, im Bericht separat unter Ziffer 6.6 geschilderter Vorgang, weil er zeigt, dass auch staatliche Institutionen selbst betroffen sind, und weil er zum Redaktionsschluss noch ungelöst war: „Einer durch das Amtsgericht Bremen gemeldeten Datenschutzverletzung lag der folgende Sachverhalt zugrunde: Mehrere Bedienstete des Gerichtes haben ihre beruflich eingerichteten Zugriffe auf das Melderegister der Stadtgemeinde Bremen sowie der Melderegister weiterer Kommunen im Bundesgebiet genutzt, um Melderegisterabfragen über andere Bedienstete sowie deren Angehörige durchzuführen.“

    Die Aufklärung geriet dabei ins Stocken, und zwar nicht wegen fehlender Beweise, sondern wegen fehlender Kooperation: „Die Sachverhaltsaufklärung gestaltete sich unter anderem als schwierig, weil dem Landesbeauftragten für Datenschutz und Informationsfreiheit die die Zugriffe dokumentierenden Protokolldaten nicht oder nur unzureichend vorgelegt wurden. Zu Redaktionsschluss stand der Abschluss der Sachverhaltsaufklärung noch aus.“ Die Behörde kündigt an, zusätzlich zu prüfen, „ob das Gericht hinreichende technische und organisatorische Maßnahmen zur Verhinderung derartiger Abfragen ergriffen hat.“

    Klartext für Geschäftsführer: Dieser Fall ist noch offen, es gibt keine Anordnung und kein Bußgeld, und der Bericht lässt bewusst offen, wie er ausgeht. Trotzdem ist er lehrreich, gerade weil er zeigt, was schiefläuft, wenn eine Organisation bei einer Datenschutzverletzung selbst Betroffene und Aufsichtsobjekt zugleich ist: Wer die eigenen Protokolldaten nicht vollständig herausgeben kann oder will, verlängert die Prüfung und verschärft am Ende die eigene Position. Vollständige, unveränderliche Zugriffsprotokolle sind kein Kür-Thema für die IT-Abteilung, sondern die Grundlage dafür, im Ernstfall schnell und glaubwürdig aufklären zu können.

    Die rechtliche Einordnung

    Der Bericht selbst zieht für die Melderegister-Fälle eine klare eigene rechtliche Linie, die sich wörtlich zitieren lässt: „Das Abfragen von personenbezogenen Daten in behördlichen Systemen stellt gemäß Artikel 4 Ziffer 2 Datenschutzgrundverordnung (DSGVO) eine Verarbeitung von personenbezogenen Daten dar. Durch dieses Abfragen ohne berechtigten Anlass wird gegen das Erfordernis der Rechtmäßigkeit der Datenverarbeitung gemäß Artikel 5 Absatz 1 Buchstabe a) DSGVO sowie gegen das der Zweckbindung gemäß Artikel 5 Absatz 1 Buchstabe b) DSGVO verstoßen, soweit keine der in Artikel 6 Absatz 1 Unterabsatz 1 DSGVO genannten Bedingungen zum Zeitpunkt der Abfrage erfüllt sind. Insofern sind diese Abfragen von personenbezogen Daten in behördlichen Systemen ohne berechtigten Anlass bußgeldbewehrte Ordnungswidrigkeiten gemäß Artikel 83 Absatz 1, Absatz 2 und Absatz 5 Buchstabe a) DSGVO.“ Bemerkenswert ist zudem, dass die Behörde die abfragenden Beschäftigten selbst als eigenständig Verantwortliche im Sinne von Art. 4 Nr. 7 DSGVO einordnet, nicht nur ihren Arbeitgeber, und sich dabei ausdrücklich auf zwei Gerichtsentscheidungen stützt: Amtsgericht Stuttgart, Urteil vom 22.11.2023, Az. 31 OWi 315 Js 18340/23, Rn. 71 ff., und Oberlandesgericht Stuttgart, Beschluss vom 25.02.2025, Az. 2 ORbs 16 Ss 336/24, Rn. 6 ff.

    Für den GPS-Tracking-Fall nennt der Bericht keine einzelne DSGVO-Norm für die Bußgeldbemessung, sondern argumentiert über den Verarbeitungsbegriff (Erhebung und Speicherung von Standort-, Bewegungs- und Zeitdaten als „legitimationsbedürftige Datenverarbeitung“) und über das allgemeine Persönlichkeitsrecht. Die einschlägige Eingriffsnorm für Bußgelder gegen Privatpersonen ohne unternehmerischen Bezug ist auch hier Art. 83 DSGVO in Verbindung mit Art. 6 Abs. 1 DSGVO als verletzter Erlaubnistatbestand, das ist eigene rechtliche Einordnung, kein wörtliches Berichtszitat.

    Was für die Praxis zählt

    Alle drei geschilderten Fallgruppen, private GPS-Überwachung, Melderegister-Missbrauch durch Behördenmitarbeitende, ungeklärte Protokolldaten-Herausgabe am eigenen Gericht, haben einen gemeinsamen Nenner: Es ging in keinem Fall um eine komplexe technische Sicherheitslücke, sondern um den Zugriff auf ohnehin vorhandene Systeme durch Personen, die formal zugriffsberechtigt waren oder sich unbefugt Zugang zu personenbezogenen Daten verschafften. Der Bericht verzeichnet für 2025 insgesamt 15 Bußgeldbescheide mit 101 Einzel-Geldbußen und einer Gesamtsumme von 75.077 Euro, sechs Bescheide richteten sich gegen natürliche Personen, neun gegen Unternehmen. In 26 weiteren Fällen sah die Behörde von einer Geldbuße ab oder stellte das Verfahren ein. Die Kernaussage von Dr. Timo Utermark bleibt dabei nicht auf Cloud-Souveränität beschränkt, sondern gilt für alle drei Fälle gleichermaßen: Zugriffsrechte sind kein Freibrief, und wer sie überschreitet, muss mit Konsequenzen rechnen, private wie berufliche.


    Dies ist der dritte Beitrag der geplanten Vertiefungs-Serie zu weiteren Landes-Tätigkeitsberichten 2025/2026 nach dem Muster der bereits erschienenen BlnBDI-Serie (Teil 1: LDI NRW, Personalvermittlung, über 35.000 Euro Bußgeld; Teil 2: SDTB Sachsen, 72 Kameras in einer Flüchtlingsunterkunft ohne Rechtsgrundlage). Für Mecklenburg-Vorpommern liegt weiterhin kein vergleichbar konkreter Einzelfall vor.


    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 20.07.2026.

  • 72 Kameras, keine Rechtsgrundlage: Wie Sachsens Datenschutzbeauftragte einen Vermieter zum Abschalten zwang
    Symbolbild, KI-generiert

    72 Kameras, keine Rechtsgrundlage: Wie Sachsens Datenschutzbeauftragte einen Vermieter zum Abschalten zwang

    Über 1.600 Eingaben gingen 2025 bei der Sächsischen Datenschutz- und Transparenzbeauftragten (SDTB) ein, ein Rekordanstieg von 29 Prozent gegenüber dem Vorjahr. Mehr als die Hälfte aller neuen Ordnungswidrigkeitenanzeigen im nichtöffentlichen Bereich betraf ein einzelnes Thema: den Betrieb von Überwachungskameras, in aller Regel private Videoüberwachung. Am 24. März 2026 übergab die Datenschutzbeauftragte Dr. Juliane Hundert ihren Tätigkeitsbericht 2025 an Landtagspräsident Alexander Dierks, und der spektakulärste Einzelfall darin zeigt, wie weit so etwas eskalieren kann, bevor eine Behörde eingreift: In einer Flüchtlingsunterkunft in Sachsen installierte der Eigentümer 72 Kameras im Innen- und Außenbereich.

    Was in der Unterkunft installiert war

    Die Pressemeldung nennt keinen Ort, keinen Namen und keine Bewohnerzahl der Einrichtung, nur die nackte Zahl: 72 Kameras, verteilt auf Innen- und Außenbereich. Zum Vergleich: Übliche Wohnraum-Videoüberwachung kommt meist mit einer einstelligen Kamerazahl aus, gerichtet auf Hauseingang oder Klingelbereich. 72 Kameras deuten auf eine Vollüberwachung des gesamten Gebäudes hin, innen wie außen, bei einer besonders schutzbedürftigen Bewohnergruppe.

    Die SDTB nahm direkten Kontakt zum Eigentümer auf. Ergebnis: Er nahm sämtliche Kameras außer Betrieb, ohne dass es zu einer förmlichen Anordnung kam. Dr. Juliane Hundert beschreibt das Zeitfenster, das dafür blieb, selbst: „Andernfalls hätte sich mich [sic] gezwungen gesehen, eine schriftliche Anordnung mitsamt einer Zwangsgeldandrohung zu erlassen.“ Die Formulierung zeigt, wie knapp die Grenze zur förmlichen Eskalationsstufe war, nicht, dass sie überschritten wurde.

    Klartext für Geschäftsführer: Wer als Vermieter, Betreiber oder Träger einer Einrichtung Videoüberwachung plant, sollte sich an dieser Zahl orientieren: 72 Kameras sind kein Einzelfall von „übervorsichtig“, sondern ein Fall, der eine Aufsichtsbehörde auf den Plan ruft. Die gute Nachricht in diesem konkreten Fall: Wer schnell reagiert, sobald die Behörde anfragt, kann eine förmliche Anordnung mit Zwangsgeld noch vermeiden. Die schlechte Nachricht: Diese Kulanz gilt nur bis zu dem Punkt, an dem die Behörde den Geduldsfaden verliert, und genau dort war der Fall angekommen.

    Warum private Videoüberwachung in Sachsen zum Dauerthema wird

    Der Einzelfall steht nicht isoliert. Die SDTB registrierte 2025 bei nichtöffentlichen Stellen 270 Beschwerden zur Videoüberwachung, 2021 waren es noch 120, 2023 bereits 190. Der Anstieg geht laut Bericht fast ausschließlich auf Privatpersonen zurück, die im Wohn- und Nachbarschaftsumfeld Kameras installieren und dabei häufig öffentliche Gehwege oder fremde Mieterbereiche mitfilmen.

    Ein wiederkehrendes Argument der Kamerabetreiber gegenüber der Behörde: Ihre Überwachung diene der öffentlichen Sicherheit, die Polizei frage schließlich regelmäßig einzelne Sequenzen unter Nennung von Tagebuchnummern an. Dr. Juliane Hundert widerspricht dem in aller Deutlichkeit: „Es ist nicht die Aufgabe privater Akteure, mit ihrer Überwachung des öffentlichen Raums Hilfspolizei zu spielen. Dafür gibt es auch keine rechtliche Grundlage, und es ist nicht Aufgabe der Polizei, die Gefahrenabwehr den Privaten zu überlassen.“

    Die rechtliche Einordnung

    Die Pressemeldung selbst nennt keine DSGVO-Artikelnummern zu diesem Fall, die folgende Einordnung ist eigene rechtliche Zuordnung, kein Behördenzitat. Wer als privater Verantwortlicher Kameras auf fremdem Grund, in Gemeinschaftsflächen oder gar im Innenbereich einer fremden Unterkunft betreibt, braucht dafür eine Rechtsgrundlage nach Art. 6 Abs. 1 DSGVO, in der Praxis meist das berechtigte Interesse nach Art. 6 Abs. 1 lit. f DSGVO, das aber gegen die Interessen der gefilmten Personen abgewogen werden muss. Bei einer Flüchtlingsunterkunft mit Innenraumüberwachung dürfte diese Abwägung praktisch nie zugunsten des Betreibers ausgehen: Die Bewohner haben dort ihren einzigen privaten Rückzugsraum, und eine besonders schutzbedürftige Personengruppe wiegt in der Interessenabwägung schwerer. Die Anordnungsbefugnis, mit der die SDTB in diesem Fall drohte, ergibt sich aus Art. 58 Abs. 2 DSGVO; die angedrohte Durchsetzung per Zwangsgeld ist eine Frage des sächsischen Verwaltungsvollstreckungsrechts, nicht der DSGVO selbst.

    Klartext für Techniker: Bei der Planung einer Videoüberwachungsanlage zählt nicht nur, ob technisch eine Rechtsgrundlage existiert, sondern wie granular sie greift. 72 Kameras pauschal über ein ganzes Gebäude zu verteilen, ist das Gegenteil von Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO): Jede zusätzliche Kamera braucht ihre eigene, dokumentierte Zweckbindung. Eine Kamera am Haupteingang zur Zutrittskontrolle ist etwas anderes als eine Kamera im Fluren-Innenbereich, wo Bewohner sich frei bewegen. Wer eine Anlage dieser Größenordnung plant, sollte vor der Installation eine Datenschutz-Folgenabschätzung durchführen und pro Kamerastandort einzeln begründen können, warum genau dieser Blickwinkel notwendig ist, nicht erst, wenn die Aufsichtsbehörde anruft.

    Der zweite Fall aus demselben Bericht: verkaufte Krankenhaus-Computer

    Ein weiterer im Bericht geschilderter Fall betrifft ein sächsisches Krankenhaus: Ein Mitarbeiter hatte ausgesonderte Computer seines Arbeitgebers erworben und weiterverkauft. Einer der Käufer stellte anschließend eine gelöschte Festplattenpartition wieder her, und fand Röntgenbilder sowie Befunde von Patientinnen und Patienten. Die Pressemeldung nennt zu diesem Fall keine wörtliche Stellungnahme der Behörde, beschreibt den Sachverhalt aber als einen der Fälle, in denen die SDTB 2025 „teils gravierende Datenschutzverstöße“ verfolgen und abstellen konnte. Auch hier hat die Behörde keinen konkreten Bußgeldbetrag veröffentlicht.

    Der Fall zeigt eine andere Fehlerklasse als die Kameraüberwachung: nicht fehlende Rechtsgrundlage für eine Verarbeitung, sondern fehlende technische Löschung vor der Weiterveräußerung von Hardware. Wer IT-Geräte ausmustert, muss sicherstellen, dass Datenträger nicht bloß formatiert, sondern nach anerkannten Standards überschrieben oder physisch zerstört werden, eine Festplattenpartition „wiederherzustellen“ ist technisch trivial, wenn vorher nur gelöscht statt sicher überschrieben wurde.

    Was für die Praxis zählt

    Zwei Fälle, zwei völlig unterschiedliche Fehlerquellen, ein gemeinsamer Nenner: In beiden Fällen lag der Fehler nicht in der grundsätzlichen Entscheidung (Sicherheit erhöhen wollen, Altgeräte verkaufen wollen), sondern in der fehlenden datenschutzrechtlichen Prüfung vor der Umsetzung. Die SDTB registrierte 2025 im nichtöffentlichen Bereich 114 neue Ordnungswidrigkeitenanzeigen, ein Plus von 37 Prozent gegenüber dem Vorjahr, mehr als die Hälfte davon zu Videoüberwachung. Der Trend zeigt in eine Richtung: mehr Beschwerden, mehr Verfahren, und eine Behörde, die nach eigener Aussage bereits „an ihren Belastungsgrenzen“ arbeitet, mit 41 Mitarbeitenden für ganz Sachsen.


    Dies ist der zweite Beitrag der geplanten Vertiefungs-Serie zu weiteren Landes-Tätigkeitsberichten 2025/2026 nach dem Muster der bereits erschienenen BlnBDI-Serie (Teil 1: LDI NRW, Personalvermittlung, über 35.000 Euro Bußgeld). Für Bremen und Mecklenburg-Vorpommern liegt weiterhin kein vergleichbar konkreter Einzelfall vor.


    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 20.07.2026.

  • 47 Sicherheitslücken im Überblick: unsere komplette CVE-Bestandsaufnahme nach Risiko sortiert
    Symbolbild, KI-generiert

    47 Sicherheitslücken im Überblick: unsere komplette CVE-Bestandsaufnahme nach Risiko sortiert

    Seit dem 10. Juli 2026 haben wir in mehreren Artikeln insgesamt 47 Sicherheitslücken (CVEs) dokumentiert und gegen Primärquellen wie die National Vulnerability Database (NVD), Hersteller-Advisories und den CISA-KEV-Katalog geprüft. Jede einzelne davon hatte bereits ihren eigenen Artikel oder Absatz, mit Einordnung für Geschäftsführung und Technik. Was bisher fehlte: der Überblick über alle 47 an einem Ort, sortiert nicht nach Veröffentlichungsdatum, sondern nach dem, was tatsächlich zählt, dem Risiko.

    Dieser Artikel ist genau das: eine Bestandsaufnahme, keine Neuauflage. Wo eine Lücke bereits ausführlich behandelt wurde, verweisen wir kurz und verlinken auf den Originalartikel, dort steht die vollständige technische Tiefe. Ganz unten finden Sie außerdem den Link zu unserer durchsuchbaren, filterbaren CVE-Datenbank mit allen Details zu jedem einzelnen Eintrag.

    Die drei aktiv ausgenutzten Lücken zuerst

    Von 47 dokumentierten CVEs stehen drei nachweislich im Katalog aktiv ausgenutzter Schwachstellen (CISA-KEV). Bei diesen dreien ist die Frage nicht „ob“, sondern „wann“ ein Angreifer es versucht, wenn die betroffene Software im Einsatz ist.

    • CVE-2026-15409 & CVE-2026-15410, SonicWall SMA1000 Series (Remote-Access-Gateway). SSRF (CVSS 10.0, unauthentifiziert) plus Command-Injection (CVSS 7.2, post-authentifiziert), in Kombination eine vollständige Fernübernahme des Geräts ohne Zugangsdaten. Fix: 12.4.3-03453 / 12.5.0-02835. Ausführlich mit Angriffskette und CVSS-Vektor erklärt in unserem Einzelartikel zu SonicWall SMA1000.
    • CVE-2026-41940, cPanel & WHM (Hosting-Panel). CRLF-Injection im Login-Prozess, CVSS 9.8, erlaubt Admin-Zugriff auf den ganzen Hosting-Server ohne Zugangsdaten. Fix: aktuellster cPanel-TSR. Details zur Angriffsmethode im Abschnitt „cPanel/WHM“ unseres Artikels zur Webserver-CVE-Flut.

    GF-Klartext: Setzen Sie eines dieser Systeme ein, ist das keine Lücke für die nächste Wartungsrunde, sondern für heute. Beide stehen im CISA-KEV-Katalog, das heißt: reale, dokumentierte Angriffe, keine theoretische Bewertung. Prüfen Sie beim jeweiligen Hoster beziehungsweise IT-Dienstleister aktiv nach, ob der Patch bereits eingespielt ist, verlassen Sie sich nicht auf automatische Updates allein.

    Kritisch (CVSS 9.0 und höher)

    Neun der 47 Lücken erreichen einen kritischen CVSS-Wert. Zwei davon zählen bereits zu den aktiv ausgenutzten oben, die übrigen sieben sind nach heutigem Kenntnisstand nicht als aktiv ausgenutzt bekannt, aber mit voller oder nahezu voller Punktzahl bewertet.

    Netzwerk-Infrastruktur (Firewall, WLAN-Controller, Self-Hosting)

    • CVE-2026-50746, Ubiquiti UniFi Connect Application, CVSS 10.0. Fehlerhafte Zugriffskontrolle erlaubt unauthentifizierte Befehlseinschleusung über das Netzwerk. Fix: 3.4.20.
    • CVE-2026-57155, OPNsense (Community & Business), CVSS 9.9. Ein stark eingeschränktes Firewall-Alias-Konto kann über eine unsichere GeoIP-Datenbank-Verarbeitung volle Root-Kontrolle erlangen. Fix: 26.1.11 / 26.4.1.
    • CVE-2026-34038, Coolify (Self-Hosting-Plattform), CVSS 9.9. Command Injection über Deployment-Parameter, volle Codeausführung samt Auslesen von Zugangsdaten aus Logs. Fix: 4.0.0-beta.469.

    Alle drei ausführlich mit Angriffsweg und Härtungsempfehlung in unserem Roundup zu Firewall, WLAN-Controller und Self-Hosting-Plattform.

    WordPress-Plugins und -Themes

    • CVE-2026-57811, Realtyna Organic IDX, CVSS 10.0. Unauthentifizierte Remote Code Inclusion, kein Account nötig. Fix: 5.3.0.
    • CVE-2026-57724, Kirki (Theme-Baukasten), CVSS 9.8. PHP Object Injection durch unsichere Deserialisierung. Fix: 6.0.13.
    • CVE-2026-57744, RT-Theme 18 | Extensions, CVSS 9.8. Gleiches Muster wie Kirki, Fixed-Version bislang nicht dokumentiert.

    Details und Rechtestufen-Einordnung im KW30-Roundup WordPress-Plugins und -Themes.

    Webserver/Middleware

    • CVE-2026-42530, NGINX Open Source/Plus, ngx_http_v3_module (HTTP/3), CVSS 9.2 (v4), Use-after-free. Reicht von Absturz des Worker-Prozesses bis zu theoretischer Codeausführung. Fix: 1.31.2+. Eingeordnet im Abschnitt „NGINX“ unseres CVE-Flut-Artikels.

    Techniker-Klartext: Bei allen neun kritischen Lücken gilt dieselbe Faustregel: sofort patchen, nicht bis zum nächsten Wartungsfenster warten. Bei RT-Theme 18 Extensions und Coolify (nur unterhalb der genannten Fixed-Version) gibt es entweder noch keine dokumentierte Fixed-Version oder die Lücke sitzt in einer selten aktualisierten Komponente, hier hilft ein Blick in den jeweils verlinkten Artikel für die konkrete Übergangs-Härtung.

    Hoch (CVSS 7.0 bis 8.9)

    17 der 47 Lücken liegen im hohen Bereich, kein Grund zur Panik, aber ebenfalls kein Fall für „irgendwann“. Eine der 17, die SonicWall-Command-Injection (CVE-2026-15410), steht bereits oben bei den aktiv ausgenutzten; die übrigen 16 verteilen sich wie folgt:

    WordPress-Plugins (7 Funde, alle aus dem KW30-Roundup)

    CVE-IDProduktCVSSKurz-EinordnungFix
    CVE-2026-13353WP Ultimate CSV Importer8.8Subscriber kann eigenen PHP-Code über eval() ausführen (fehlender Capability-Check)nicht dokumentiert
    CVE-2026-14158Widget Logic Visual8.8identisches Muster wie CSV Importernicht dokumentiert
    CVE-2026-14495DoLogin Security8.8schwacher Zufallsgenerator bei passwortlosen Login-Links, Account Takeovernicht dokumentiert
    CVE-2026-11855Simple Membership8.8fehlende Stripe-Webhook-Signaturprüfung, XSS im Admin-Kontext4.7.5
    CVE-2026-27060ARMember Premium (aus KW29)8.8PHP Object Injection durch Deserialisierungnicht dokumentiert
    CVE-2026-6101AMP for WP7.5unsichere ZIP-Extraktion, beliebiger Datei-Schreibzugriffnicht dokumentiert
    CVE-2026-15288SureForms7.5fehlende Preisvalidierung bei Stripe-Zahlungsformularen2.2.2

    WordPress-Themes, unauthentifiziertes XSS (4 Funde, alle aus KW29)

    • CVE-2026-27402 (Kids Life | Children School), CVE-2025-69156 (Kids Zone), CVE-2025-69155 (Fitness Zone), alle drei von Designthemes, CVSS je 7.1, identischer Angriffsvektor: ein Opfer muss einen präparierten Link anklicken.
    • CVE-2025-69152 (Artale | Wedding Photography, ThemeGoods), CVSS 7.1, gleiches Muster.

    Webserver/Middleware (5 Funde, alle aus dem CVE-Flut-Artikel)

    • CVE-2026-50645, Apache CXF, CVSS 7.5, Denial of Service durch unbegrenzte Attachment-Header.
    • CVE-2026-33846, CVE-2026-33845, CVE-2026-42009, CVE-2026-42010, GnuTLS, schweregrad hoch (kein offizieller CVSS-Wert zum Artikelstand), Heap-Lücken und eine Authentifizierungsumgehung bei RSA-PSK in der DTLS-Verarbeitung. Fix jeweils: 3.8.13.

    GF-Klartext: In dieser Gruppe stecken viele Angriffe, die entweder eine Nutzerinteraktion (Klick auf einen Link) oder ein bereits vorhandenes, wenn auch niedrig privilegiertes Konto voraussetzen. Das senkt das Risiko gegenüber der kritischen Gruppe, hebt es aber nicht auf, gerade Redaktionsteams mit mehreren Konten und öffentlich erreichbare Kontaktformulare sind ein realistisches Einfallstor.

    Mittel (CVSS 4.0 bis 6.9)

    Acht Lücken liegen im mittleren Bereich, überwiegend Konfigurations- und Zugriffskontroll-Probleme statt direkter Serverübernahme.

    • CVE-2026-14449, u5CMS, CVSS 6.4, reflektiertes XSS über den Parameter „thanks“. Fix: 12.8.9. (KW29)
    • CVE-2026-34478, Apache log4j, Rfc5424Layout, CVSS 6.9, Log-Injection durch stillschweigend umbenanntes Escaping-Attribut. Fix: 2.25.4.
    • CVE-2026-55956, CVE-2026-43512, CVE-2026-43515, Apache Tomcat, jeweils ohne offiziellen CVSS-Wert, Umgehung von Zugriffsbeschränkungen beziehungsweise fehlerhafte Digest-Authentifizierung. Fix: 11.0.22/11.0.23.
    • CVE-2026-42011, CVE-2026-42012, CVE-2026-42013, GnuTLS, Schwächen bei der Zertifikatsvalidierung (Name-Constraints, CN-Fallback). Fix: 3.8.13.

    (log4j und Tomcat aus dem CVE-Flut-Artikel, GnuTLS ebenda.)

    Niedrig und offen: 13 Funde ohne akuten Handlungsdruck

    Die restlichen 13 Einträge sind entweder als niedrig eingestuft oder ihr CVSS-Wert stand zum jeweiligen Artikelstand noch aus (Kennzeichnung „offen“ in unserer Datenbank, kein Sicherheitsurteil, sondern fehlende NVD-Anreicherung).

    CVE-IDProduktSchweregradKurz-Einordnung
    CVE-2026-55276Apache Tomcatniedrigreines Logging-Problem, Laufzeit-Rechte unberührt
    CVE-2026-55955Apache Tomcat (EncryptInterceptor)niedrigfehlender Replay-Schutz
    CVE-2026-12988WP 2FAoffenAccount Takeover trotz 2FA durch fehlende E-Mail-Verifikation, Fix 3.1.1.2
    CVE-2026-42055NGINX (Proxy-v2/gRPC)offenPufferüberlauf, Fix 1.31.2
    CVE-2026-9256NGINX (rewrite-Modul)offenPufferüberlauf, Fix 1.31.1
    CVE-2026-42945, CVE-2026-42946NGINXoffenweitere Puffer-/HTTP-3-Probleme, Fix 1.31.0+
    CVE-2026-40460NGINX (HTTP/3)offenAdressspoofing, Fix 1.31.0+
    CVE-2026-48142NGINX (charset-Modul)offenBuffer-Overread, Fix 1.31.2+
    CVE-2026-34480Apache log4j (XmlLayout)offenstiller Log-Verlust, Fix 2.25.4
    CVE-2026-34479Apache log4j (1.2-api-Brücke)offenanaloges Konfigurationsproblem, Fix 2.25.4
    CVE-2026-12746Dancer2::Plugin::Auth::OAuth::Provideroffenfehlender CSRF-Schutz (state-Parameter), Fix 0.23
    CVE-2026-12194phpIPAMoffenauthentifizierte Local File Inclusion über die API, API standardmäßig deaktiviert

    Alle Details, inklusive der jeweiligen Primärquelle, im CVE-Flut-Artikel (NGINX, log4j, Tomcat, Dancer2, phpIPAM) beziehungsweise im KW30-Roundup (WP 2FA).

    Techniker-Klartext: „Offen“ heißt nicht „harmlos“, sondern „NVD hat noch keinen eigenen CVSS-Wert vergeben“. Bei log4j und NGINX empfiehlt sich trotzdem das reguläre Update im nächsten Wartungsfenster, weil beide Komponenten oft zentral im Stack sitzen und ein späterer, höher bewerteter Fund in derselben Versionsreihe keine Seltenheit ist.

    Fazit: Priorität vor Vollständigkeit

    Bei 47 offenen Punkten hilft keine Liste, die alles gleich behandelt. Unsere Reihenfolge für die nächsten Wochen:

    1. Die drei aktiv ausgenutzten Lücken (SonicWall SMA1000, cPanel/WHM) sofort prüfen, wenn im Einsatz.
    1. Die neun kritischen Lücken im laufenden Wartungsfenster patchen, priorisiert nach Erreichbarkeit von außen (Firewall/Netzwerk vor internem Tool).
    2. Die 17 hohen Lücken im Rahmen des nächsten regulären Updates, mit besonderem Blick auf Plugins mit Zahlungs- oder Kontofunktion.
    3. Mittel, niedrig und offen: in die reguläre Update-Routine einplanen, keine Sonderaktion nötig.

    Ein einzelner Blogartikel ersetzt keinen laufenden Scan der eigenen Systeme. Wer wissen will, ob eine der 47 Lücken die eigene Infrastruktur tatsächlich betrifft, findet alle Einträge mit vollständigen Metadaten, Filterfunktion nach Hersteller, Plattform und Schweregrad in unserer durchsuchbaren CVE-Datenbank.

    Quellen

  • DSA-Plattformpflichten: Von der Verbraucherklage in Bamberg bis zur VLOP-Kontrolle in Luxemburg
    Symbolbild, KI-generiert

    DSA-Plattformpflichten: Von der Verbraucherklage in Bamberg bis zur VLOP-Kontrolle in Luxemburg

    Der Digital Services Act (DSA) gilt seit Februar 2024 vollständig, aber ein Gesetzestext allein setzt sich nicht selbst durch. Wer die neuen Plattformpflichten tatsächlich durchsetzt, zeigt sich erst in den Gerichtssälen: mal ein bayerisches Landgericht, das YouTube die Werbekennzeichnung vorschreibt, mal das Gericht der Europäischen Union (EuG) in Luxemburg, das darüber urteilt, ob Amazon oder Zalando zu Recht als sehr große Online-Plattform gilt. Sechs Entscheidungen aus den vergangenen zwölf Monaten zeichnen zusammen ein Bild davon, wie eng das Netz der DSA-Aufsicht inzwischen tatsächlich ist, und wo es überraschend Löcher hat.

    Der Ausgangspunkt: eine Verbraucherklage in Bamberg

    Den Anfang macht ein Urteil, das zeigt, dass DSA-Durchsetzung nicht nur Behördensache ist. Am 18. März 2026 entschied das OLG Bamberg (3 UKl 5/25 e) auf Klage der Verbraucherzentrale Bayern: Ein Verbraucherschutzverband ist klagebefugt gegen DSA-Verstöße von TikTok. Konkret ging es um zwei Pflichten aus Art. 16, 27 Abs. 3 und 38 DSA: die Option, personalisierte Feeds zu deaktivieren, und das Melde-Verfahren für rechtswidrige Inhalte müssen unmittelbar und leicht auffindbar sein. Wer als sehr große Plattform diese Funktionen versteckt, etwa in einem Menü, in dem Nutzer sie nicht erwarten, verstößt gegen den DSA, und ein Verbraucherverband kann das gerichtlich durchsetzen, ganz ohne dass die EU-Kommission oder eine nationale Aufsichtsbehörde einschreiten muss. Das OLG hat die Revision zum BGH zugelassen; die Frage der Verbandsklagebefugnis bei DSA-Verstößen ist damit noch nicht letztinstanzlich geklärt.

    Werbekennzeichnung darf nicht verschwinden

    Nur eine Woche zuvor, am 11. März 2026, hatte das LG Bamberg (1 HK O 19/25) einen eng verwandten DSA-Fall entschieden, dort auf Klage der Verbraucherzentrale Baden-Württemberg: YouTube muss durchsetzen, dass Werbekennzeichnungen bei Influencer-Videos während der gesamten Videolänge oder jedenfalls während des überwiegenden Teils klar, eindeutig, in Echtzeit und optisch hervorgehoben angezeigt werden. Eine nur kurze, unauffällige Kennzeichnung zu Beginn des Videos genügt den Anforderungen aus Art. 26 Abs. 2 DSA in Verbindung mit § 6 Abs. 1 Nr. 2 DDG nicht. Das Gericht macht damit deutlich, dass Werbekennzeichnung kein einmaliger Haken zu Sendungsbeginn ist, sondern eine Dauerpflicht über die komplette Laufzeit des Inhalts. Das Urteil ist noch nicht rechtskräftig; die Plattform kann Berufung einlegen.

    Klartext für Geschäftsführer: Das Urteil bindet die Plattform, nicht den Buchenden, das ist die gesicherte Aussage daraus. Annahme: Wer Influencer-Kooperationen bucht oder selbst Video-Content mit Produktplatzierung veröffentlicht, sollte sich trotzdem nicht auf ein kurzes „Anzeige“-Intro verlassen, weil die Plattform, auf der der Inhalt läuft, die durchgängige Sichtbarkeit ohnehin durchsetzen muss.

    Wer ist überhaupt VLOP? Amazon vor dem EuG

    Die eigentliche Architektur der DSA-Aufsicht hängt an einem einzigen Begriff: der sehr großen Online-Plattform (VLOP), die besonders strengen Zusatzpflichten unterliegt. Am 19. November 2025 bestätigte das EuG (T-367/23, ECLI:EU:T:2025:1038) im Verfahren Amazon EU / Kommission: Die Einstufung von Amazon Store als VLOP ist rechtmäßig. Der Nutzerschwellenwert von 45 Millionen durchschnittlichen monatlichen aktiven Nutzern in der EU, ab dem diese Einstufung greift, ist verhältnismäßig. Auch ein Marktplatz kann systemische Risiken erzeugen, argumentierte das Gericht, nicht nur soziale Netzwerke oder Suchmaschinen. Amazon war damit mit dem Versuch gescheitert, sich aus dem Kreis der besonders beaufsichtigten Plattformen herauszuklagen. Gegen ein EuG-Urteil ist ein auf Rechtsfragen beschränktes Rechtsmittel zum EuGH möglich.

    EuG bestätigt: „aktiver Nutzer“ zählt jeden, der Inhalten ausgesetzt ist

    Rund zweieinhalb Monate zuvor, am 3. September 2025, hatte das EuG bereits im Fall Zalando / Kommission (T-348/23, ECLI:EU:T:2025:821) den entscheidenden Streitpunkt geklärt, wer als „aktiver Nutzer“ im Sinne von DSA Art. 3, 24 und 33 überhaupt zählt. Zalando wollte nur zahlende Käufer mitzählen lassen. Das Gericht widersprach: Der Begriff erfasst alle Personen, die den verbreiteten Informationen ausgesetzt sind, unabhängig davon, ob eine Transaktion stattfindet, auch Nutzer, die nur Drittverkäufer-Informationen im Partnerprogramm sehen. Das EuG wies Zalandos Klage ab. Rechtskräftig ist das nicht: Zalando hat am 13. November 2025 Rechtsmittel zum EuGH eingelegt (C-724/25 P), das Verfahren ist anhängig.

    Klartext für Techniker: Wer eine eigene Plattform mit nutzergenerierten oder Drittanbieter-Inhalten betreibt und die Schwelle von 45 Millionen durchschnittlichen monatlichen aktiven Nutzern im Blick behalten muss, sollte beim Zählen nicht nur Käufer oder registrierte Accounts erfassen. Nach dieser Linie zählt jede Person, die Inhalte tatsächlich angezeigt bekommt, selbst wenn sie nie etwas kauft oder sich einloggt.

    Wenn sogar die Kommission patzt: Meta und TikTok gewinnen formal, zahlen aber trotzdem

    Der vielleicht überraschendste Teil dieses Clusters betrifft nicht die Plattformen, sondern die EU-Kommission selbst. Am 10. September 2025 entschied das EuG gleich zweimal identisch: Im Verfahren Meta Platforms Ireland / Kommission (T-55/24, ECLI:EU:T:2025:842) und im Parallelverfahren TikTok Technology / Kommission (T-58/24, ECLI:EU:T:2025:843) wurden die Aufsichtsgebührenentscheidungen der Kommission für 2023 aufgehoben. Der Grund war rein formal, aber folgenreich: Die Methodik zur Berechnung der durchschnittlichen monatlichen aktiven Nutzer, auf deren Basis die Kommission gemäß Art. 43 DSA die Aufsichtsgebühr für Facebook, Instagram und TikTok festgelegt hatte, hätte in einem delegierten Rechtsakt statt in einem Durchführungsrechtsakt geregelt werden müssen. Die Kommission hatte also die falsche Rechtsaktform gewählt, und das genügte dem Gericht, um die Gebührenbescheide aufzuheben. Ein endgültiger Sieg ist das für Meta und TikTok damit nicht, gleich in zweierlei Hinsicht. Erstens: Weil es sich um einen reinen Formfehler handelt, muss die Kommission die Methodik zur Berechnung der durchschnittlichen monatlichen aktiven Nutzer nun in einem delegierten Rechtsakt festlegen und auf dieser Grundlage neue Durchführungsbeschlüsse erlassen. Zweitens, und praktisch entscheidender: Meta und TikTok zahlen trotzdem, jedenfalls vorerst. Das Gericht hielt die Wirkungen der aufgehobenen Beschlüsse vorläufig aufrecht, für höchstens zwölf Monate ab Rechtskraft der Urteile, weil es an der Zahlungspflicht für 2023 selbst keinen Fehler fand.

    Die Urteile im Überblick

    DatumGerichtAz.Kernaussage
    03.09.2025EuGT-348/23Zalando zu Recht als VLOP eingestuft, „aktiver Nutzer“ unabhängig von Transaktion
    10.09.2025EuGT-55/24Aufsichtsgebühr Meta 2023 wegen falscher Rechtsaktform aufgehoben, Wirkung bis zu 12 Monate vorläufig fortgeltend
    10.09.2025EuGT-58/24Aufsichtsgebühr TikTok 2023 wegen falscher Rechtsaktform aufgehoben, Wirkung bis zu 12 Monate vorläufig fortgeltend
    19.11.2025EuGT-367/23Amazon-VLOP-Einstufung rechtmäßig, 45-Mio-Schwelle verhältnismäßig
    11.03.2026LG Bamberg1 HK O 19/25Werbekennzeichnung bei Influencer-Videos muss durchgängig sichtbar sein
    18.03.2026OLG Bamberg3 UKl 5/25 eVerbraucherschutzverband klagebefugt gegen DSA-Verstöße

    Was für die Geschäftsführung zählt: Der DSA wird auf zwei Ebenen gleichzeitig durchgesetzt, national durch Verbraucherschutzverbände vor Zivilgerichten und EU-weit durch das EuG bei Fragen der VLOP-Einstufung. Wer Werbekooperationen managt oder Inhalte über Drittanbieter, Partnerprogramme oder algorithmische Feeds ausspielt, sollte beide Ebenen im Blick behalten. Auch die Kommission selbst muss sich an strenge Formvorgaben halten, DSA-Aufsicht ist keine Einbahnstraße.

    Was für die Technik zählt: Das EuG hat den Begriff des aktiven Nutzers erstinstanzlich weit ausgelegt, er zählt jede Person, die Inhalten ausgesetzt ist, nicht nur zahlende oder eingeloggte Nutzer. Die letztinstanzliche Klärung durch den EuGH steht noch aus. Wer die Schwelle von 45 Millionen durchschnittlichen monatlichen aktiven Nutzern beobachtet, braucht schon jetzt ein Zählverfahren, das dieser weiten Definition standhält. Bei Werbekennzeichnungen reicht ein Intro-Hinweis technisch nicht, die Kennzeichnung muss über die gesamte Laufzeit eines Inhalts eingeblendet bleiben.

    Diese Serie wird fortgesetzt: der fünfte und letzte Teil bringt den Auskunftsanspruch nach Art. 15 DSGVO, der bereits produktionsreif in der Warteschlange liegt.


    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 20.07.2026.

  • Über 35.000 Euro Bußgeld, weil „gelöscht“ nicht gelöscht hieß: der NRW-Fall zur Löschpflicht
    Symbolbild, KI-generiert

    Über 35.000 Euro Bußgeld, weil „gelöscht“ nicht gelöscht hieß: der NRW-Fall zur Löschpflicht

    Ein Kunde bittet um Löschung seiner Daten, bekommt eine Bestätigungsmail und landet trotzdem weiter im Newsletter-Verteiler. Genau das ist einer Düsseldorfer Personalvermittlung passiert, nur dass es diesmal keine Ausrede für ein technisches Versehen gab: Die Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen (LDI NRW), Bettina Gayk, hat das Unternehmen im September 2025 mit einem Bußgeld von über 35.000 Euro belegt. Die Pressemeldung stammt aus dem Berichtsjahr 2025, das der 31. Tätigkeitsbericht abdeckt, und zeigt, wie schnell aus einer schleppenden Auskunfts- und Löschpraxis ein fünfstelliger Betrag wird.

    Was die Personalvermittlung falsch gemacht hat

    Arbeitssuchende, die bei dem Unternehmen registriert waren, verlangten Auskunft darüber, welche Daten über sie gespeichert sind, und forderten teils zusätzlich die Löschung dieser Daten. Beides blieb liegen. Die LDI NRW schaltete sich ein und schrieb das Unternehmen selbst an, um Auskunft zu verlangen und auf die gesetzliche Kooperationspflicht gegenüber der Aufsichtsbehörde hinzuweisen. Auch diese Schreiben blieben unbeantwortet.

    Besonders dreist wurde es an einem anderen Punkt: Mehreren Betroffenen teilte das Unternehmen mit, ihre Daten seien gelöscht, verschickte anschließend aber weiterhin Newsletter-Werbung an genau diese Personen. Wer als Betroffener eine Löschbestätigung erhält und sich anschließend erneut im Postfach beworben findet, verliert zu Recht das Vertrauen darin, dass „gelöscht“ bei diesem Unternehmen tatsächlich gelöscht bedeutet.

    Klartext für Geschäftsführer: Es gab hier keine Grauzone, über die man streiten könnte. Die Behörde hat konkret angefragt, das Unternehmen hat geschwiegen. Wer auf ein Auskunftsersuchen oder ein Behördenschreiben gar nicht reagiert, verschärft die Lage gegenüber einer verspäteten, aber inhaltlich korrekten Antwort erheblich. Eigene Einordnung: Art. 31 DSGVO verlangt die Zusammenarbeit mit der Aufsichtsbehörde, Schweigen ist deshalb nichts Neutrales, sondern fällt auf das Unternehmen zurück. Die Pressemeldung der LDI NRW stellt dazu allerdings keinen eigenen, gesondert benannten Verstoß fest.

    Warum die Löschbestätigung selbst zum Problem wurde

    Rechtlich betrachtet liegen in diesem Fall zwei getrennte Verstöße übereinander. Erstens die unbeantworteten Auskunftsersuchen: Art. 15 DSGVO gibt Betroffenen den Auskunftsanspruch; Art. 12 Abs. 3 DSGVO verpflichtet Verantwortliche, darauf unverzüglich, spätestens aber binnen eines Monats zu reagieren, eine Frist, die durch bloßes Nichtreagieren gerissen wird. Zweitens, und das wiegt in diesem Fall schwerer, das Löschersuchen nach Art. 17 DSGVO: Wer eine Löschung bestätigt, ohne sie tatsächlich durchzuführen, begeht keinen bloßen Prozessfehler, sondern verschafft dem Betroffenen eine falsche Tatsachenannahme über den Stand seiner eigenen Daten. Genau dieser Punkt, die Diskrepanz zwischen Bestätigung und Realität, dürfte für die Höhe des Bußgelds mitentscheidend gewesen sein, auch wenn die Pressemeldung der LDI NRW keine Berechnungsformel offenlegt. Allgemein richtet sich die Zumessung nach den Kriterien des Art. 83 Abs. 2 DSGVO, darunter Art, Schwere und Dauer des Verstoßes sowie der Grad der Zusammenarbeit mit der Aufsichtsbehörde.

    Klartext für Techniker: Eine Löschbestätigung, die verschickt wird, bevor die Löschung in allen Systemen tatsächlich abgeschlossen ist, ist technisch gesehen eine falsche Aussage gegenüber dem Betroffenen. Das betrifft vor allem verteilte Systeme: Ein CRM kann eine Person löschen, während dieselbe Person parallel noch in einer Newsletter-Liste, einem Marketing-Tool oder einem Backup-Export weiterlebt. Ein Löschprozess ist erst dann abgeschlossen, wenn er alle Systeme erfasst, in denen personenbezogene Daten tatsächlich verarbeitet werden, nicht nur das System, in dem die Löschanfrage ursprünglich einging.

    Was die Behörde dazu sagt

    Bettina Gayk kommentierte den Fall deutlich: „Ignoranz beim Datenschutz zahlt sich nicht aus.“ Sie betonte zugleich: „Solch dreistes Verhalten nimmt leider zu.“ und: „Datenschutz darf nicht von der Willkür Einzelner abhängig sein.“

    Der Fall steht damit auch für einen allgemeinen Trend. Aus dem am 17. April 2026 vorgelegten

    1. Tätigkeitsbericht der LDI NRW für das Jahr 2025 geht hervor: Die Zahl der Eingaben bei

    der Behörde stieg von 12.490 auf 18.062 und damit um fast 45 Prozent, die darin enthaltenen Datenschutzbeschwerden von 7.539 auf 12.592 und damit um mehr als 67 Prozent. Die Gesamtsumme der 2025 verhängten Bußgelder näherte sich laut Bericht der halben Million Euro.

    Was für die Praxis zählt

    Der Fall ist kein Sonderfall aus einer Nischenbranche. Jedes Unternehmen, das mit Bewerberdaten, Kundendaten oder Interessentendaten arbeitet und dabei einen Newsletter-Verteiler pflegt, steht vor demselben strukturellen Risiko: Löschung in einem System, Fortbestand in einem anderen. Wer ein Löschersuchen bestätigt, sollte deshalb erst prüfen, ob die Löschung in sämtlichen angeschlossenen Systemen durchgeführt wurde, bevor die Bestätigung verschickt wird, nicht danach. Und wer eine Anfrage der eigenen Datenschutzaufsicht erhält, sollte sie unabhängig von der eigenen Rechtsauffassung beantworten. Das Schweigen gegenüber der Behörde dürfte mitentscheidend dafür gewesen sein, dass aus einer schwierigen Situation eine teure wurde.

    Dies ist der erste Beitrag der geplanten Vertiefungs-Serie zu weiteren Landes-Tätigkeitsberichten 2025/2026 nach dem Muster der bereits erschienenen BlnBDI-Serie. Für Sachsen, Bremen und Mecklenburg-Vorpommern liegt bislang kein vergleichbar konkreter Einzelfall vor; die jeweiligen Tätigkeitsberichte müssten dafür noch eigenständig recherchiert werden.


    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 20.07.2026.

  • Auskunftsanspruch Art. 15 DSGVO: was BFH, BGH und EuGH für Unternehmen bedeuten
    Symbolbild, KI-generiert

    Auskunftsanspruch Art. 15 DSGVO: was BFH, BGH und EuGH für Unternehmen bedeuten

    Jeder Kunde, jeder Bewerber, jeder ehemalige Mitarbeiter kann jederzeit fragen: Welche Daten haben Sie über mich gespeichert? Art. 15 DSGVO gibt dieser Frage ein Recht, und Unternehmen als Verantwortliche müssen antworten, grundsätzlich kostenlos, innerhalb eines Monats, grundsätzlich ohne Begründung des Anfragenden verlangen zu können. Was in der Praxis schwerfällt, ist nicht die Pflicht selbst, sondern ihr Umfang: Reicht eine Zusammenfassung, oder müssen ganze Dokumente heraus? Zählen interne Vermerke dazu? Und gibt es überhaupt eine Grenze, ab der ein Antrag als missbräuchlich abgelehnt werden darf? Zwischen 2021 und 2026 haben BGH, EuGH und in einer bemerkenswert dichten Serie auch der Bundesfinanzhof genau diese Fragen beantwortet, zwölf Entscheidungen, die zusammen ein klares Bild ergeben.

    Die BFH-Serie: sieben Urteile in sechs Monaten

    Dass ausgerechnet der Bundesfinanzhof zur zentralen Instanz für Art. 15 DSGVO wurde, überrascht auf den ersten Blick. Der Hintergrund: Steuerpflichtige verlangen von Finanzbehörden zunehmend Auskunft nach Art. 15 DSGVO, oft als Ersatz oder Ergänzung zur klassischen Akteneinsicht. Zwischen Januar und Juli 2025 musste der BFH deshalb siebenmal klären, wie weit dieser Anspruch reicht. Die steuerverfahrensrechtlichen Besonderheiten dieser Fälle, etwa das Verhältnis zur Akteneinsicht nach AO/FGO oder das Steuergeheimnis nach § 30 AO, lassen sich nicht 1:1 auf private Unternehmen übertragen. Die dahinterliegenden DSGVO-Auslegungsgrundsätze, die diese Urteile zu Umfang, internen Vermerken und Aufwand als Ablehnungsgrund entwickeln, gelten dagegen für jeden Verantwortlichen gleichermaßen, denn Art. 15 DSGVO selbst unterscheidet nicht zwischen Behörde und Betrieb.

    Den Auftakt macht das Urteil vom 14. Januar 2025 (IX R 25/22): Unverhältnismäßiger Aufwand allein rechtfertigt keine Auskunftsverweigerung, ein Ersuchen ist nicht bereits deshalb exzessiv, weil es sachlich oder zeitlich nicht eingegrenzt ist. Am 11. März 2025 folgen zwei weitere Entscheidungen am selben Tag: Der Anspruch besteht unabhängig von Art und Form der Aktenführung (IX R 23/22) und umfasst auch interne Vermerke, Aktennotizen und interne Kommunikation, soweit Personenbezug vorliegt (IX R 24/22). Ein Verweis auf „das würde zu viel Arbeit machen“ trägt also nicht, und „das steht doch nur in unseren internen Notizen“ schützt ebenfalls nicht vor der Herausgabepflicht.

    Am 8. April 2025 zieht der BFH gleich dreifach nach. Betroffenenschreiben an eine oberste Landesbehörde sind vollständig personenbezogene Daten, die rechtliche Analyse der Behörde selbst dagegen nicht, wohl aber die darin verarbeiteten personenbezogenen Angaben (IX R 22/22). Wer erstmals im laufenden Klageverfahren von einem Akteneinsichtsantrag auf einen datenschutzrechtlichen Auskunftsanspruch umschwenkt, vollzieht eine Klageänderung, die einen vorherigen außergerichtlichen Antrag voraussetzt (IX R 8/24). Und: Art. 15 DSGVO vermittelt keinen allgemeinen Akteneinsichtsanspruch, gegen die Ablehnung eines Akteneinsichtsantrags ist der behördliche Einspruch der richtige Weg, nicht die DSGVO-Auskunftsklage (IX R 27/22).

    Klartext für Geschäftsführer: Diese drei Urteile ziehen eine wichtige Trennlinie. Ein Kunde, der Ihre komplette Kundenakte sehen will, hat dafür keinen Anspruch aus Art. 15 DSGVO, sondern höchstens einen vertraglichen oder sonstigen Einsichtsanspruch, wenn überhaupt einen. Art. 15 DSGVO verschafft eine verständliche Auskunft über die Daten, nicht automatisch den kompletten Aktenordner.

    Den Schlusspunkt dieser Halbjahres-Serie setzt das Urteil vom 15. Juli 2025 (IX R 25/24): Ein Steuerpflichtiger hat regelmäßig keinen Anspruch, den Inhalt einer anonymen Anzeige beim Finanzamt offengelegt zu bekommen. Das Auskunftsersuchen darf nicht allein deshalb abgelehnt werden, weil es einen datenschutzfremden Zweck verfolgt, aber der Auskunftsanspruch ist nach § 32c Abs. 1 Nr. 1 i.V.m. § 32b Abs. 1 AO ausgeschlossen, wenn die Abwägung im Einzelfall ergibt, dass das Geheimhaltungsinteresse überwiegt: Sowohl die Identität des Anzeigeerstatters als auch der Inhalt seiner Anzeige unterliegen dem Geheimnisschutz nach § 30 AO. Übertragen auf die Unternehmenspraxis: Wer intern einen anonymen Hinweisgeber-Fall hat, kann sich für den Schutz der Identität auf eine vergleichbare Kollisionsnorm oder auf die Rechte Dritter nach Art. 15 Abs. 4 DSGVO berufen, aber nicht pauschal auf „das interessiert Sie nichts“.

    Die BGH/EuGH-Linie: was eine Kopie tatsächlich enthalten muss

    Parallel zur BFH-Serie hat die zivilrechtliche Rechtsprechung eine zweite, ebenso wichtige Frage geklärt: Was genau schuldet der Verantwortliche, wenn er „eine Kopie“ der Daten nach Art. 15 Abs. 3 DSGVO herausgibt?

    Den Ausgangspunkt setzt der BGH bereits am 15. Juni 2021 (VI ZR 576/19): Der Auskunftsanspruch folgt einem weiten Datenbegriff und erfasst auch interne Vermerke und Kommunikation mit Personenbezug, reine Rechtsbewertungen der verantwortlichen Stelle selbst sind aber ausgenommen, dieselbe Linie, die der BFH vier Jahre später für Behörden bestätigt. Der EuGH konkretisiert am 4. Mai 2023 im CRIF-Urteil (C-487/21), was „Kopie“ bedeutet: Sie muss eine originalgetreue und verständliche Reproduktion aller betroffenen Daten ermöglichen, was im Einzelfall auch ganze Dokumente oder Datenbankauszüge erfordern kann, wenn dies für die wirksame Rechtsausübung unerlässlich ist.

    Am 27. September 2023 zieht der BGH in einem Versicherungsfall eine Grenze (IV ZR 177/22): Die Begründungsschreiben zu Prämienanpassungen samt Anlagen sind als solche keine personenbezogenen Daten des Versicherungsnehmers, Art. 15 Abs. 1 und 3 DSGVO gibt daher keinen Anspruch auf ihre Abschrift. Ein Auskunftsanspruch kann sich in solchen Fällen allenfalls aus § 242 BGB ergeben, und auch nur unter engen Voraussetzungen. Am 16. April 2024 präzisiert der BGH diese Linie weiter (VI ZR 223/21): Der Anspruch betrifft eine Kopie der Daten, nicht pauschal eine Dokumentkopie, ganze Dokumente sind nur herauszugeben, wenn dies für eine verständliche Auskunft unerlässlich ist. Zugleich stellt der BGH klar, dass Schreiben, die die betroffene Person selbst an den Verantwortlichen gerichtet hat, in ihrer Gesamtheit personenbezogene Daten sind und daher als vollständige Kopie herausverlangt werden können.

    Klartext für Techniker: Wer ein Auskunftsersuchen bearbeitet, muss nicht reflexartig den kompletten Datensatz oder alle Rohdokumente exportieren. Maßgeblich ist, ob eine verständliche, originalgetreue Auskunft auch ohne die vollständigen Dokumente möglich ist. Ist sie das, reicht eine strukturierte Zusammenstellung der personenbezogenen Daten. Ist sie es nicht, etwa weil der Kontext ohne das ganze Dokument nicht verständlich wird, müssen ganze Dokumente heraus.

    Die Grenze: wenn der Antrag selbst missbräuchlich wird

    Den bislang jüngsten und für die Praxis vielleicht wichtigsten Punkt setzt der EuGH am 19. März 2026 im Fall Brillen Rottler (C-526/24): Ein erster Auskunftsantrag kann ausnahmsweise exzessiv im Sinne von Art. 12 Abs. 5 DSGVO sein, wenn er missbräuchlich zur Erlangung eines DSGVO-fremden Vorteils gestellt wird, etwa um sich im Vorfeld eines Rechtsstreits einen prozessualen Vorteil zu verschaffen, ohne dass es dem Antragsteller tatsächlich um den Datenschutz geht. Gleichzeitig stellt der EuGH klar: Art. 82 Abs. 1 DSGVO gewährt Schadensersatz für Verletzungen des Auskunftsrechts auch dann, wenn keine konkrete unrechtmäßige Datenverarbeitung nachgewiesen wird, sofern ein konkreter Schaden belegt ist. Die Ablehnungsmöglichkeit bei Missbrauch ist also die Ausnahme, keine allgemeine Abwehrstrategie, und wer zu Unrecht ablehnt, haftet trotzdem.

    Die zwölf Urteile im Überblick

    DatumGerichtAz.Kernaussage
    14.01.2025BFHIX R 25/22Unverhältnismäßiger Aufwand rechtfertigt keine Auskunftsverweigerung, kein pauschales Exzessiv
    11.03.2025BFHIX R 23/22Anspruch auch gegenüber oberster Landesbehörde, unabhängig von Aktenführung
    11.03.2025BFHIX R 24/22Umfasst interne Vermerke, Notizen, interne Kommunikation mit Personenbezug
    08.04.2025BFHIX R 22/22Betroffenenschreiben vollständig erfasst, Behörden-Rechtsanalyse selbst nicht
    08.04.2025BFHIX R 8/24Wechsel Akteneinsicht → Auskunftsanspruch im Klageverfahren = Klageänderung
    08.04.2025BFHIX R 27/22Kein allgemeiner Akteneinsichtsanspruch aus Art. 15 DSGVO
    15.07.2025BFHIX R 25/24Kein Anspruch auf Identität eines anonymen Anzeigenden, Steuergeheimnis § 30 AO schützt
    15.06.2021BGHVI ZR 576/19Weiter Datenbegriff, interne Vermerke erfasst, reine Rechtsbewertungen nicht
    04.05.2023EuGHC-487/21 (CRIF)Kopie muss originalgetreue, verständliche Reproduktion sein
    27.09.2023BGHIV ZR 177/22Begründungsschreiben zu Prämienanpassungen sind keine personenbezogenen Daten, kein Anspruch aus Art. 15 DSGVO
    16.04.2024BGHVI ZR 223/21Anspruch betrifft Kopie der Daten, nicht pauschal Dokumentkopie
    19.03.2026EuGHC-526/24 (Brillen Rottler)Antrag kann bei Missbrauch exzessiv sein, Schadensersatz auch ohne bewiesene Datenverarbeitung

    Was für die Geschäftsführung zählt: Ein Auskunftsersuchen nach Art. 15 DSGVO ist kein Freibrief für den kompletten Aktenschrank, aber auch keine Formalie, die man mit einer kurzen Standardantwort abtun kann. Interne Vermerke, Notizen und Kommunikation mit Personenbezug gehören dazu, reine interne Rechtsbewertungen nicht. Der Aufwand allein ist kein Ablehnungsgrund. Nur wenn ein Antrag erkennbar missbraucht wird, um sich einen DSGVO-fremden Vorteil zu verschaffen, etwa in einem laufenden Rechtsstreit, kommt eine Ablehnung als exzessiv in Betracht, und selbst dann bleibt das Haftungsrisiko bei einer falschen Einschätzung hoch.

    Was für die Technik zählt: Ein sauberer Auskunftsprozess muss in der Lage sein, personenbezogene Daten aus internen Notizen, E-Mails und Vermerken systematisch zu identifizieren, nicht nur aus den offensichtlichen Stammdatenfeldern. Die Antwort muss originalgetreu und verständlich sein, das kann eine strukturierte Zusammenstellung sein, muss aber im Einzelfall ganze Dokumente umfassen, wenn ohne sie die Auskunft nicht nachvollziehbar wäre. Ein Prozess, der pauschal „wir geben nur eine Zusammenfassung raus“ oder pauschal „wir geben alle Dokumente raus“ vorsieht, hält keiner der zwölf Entscheidungen in voller Breite stand, hier zählt die Einzelfallprüfung.

    Diese Serie wird fortgesetzt: der verbleibende Cluster (DSA-Plattformpflichten) aus dem laufenden Content-Plan ist als Backlog dokumentiert und wird produziert, sobald der Cliffhanger-Slot bestätigt weiterläuft.


    Dieser Beitrag ist eine an die Allgemeinheit gerichtete Darstellung von Rechtsfragen und keine Rechtsdienstleistung (§ 2 Abs. 1 und Abs. 3 Nr. 5 RDG). Er prüft keinen Einzelfall und ersetzt keine anwaltliche Beratung. Maßgeblich ist allein der Gesetzestext in seiner geltenden Fassung; Stand: 20.07.2026.

WhatsApp