1. Angriffsfläche WordPress: nach dem Kern jetzt die Plug-ins

Seit Freitag, 7. August 2026 · zuletzt aktualisiert Dienstag, 18. August 2026 · Score 84

Elf Tage nach der Kern-Schwachstelle XSS2Shell (CVE-2026-64638) trifft es die Erweiterungsebene: Wordfence meldet in Forminator Forms bis einschließlich Version 1.56.1 einen unauthentifizierten Datei-Upload und in den Royal Elementor Addons eine SSRF- (CVE-2026-17123, CVSS 8,8) sowie eine gespeicherte XSS-Lücke (CVE-2026-19217, CVSS 6,4). Beide Plug-ins kommen auf über 600.000 aktive Installationen.

Letzte Entwicklung: Für die Royal Elementor Addons steht Version 1.7.1066 bereit. Der Forminator-Fall ist der schwerwiegendere, weil er keinerlei Anmeldung voraussetzt und die Blockliste gefährlicher Dateiendungen über MIME-Typ-Tricks umgangen werden kann.

2. SAP Commerce Cloud: von der Patchday-Lücke zur beobachteten Ausnutzung

Seit Dienstag, 11. August 2026 · zuletzt aktualisiert Montag, 17. August 2026 · Score 80

Die am SAP-Patchday geschlossene Schwachstelle CVE-2026-58231 erlaubt unauthentifizierte Codeausführung in SAP Commerce Cloud; Angreifer missbrauchen dafür einen Standard-Authentifizierungs-Client. Beim Erscheinen wurde sie mit CVSS 10 bewertet und als vollständige Kompromittierbarkeit beschrieben.

Letzte Entwicklung: Über das Wochenende haben Sicherheitsforscher erste Angriffsversuche im Netz beobachtet (Meldung von DefusedCyber). Die Lücke wechselt damit vom Zustand „gepatcht, aber ungenutzt“ in den Zustand „aktiv ausgenutzt“ — mit entsprechender Priorität für alle Betreiber, die noch nicht aktualisiert haben.

1.1 Formular-Plug-ins sind Datenspeicher, nicht nur Versandwerkzeuge

18.08.2026 · heise: WordPress-Plug-in Forminator Forms — Kritische Lücke erlaubt Codeschmuggel

Zusammenfassung: Die heute bekannt gewordene Schwachstelle betrifft mit Forminator Forms ausgerechnet das Werkzeug, mit dem Kontakt-, Bewerbungs-, Umfrage- und Anmeldeformulare gebaut werden. Solche Plug-ins speichern die Einsendungen standardmäßig in der WordPress-Datenbank, zusätzlich zum E-Mail-Versand — Namen, Anschriften, Telefonnummern, Freitextfelder und bei aktiviertem Upload auch Dateianhänge. Damit liegt in vielen Unternehmens- und Vereinswebsites ein über Jahre gewachsener Bestand personenbezogener Daten, der weder im Verzeichnis der Verarbeitungstätigkeiten auftaucht noch einer Löschfrist unterliegt.

Hintergrund & Einordnung: Die datenschutzrechtliche Bewertung eines solchen Vorfalls hängt entscheidend davon ab, was gespeichert war. Eine kompromittierte Website ohne personenbezogene Daten ist ein IT-Sicherheitsproblem; eine kompromittierte Website mit fünf Jahren Bewerbungsunterlagen ist eine meldepflichtige Datenschutzverletzung nach Art. 33 DSGVO, bei Bewerbungsdaten regelmäßig mit hohem Risiko und damit auch mit Benachrichtigungspflicht nach Art. 34. Erschwerend kommt hinzu, dass Datei-Uploads in vielen Konfigurationen unter einer erratbaren URL im Upload-Verzeichnis landen — dann braucht es nicht einmal einen Angriff, um an die Inhalte zu kommen. Für die Bewertung nach Art. 32 ist außerdem relevant, dass es sich um eine unauthentifizierte Lücke handelt: Die Zugriffsschwelle liegt bei null, was die Wahrscheinlichkeit einer Ausnutzung in die Höhe treibt, sobald ein Exploit kursiert.

Praxisfolgen / Handlungsempfehlung: Nehmen Sie Formular-Plug-ins ins Verarbeitungsverzeichnis auf und definieren Sie dort Löschfristen — für Kontaktanfragen sind wenige Monate üblich, für Bewerbungen die AGG-Fristen zuzüglich Puffer. Prüfen Sie, ob die Speicherung in der Datenbank überhaupt gebraucht wird; viele Plug-ins lassen sich auf reinen E-Mail-Versand umstellen, was das Risiko strukturell beseitigt. Sichern Sie Upload-Verzeichnisse gegen direkten Abruf und gegen PHP-Ausführung. Und halten Sie fest, wer im Ernstfall die Meldung nach Art. 33 verantwortet — bei extern betreuten Websites ist das erfahrungsgemäß die ungeklärteste Frage.

1.2 Bundespolizeigesetz: Echtzeit-Videoanalyse liegt beim Bundesrat

18.08.2026 · datenschutzticker.de · Deutscher Bundestag: Textarchiv zur Sitzung

Zusammenfassung: Statusmeldung zu einem Vorgang, der im Sommerloch untergegangen ist: Der Bundestag hat am 10. Juli 2026 einen Änderungsantrag der Koalition zum Gesetz zur Modernisierung des Bundespolizeigesetzes beschlossen. Er erlaubt der Bundespolizei die Echtzeitanalyse von Videoaufnahmen an öffentlichen Orten wie Bahnhöfen, einschließlich automatisierter Erkennung von Bewegungs- und Objektmustern, biometrischer Detektion in Echtzeit und KI-gestützter Verhaltensbewertung, jeweils mit Abgleich gegen große Datenbestände. Der Bundesrat hat noch nicht zugestimmt; eine vergleichbare Regelung war dort 2021 gescheitert.

Hintergrund & Einordnung: Die Einordnung ist hier wichtiger als die Neuigkeit — der Beschluss ist gut fünf Wochen alt und wird in diesem Briefing als Verfahrensstand geführt, nicht als aktuelle Meldung. Praktisch bedeutsam ist die Kombination dreier Elemente, die einzeln jeweils weniger eingriffsintensiv wären: verdachtsunabhängige Erfassung, biometrische Auswertung in Echtzeit und automatisierte Verhaltensbewertung. Die datenschutzrechtliche Kritik richtet sich entsprechend auf Datenminimierung, Zweckbindung und die fehlende Benachrichtigung Betroffener — an einem Bahnhof lässt sich Betroffenheit praktisch nicht individuell mitteilen. Hinzu kommt die Verzahnung mit der KI-Verordnung: Biometrische Echtzeit-Fernidentifizierung im öffentlichen Raum ist dort grundsätzlich verboten und nur unter engen Voraussetzungen zulässig; wie weit die nationale Ermächtigung reicht, wird sich an dieser Schnittstelle entscheiden.

Praxisfolgen / Handlungsempfehlung: Für Betreiber von Bahnhöfen, Flughäfen, Stadien und großen Veranstaltungsorten lohnt es, die eigene Videoinfrastruktur jetzt zu inventarisieren: Wo endet die eigene Verantwortlichkeit, wo beginnt die behördliche, und welche Schnittstellen zur Bundespolizei bestehen technisch bereits? Datenschutzbeauftragte sollten das Gesetzgebungsverfahren bis zur Bundesratsbefassung verfolgen und die Frage klären, ob eigene Anlagen für die beschriebenen Analysen überhaupt technisch geeignet sind — eine spätere Nachrüstung wäre ein eigener, DSFA-pflichtiger Vorgang.

2.1 Minimum Viable Zero Trust: Zuschnitt statt Großprojekt

17.08.2026 · heise: Sicherheitskonzept Minimum Viable Zero Trust in 90 Tagen einführen

Zusammenfassung: Der Beitrag beschreibt ein wiederkehrendes Muster: Zero-Trust-Vorhaben werden als Großprojekt begonnen und als Großprojekt beendet, ohne dass sich das Risiko messbar verändert hätte. Als Ursachen benennt er einen zu breit gewählten Geltungsbereich, Abhängigkeiten zwischen Teams und Systemen und die Erwartung, Zero Trust ließe sich wie ein Produkt einführen. Der Gegenentwurf — Minimum Viable Zero Trust — beschränkt den Geltungsbereich bewusst so, dass innerhalb von 90 Tagen eine messbare Risikoreduktion entsteht, und setzt dort an, wo das Schadenspotenzial am größten ist: bei Adminpfaden und privilegierten Identitäten.

Hintergrund & Einordnung: Die beschriebene Ausgangslage trifft den deutschsprachigen Mittelstand präzise: historisch gewachsene Identitätslandschaften mit Active Directory plus mehreren Identity Providern und Cloud-Tenants, Schatten-IT durch SaaS, uneinheitliche Adminpfade, Legacy-Authentifizierung und begrenzte Engineering-Kapazität. Genau diese Gemengelage macht den Big-Bang-Ansatz aussichtslos und den Zuschnitt auf privilegierte Zugänge attraktiv. Der Ansatz passt zudem auffällig gut zu den Vorfällen der vergangenen Tage: Die Kompromittierungen bei RingCentral und Questel liefen über telefonisch erschlichene Zugänge zu Cloud-Tenants, nicht über technische Lücken — also über exakt den Pfad, den ein MVZT-Zuschnitt zuerst absichert.

Praxisfolgen / Handlungsempfehlung: Beginnen Sie mit einer Bestandsaufnahme der privilegierten Identitäten über alle Tenants hinweg — erfahrungsgemäß ist allein diese Liste länger als erwartet. Setzen Sie für diese Konten phishing-resistente Authentisierung durch, trennen Sie administrative von persönlichen Konten und führen Sie einen kontrollierten Zugangspfad ein, statt Administration aus dem Arbeitsalltag heraus zuzulassen. Definieren Sie vorab, woran Sie den Erfolg nach 90 Tagen messen — etwa Anteil privilegierter Konten mit FIDO2, Zahl der Wege zu einem Domänenadministrator, Zeit bis zum Entzug eines Zugangs.

2.2 PostgreSQL: Updates gegen Codeausführung und ein nahendes Support-Ende

18.08.2026 · heise: Schadcode-Sicherheitslücken bedrohen PostgreSQL · PostgreSQL-Projekt: Release-Ankündigung

Zusammenfassung: Das PostgreSQL-Projekt hat abgesicherte Ausgaben veröffentlicht: 14.24, 15.19, 16.15, 17.11 und 18.6. Über mehrere Schwachstellen können Angreifer Schadcode auf Systeme bringen und ausführen; in den meisten Fällen ist damit die vollständige Kontrolle über die Instanz möglich. Zugleich weisen die Entwickler darauf hin, dass der Support für PostgreSQL 14 am 12. November 2026 ausläuft — ab diesem Zeitpunkt bleiben neue Lücken in dieser Version offen.

Hintergrund & Einordnung: Datenbankserver stehen selten im Internet, was die unmittelbare Dringlichkeit dämpft — sie sind aber das Ziel, auf das jede erfolgreiche Kompromittierung einer Webanwendung hinausläuft. Genau deshalb ist die Kombination mit den heutigen WordPress-Lücken bemerkenswert: Wer über ein Plug-in Code auf dem Webserver ausführt, hat in aller Regel bereits die Datenbankzugangsdaten aus der Konfigurationsdatei und braucht die Datenbanklücke gar nicht mehr. Die eigentliche Botschaft des Tages liegt deshalb im Lebenszyklus: PostgreSQL 14 ist in vielen Umgebungen die Version, die vor Jahren mit einer Anwendung mitgeliefert wurde und seither unbeachtet läuft. Drei Monate vor dem Support-Ende ist der Zeitpunkt, an dem ein Major-Upgrade noch planbar ist statt eskaliert.

Praxisfolgen / Handlungsempfehlung: Spielen Sie die Minor-Updates zeitnah ein — sie sind bei PostgreSQL erfahrungsgemäß unkritisch und erfordern nur einen Neustart. Erheben Sie parallel, welche Instanzen auf Version 14 laufen, und ordnen Sie jeder eine Anwendung samt Verantwortlichem zu; Instanzen ohne benannten Verantwortlichen sind die eigentlichen Kandidaten für ein böses Erwachen im November. Prüfen Sie zusätzlich, ob Datenbankzugangsdaten in Webanwendungs-Konfigurationen mit minimalen Rechten hinterlegt sind — ein Anwendungskonto braucht selten Superuser-Rechte.

3.1 WordPress-Erweiterungen: unauthentifizierter Datei-Upload in Forminator Forms

18.08.2026 · Wordfence: Forminator Forms · Wordfence: Royal Elementor Addons SSRF

Zusammenfassung: In Forminator Forms bis einschließlich Version 1.56.1 können nicht authentifizierte Akteure beliebige Dateien hochladen. Ursache ist eine unzureichende Prüfung des Dateityps in einem Eingabefeld; die vorhandene Blockliste gefährlicher Erweiterungen lässt sich durch geschickte Nutzung von MIME-Typen umgehen. Das Plug-in kommt auf rund 600.000 aktive Installationen. In den Royal Elementor Addons — ebenfalls über 600.000 Installationen — fand Wordfence zwei weitere Schwachstellen: eine Server-Side Request Forgery über die Webhook-URL-Einstellung des Formular-Builder-Widgets, ausnutzbar ab Contributor-Rechten (CVE-2026-17123, CVSS 8,8), und eine gespeicherte Cross-Site-Scripting-Lücke mit denselben Voraussetzungen (CVE-2026-19217, CVSS 6,4). Version 1.7.1066 enthält beide nicht mehr.

Hintergrund & Einordnung: Der unauthentifizierte Datei-Upload gehört zu den wenigen Schwachstellenklassen, bei denen zwischen Bekanntwerden und Massenausnutzung typischerweise Stunden bis wenige Tage liegen — die Ausnutzung ist trivial automatisierbar, das Ziel über die WordPress-REST-API leicht identifizierbar, und der Ertrag ist eine vollständige Serverübernahme. Die Umgehung der Blockliste über MIME-Typen ist dabei der klassische Konstruktionsfehler: Eine Blockliste gefährlicher Endungen setzt voraus, dass man alle gefährlichen Endungen kennt und dass die Endung überhaupt das entscheidende Kriterium ist. Bei den Royal Elementor Addons ist die Einstiegshürde höher, aber nicht hoch: Contributor-Rechte vergeben viele Redaktionen großzügig, und eine SSRF über eine frei konfigurierbare Webhook-URL öffnet den Weg zu internen Diensten und Cloud-Metadatendiensten, die von außen nicht erreichbar wären.

Praxisfolgen / Handlungsempfehlung: Beide Plug-ins auf allen betreuten Instanzen aktualisieren und die tatsächlich laufende Version auslesen, statt der Update-Automatik zu vertrauen. Anschließend das Upload-Verzeichnis auf PHP-Dateien und ungewöhnliche Zeitstempel prüfen und die Ausführung von PHP dort serverseitig unterbinden — das ist unabhängig von dieser Lücke die wirksamste Einzelmaßnahme. Überprüfen Sie zudem die Rollenvergabe: Contributor-Konten von externen Autoren, Praktikanten oder alten Projekten sind ein unterschätzter Ausgangspunkt. Für Agenturen mit vielen Kundeninstanzen lohnt ein zentraler Überblick über Plug-in-Versionen, weil die Zeitfenster bei dieser Schwachstellenklasse kurz sind.

3.2 SAP Commerce Cloud: erste Angriffsversuche beobachtet

17.08.2026 · heise: Angriffe auf SAP-Commerce-Cloud-Lücke beobachtet · heise: Patchday-Meldung vom 11.08.

Zusammenfassung: Verlaufshinweis mit materiell neuem Sachverhalt: Die am SAP-Patchday vom 11. August geschlossene Schwachstelle in SAP Commerce Cloud wird inzwischen angegriffen. Sicherheitsforscher haben über das Wochenende erste Angriffsversuche im Netz beobachtet; die Meldung stammt von DefusedCyber. Angreifer können ohne vorherige Anmeldung einen Standard-Authentifizierungs-Client missbrauchen und darüber Schadcode einschleusen und ausführen.

Hintergrund & Einordnung: Der Abstand zwischen Patch und beobachteter Ausnutzung beträgt in diesem Fall rund fünf Tage — ein Wert, der zur Beobachtung aus dem CrowdStrike-Lagebericht dieses Sommers passt, wonach ein erheblicher Teil der Exploits binnen 48 Stunden nach Veröffentlichung verfügbar ist. Für Shop-Betreiber ist der Zeitdruck damit real: Die Angreifer wissen aus dem Patch, wo sie suchen müssen, und die betroffenen Systeme sind naturgemäß aus dem Internet erreichbar. Erschwerend kommt hinzu, dass ein Standard-Authentifizierungs-Client missbraucht wird — also eine Komponente, die in Standardinstallationen vorhanden ist und nicht erst durch eine ungewöhnliche Konfiguration entsteht.

Praxisfolgen / Handlungsempfehlung: Patchstand aller Commerce-Cloud-Instanzen verifizieren und, falls noch nicht geschehen, sofort aktualisieren. Werten Sie Zugriffslogs rückwirkend ab dem 11. August auf Anfragen an die betroffenen Endpunkte aus; bei Auffälligkeiten gehören Anwendungskonten, hinterlegte Zahlungsdienstleister-Zugänge und Exportfunktionen auf die Prüfliste. Weil in Shop-Systemen Kundendaten und Bestellhistorien liegen, ist parallel die datenschutzrechtliche Bewertung anzustoßen — die 72-Stunden-Frist des Art. 33 DSGVO läuft ab Kenntnis, nicht ab Bestätigung.

3.3 Wireshark 4.6.8: 28 DoS-Lücken ohne CVE-Zuordnung

17.08.2026 · heise: Zahlreiche Crash-Lücken in Wireshark geschlossen · Wireshark: Release Notes 4.6.8

Zusammenfassung: Die Entwickler des Netzwerkanalysewerkzeugs Wireshark haben in Version 4.6.8 insgesamt 28 Schwachstellen geschlossen, über die sich Dienste zum Absturz bringen lassen. Betroffen sind unter anderem Protokoll-Dissektoren. Konkrete CVE-Nummern und Schweregrade sind in den Release Notes nicht eingetragen. Hinweise auf eine Ausnutzung liegen nach Angaben des Projekts nicht vor.

Hintergrund & Einordnung: Die Meldung ist für sich genommen unspektakulär — Denial-of-Service in einem Analysewerkzeug klingt nach geringem Risiko. Der Kontext verschiebt das Bild: Wireshark und der zugehörige Kommandozeilenkollege tshark laufen häufig auf Analyse- und Sensorsystemen, die per Definition fremden, potenziell böswillig konstruierten Netzwerkverkehr verarbeiten — teils automatisiert in Auswertungspipelines. Ein gezielt präpariertes Paket, das den Dissektor zum Absturz bringt, ist damit ein Werkzeug, um die Beobachtung während eines Angriffs auszuschalten. Die fehlende CVE-Zuordnung erschwert zudem die Priorisierung in Umgebungen, die ihr Schwachstellenmanagement an CVE-Feeds ausrichten: Ohne Kennung taucht das Update in vielen Scannern schlicht nicht auf.

Praxisfolgen / Handlungsempfehlung: Aktualisieren Sie zuerst dort, wo Wireshark oder tshark automatisiert Fremdverkehr verarbeiten — Sensoren, Analyse-Appliances, Auswertungsskripte in der Forensik. Auf Analystenarbeitsplätzen gilt die Grundregel, Mitschnitte nicht mit erhöhten Rechten zu öffnen und die Aufzeichnung von der Auswertung zu trennen. Wer sein Patch-Management an CVE-Feeds koppelt, sollte für Werkzeuge mit eigener Release-Note-Praxis einen zusätzlichen Prüfweg vorsehen.

4.1 OLG Köln: Aufkauf einer verwechslungsfähigen Konkurrenzdomain als gezielte Behinderung

Oberlandesgericht Köln · 22.07.2026 · 6 W 8/26 (rechtskräftig) · Volltext · CSA-Aufbereitung ur-604

Sachverhalt: Zwei Kanzleien lagen bereits im Streit, der auch öffentlich über soziale Netzwerke ausgetragen wurde. Im Februar 2025 erwarb die größere Kanzlei von einem Dritten mehrere Domains, darunter eine seit 2009 bestehende Domain, die mit der Unternehmensbezeichnung der kleineren Kanzlei verwechslungsfähig ist, und richtete eine Weiterleitung auf die eigene Website ein. Ende Mai 2025 bat die kleinere Kanzlei sachlich darum, die Weiterleitung abzustellen — es koste sie Mandate. Ein Partner der Gegenseite antwortete, sollte die Nachricht als Kaufanfrage zu verstehen sein, könne man darüber sprechen. Es folgten eine Abmahnung (Gegenstandswert 30.000 Euro), eine negative Feststellungsklage, eine parallele Leistungsklage und schließlich die übereinstimmende Erledigungserklärung. Das LG Köln legte die Kosten der Klägerin auf.

Entscheidung: Das OLG Köln wies die sofortige Beschwerde gegen die Kostenentscheidung zurück. Die negative Feststellungsklage war unbegründet, weil dem Beklagten ein Unterlassungsanspruch aus §§ 8 Abs. 1, Abs. 3 Nr. 1, 3, 4 Nr. 4 UWG zustand. Nach den amtlichen Leitsätzen liegt bei einem einheitlichen Unterlassungsbegehren, das auf Behinderung und Irreführung gestützt wird, nur ein Streitgegenstand vor; und es kann eine unlautere Behinderung darstellen, wenn eine mit einer Unternehmensbezeichnung verwechslungsfähige Domain allein mit dem Ziel erworben wird, sie dem Unternehmer zum Kauf anzubieten.

Begründungs-Kernpunkte: Der Senat knüpft an die BGH-Linie an, wonach eine gezielte Behinderung auch jenseits des kennzeichenrechtlichen Schutzes in der Registrierung und Nutzung einer Domain liegen kann, wenn damit unangemessen Kunden eines Mitbewerbers abgefangen werden (wetteronline.de). Das zulässige Interesse, Kunden auf die eigene Seite zu leiten, tritt zurück, wenn sich der Handelnde unangemessen zwischen Mitbewerber und Kunden drängt, ohne deutlich zu machen, dass man nicht auf der gesuchten Seite gelandet ist. Tragend war die Gesamtwürdigung dreier Indizien: die vorausgegangenen Auseinandersetzungen, die bekannte etablierte Nutzung der entsprechenden .com-Domain durch die Gegenseite und vor allem das Verkaufsangebot, das auf eine sachliche Bitte hin abgegeben wurde und der eigenen Darstellung einer „sachlich nachvollziehbaren Domainstrategie“ widersprach. Belegt war zudem, dass Mandanten die Domain in nicht unerheblichem Umfang irrig zuordneten; automatisierte Fehlermeldungen an die Absender entlasteten nicht, sondern bewiesen gerade die Fehlzuordnung. Einen Rechtsmissbrauch nach § 8c UWG verneinte der Senat: Die Abmahnung war berechtigt, und der Gegenstandswert von 30.000 Euro ist angesichts der Bedeutung anwaltlicher Sichtbarkeit im Internet nicht übersetzt.

Praxisfolgen: Vor dem Erwerb einer gebrauchten Domain prüfen, ob sie einer fremden Unternehmensbezeichnung ähnelt und ob diese im Markt etabliert ist — Kenntnis wird zugerechnet. Wer eine solche Domain hält und weiterleitet, sollte auf der Zielseite deutlich machen, dass der Nutzer nicht beim gesuchten Anbieter ist; das Fehlen dieses Hinweises ist ein tragender Abwägungsfaktor. In der Korrespondenz mit Mitbewerbern über Domains sollte jedes Verkaufsangebot unterbleiben, solange die eigene Berechtigung nicht geklärt ist — im entschiedenen Fall war ein einziger Satz das zentrale Indiz. Umgekehrt gilt für Betroffene: Fehlgeleitete Kundenanfragen sind das entscheidende Beweismaterial und sollten dokumentiert werden. Zur Reichweite: Es handelt sich um eine Kostenentscheidung nach § 91a ZPO mit summarischer Prüfung, nicht um eine Hauptsacheentscheidung — die amtlichen Leitsätze und die ausführliche Würdigung machen sie gleichwohl zu einer belastbaren Orientierung.

5.1 Zählpixel in E-Mails: italienische Umsetzungsfrist endet am 29. Oktober

18.08.2026 · Garante: Provvedimento n. 284 vom 17.04.2026 · A&O Shearman: Analyse der Leitlinien

Behörde: Garante per la protezione dei dati personali (Italien) · Adressat: alle öffentlichen und privaten Stellen, die Zählpixel in E-Mails einsetzen · Höhe: noch keine Sanktion — Umsetzungsfrist läuft

Verstoß / Rechtsgrundlage: Art. 122 des italienischen Datenschutzkodex (d.lgs. 196/2003, Umsetzung der ePrivacy-Richtlinie) in Verbindung mit den Einwilligungs- und Informationspflichten der DSGVO. Der Garante qualifiziert das Einbetten eines Pixels in eine E-Mail und das Auslesen der Rückmeldedaten als Zugriff auf das Endgerät der empfangenden Person.

Begründung: Die Leitlinien gehen auf Ermittlungen zurück: Die Behörde führte im Oktober 2025 und im Februar 2026 Prüfungen bei einem E-Mail-Dienstleister und einer Marketing-Automation-Plattform durch und stellte fest, dass Zählpixel praktisch in allen Kommunikationsarten eingesetzt werden — Newsletter, Werbekampagnen, Transaktions- und institutionelle Nachrichten. Inhaltlich klärt das Provvedimento den anwendbaren Rechtsrahmen, benennt die Fälle, in denen keine Einwilligung erforderlich ist, legt Informationspflichten fest und verlangt einen granularen Widerruf. Praxisfreundlich ist ein Punkt: Der Garante lässt zu, dass die Einwilligung in die Pixel-Messung in der allgemeinen Einwilligung zum Empfang von Werbenachrichten aufgeht, um Mehrfachabfragen und Einwilligungsmüdigkeit zu vermeiden. Das Provvedimento wurde am 29. April 2026 im Gazzetta Ufficiale veröffentlicht; die Umsetzungsfrist von sechs Monaten endet damit am 29. Oktober 2026.

Praxisfolgen: Die Vorgaben treffen jeden, der Empfänger in Italien anschreibt — die Zuständigkeit knüpft an den Endgerätezugriff an, nicht an den Sitz des Versenders. Prüfen Sie, ob Ihr Versandsystem Öffnungs- und Lesezeitmessung standardmäßig aktiviert hat; bei den meisten Marketing-Plattformen ist das der Fall, oft ohne dass es im Einwilligungstext auftaucht. Klären Sie, ob Ihre Einwilligungserklärung die Messung abdeckt, ergänzen Sie die Datenschutzinformation um Zweck und Rechtsgrundlage und richten Sie einen granularen Widerruf ein — technisch bedeutet das, die Messung pro Empfänger abschaltbar zu machen, nicht nur den Newsletter insgesamt. Wer keine italienischen Empfänger hat, sollte die Leitlinien dennoch kennen: Sie sind die bislang ausführlichste behördliche Positionierung zu einem Verfahren, das in ganz Europa Standard ist, und liefern damit einen Maßstab, an dem sich andere Aufsichtsbehörden orientieren dürften.

6.1 Windows-VBS über das SPD-EEPROM von Speichermodulen ausgehebelt

18.08.2026 · heise: „Download more RAM“ — Windows-Sicherheit durch RAM-EEPROM geknackt · Universität Birmingham

Zusammenfassung: Auf der Usenix-Sicherheitskonferenz haben Forschende einen Angriff auf die Virtualization-Based Security (VBS) von Windows vorgestellt. Angriffspunkt ist das SPD-EEPROM (Serial Presence Detect) auf Speichermodulen, das Größe und Organisation des Riegels beschreibt und beim Start vom Mainboard ausgelesen wird. Die Forschenden verdoppeln die dort gemeldete Speichermenge; bei Zugriffen auf die dadurch entstandenen „oberen“ Bereiche werden die obersten Bits ignoriert, sodass ein Alias zwischen oberer und unterer Speicherhälfte entsteht. Ein so manipuliertes System startet zwar zunächst nicht, lässt sich aber über Startparameter dennoch booten — und einzelne Kernel-Funktionen greifen weiterhin auf den vermeintlich entfernten Speicher zu. Darüber ließen sich der Speicher VBS-geschützter Prozesse lesen, Anti-Cheat-Systeme umgehen, Mobile Device Management aushebeln und Virenschutz lahmlegen.

Hintergrund & Einordnung: Der Reiz der Arbeit liegt in der Ebene: VBS isoliert sicherheitskritische Prozesse mithilfe des Hypervisors und gilt als eine der belastbarsten Windows-Schutzmaßnahmen. Der Angriff umgeht diese Isolation nicht durch einen Fehler in der Isolation selbst, sondern durch eine Lüge über die Hardware, auf der sie aufsetzt — die Schutzannahme „die Speicherkarte im System entspricht der Beschreibung“ ist bislang nirgends geprüft worden. Die Voraussetzungen relativieren die Lage: Unter Windows brauchen die Forschenden Schreibzugriff auf das EEPROM, den sie sich über mitgebrachte verwundbare Treiber verschafften (BYOVD); unter Linux genügen die frei verfügbaren i2c-tools. Entscheidend für die Praxis ist der Hinweis der Universität Birmingham, dass Systeme mit aktiviertem Secure Boot gegen den vorgestellten Angriff immun sind. Als weitere Gegenmaßnahmen nennen die Forschenden Microsoft-Patches, Prüfungen auf Speicher-Aliasing durch BIOS oder Betriebssystem und die Verweigerung des Bootvorgangs mit Modulen ohne Schreibschutz; Corsair bietet über sein iCue-Werkzeug an, den Schreibschutz des SPD-EEPROMs nachträglich zu aktivieren.

Praxisfolgen / Handlungsempfehlung: Prüfen Sie flottenweit, ob Secure Boot aktiviert ist — das ist die zentrale Maßnahme und über MDM oder Gruppenrichtlinien auswertbar. Härten Sie parallel gegen BYOVD: Die Microsoft-Sperrliste für verwundbare Treiber aktivieren und aktuell halten, weil sie die Voraussetzung dieses Angriffs und mehrerer aktueller Ransomware-Ketten gleichermaßen adressiert. Bei Geräten mit besonders schutzbedürftigen Daten lohnt zusätzlich der Blick auf den SPD-Schreibschutz der verbauten Module. Und dokumentieren Sie die Bewertung: Die Meldung wird intern absehbar als „VBS ist gebrochen“ ankommen — die belastbare Antwort lautet, dass der Angriff erhebliche Vorrechte voraussetzt und bei aktiviertem Secure Boot nicht greift.