Die laufende Kalenderwoche 36 vom 31. August bis zum 6. September 2026 liefert diesmal eine bemerkenswert breite Mischung. Es gibt klassische Hardware-Leaks, bei denen Roadmaps, Taktraten und Plattformdetails vorzeitig auftauchen. Es gibt einen Software-Leak, bei dem NVIDIA unfreiwillig demonstriert bekommt, wie schnell sich eine eigentlich kontrolliert auszurollende Technik nach ihrer Veröffentlichung verselbstständigen kann. Und es gibt mehrere Sicherheitsvorfälle, bei denen der Begriff „Leak“ seine wesentlich unangenehmere Bedeutung annimmt. Der mit Abstand ernsteste Fall spielt sich dabei nicht in irgendeinem hypothetischen Datenblatt eines kommenden Prozessors ab, sondern im Berliner Landesnetz. Dort ist aus einem zunächst noch teilweise unklaren Cyberangriff inzwischen ein ausgewachsener Datenabfluss mit anschließender Erpressung und Veröffentlichung gestohlener Verwaltungsdaten geworden. Das ist qualitativ eine andere Liga als der übliche LeakWatch-Stoff und zugleich ein ziemlich anschauliches Beispiel dafür, warum Informationssicherheit bei Behörden nicht an der Firewall enden darf.

Daneben liefert NVIDIA mit DLSS 5 einen fast schon lehrbuchartigen Fall für die Rubrik „einmal draußen, immer draußen“. Die Neural-Rendering-Komponente tauchte vor dem eigentlichen offiziellen Start in NBA 2K27 auf, landete binnen kürzester Zeit in anderen Spielen und wurde anschließend von Moddern auf Hardware gebracht, für die NVIDIA die Technik offiziell überhaupt nicht vorgesehen hatte. Inzwischen reicht das Experiment sogar bis zu Radeon-GPUs. Intel wiederum bekommt mit einer geleakten Partnerfolie neue Nahrung für die Hoffnung, dass LGA1954 tatsächlich länger als eine Generation relevant bleibt. AMD steuert neue Gerüchte zu den anvisierten Taktraten von RDNA 5 bei. Gleichzeitig zeigen Angriffe auf Coder, JFrog, SonicWall, PaperCut und WordPress-Installationen, dass die interessanteren Leaks dieser Woche nicht unbedingt aus Entwicklungsabteilungen stammen.

Beim Angriff auf das Berliner Landesnetz ist in dieser Woche die bislang unangenehmste Phase eingetreten. Die Täter haben ihre Drohung wahr gemacht und gestohlene Daten veröffentlicht. Die Berliner Senatskanzlei bestätigte am 4. September ausdrücklich, dass die entwendeten Daten veröffentlicht worden sind und dass Sicherheitsbehörden sowie beauftragte IT-Forensiker das Material untersuchen. Personen, die im Zuge dieser Analyse als konkret betroffen identifiziert werden, sollen abhängig vom jeweiligen Risiko informiert werden. Damit ist eine wichtige Grenze überschritten. Zuvor stand noch die Behauptung der mutmaßlichen Täter im Raum, große Mengen an Verwaltungsdaten erbeutet zu haben. Nun steht zumindest fest, dass tatsächlich gestohlene Daten öffentlich zugänglich gemacht wurden. Nicht ebenso sicher bestätigt ist allerdings jede Zahl und jede Inhaltsangabe, die Rhysida selbst veröffentlicht hat.

Die Ransomware-Gruppe gibt an, ungefähr 5,7 bis 5,8 Terabyte beziehungsweise rund 1,44 Millionen Dateien erbeutet zu haben. Das Land Berlin hat diese Datenmenge bisher nicht unabhängig bestätigt. Deshalb sollte sie nicht als behördlich verifizierte Größe behandelt werden. Reuters und andere Medien berichten unter Berufung auf die Täterseite und die laufenden Untersuchungen ebenfalls über diese Größenordnung. Nach bisherigem Kenntnisstand fand der wesentliche Datenabfluss zwischen dem 7. und 12. August statt. Am 14. August wurden betroffene Bereiche vom Netz getrennt. Besonders relevant ist dabei, dass der Angriff nicht nur kurzfristig einzelne Systeme berührt hat. Die Täter hatten offenbar ausreichend Zeit, größere Datenmengen zusammenzustellen und abzutransportieren. Die Berliner Verwaltung stellte später fest, dass insbesondere im Geschäftsbereich der Senatsverwaltung für Mobilität, Verkehr, Klimaschutz und Umwelt weitere Daten abgeflossen waren. Rhysida versuchte anschließend, die Daten zu Geld zu machen. Das Mindestgebot für das gestohlene Material wurde mit 30 Bitcoin angegeben, nach damaligem Kurs rund zwei Millionen Euro. Berlin erklärte ausdrücklich, nicht zahlen zu wollen. Die Versteigerungsfrist lief am 4. September aus. Danach folgte die Veröffentlichung.

Die politische Entscheidung, kein Lösegeld zu zahlen, ist nachvollziehbar. Sie beseitigt allerdings nicht das eigentliche Problem. Bei klassischer Ransomware ging es früher häufig vor allem um verschlüsselte Systeme und die Frage, ob sich Daten aus Backups wiederherstellen lassen. Moderne Erpresser kombinieren Verschlüsselung und Datenabfluss dagegen zunehmend mit Double Extortion. Selbst wenn ein Unternehmen oder eine Behörde sämtliche Systeme aus Backups wiederherstellen kann, bleibt das Druckmittel der gestohlenen Daten bestehen. Und genau deshalb ist dieser Berliner Fall so gravierend. Ein Server kann neu installiert werden. Ein Passwort kann geändert werden. Eine veröffentlichte Personalakte, eine vertrauliche Vertragsunterlage, eine interne Telefonnummer, eine Infrastrukturinformation oder eine Kombination aus Namen, Adresse, Funktion und Kontaktdaten lässt sich dagegen nicht wieder zurückholen.

Gerade bei einem solchen Vorfall ist aber auch Zurückhaltung notwendig. Rhysida hat auf seiner Leak-Seite unter anderem Verträge, E-Mails, Telefonnummern, Passwörter, personenbezogene Daten und angeblich vertrauliche beziehungsweise klassifizierte Unterlagen genannt. Solange die Behörden das veröffentlichte Material noch auswerten, sollte aus solchen Täterangaben aber keine vollständige Inventarliste gemacht werden. Die Gefahr liegt ohnehin nicht allein in einzelnen spektakulären Dokumenten. Ein umfangreiches Verwaltungsarchiv kann auch dann problematisch sein, wenn viele Dateien auf den ersten Blick banal wirken. Angreifer können unterschiedliche Datensätze miteinander verknüpfen. Ein interner Name erhält durch eine weitere Datei eine Telefonnummer, durch ein anderes Dokument eine organisatorische Funktion, durch eine Rechnung möglicherweise eine Adresse und durch E-Mail-Archive Informationen über Kommunikationspartner. Aus vielen unscheinbaren Informationsfragmenten entsteht dadurch ein wesentlich wertvolleres Gesamtbild.

Genau das macht große Datenabflüsse für Phishing, Business Email Compromise und Social Engineering so interessant. Ein Angreifer muss seinem Opfer dann nicht mehr mit einer offensichtlich generischen Nachricht begegnen. Er kann konkrete Projekte, Ansprechpartner, Organisationsstrukturen oder tatsächliche Geschäftsvorgänge referenzieren. Hinzu kommt ein zweites Problem. Informationen über Gebäude, Verkehrsplanung, technische Infrastruktur oder Verwaltungsabläufe besitzen unter Umständen eine deutlich längere Halbwertszeit als ein kompromittiertes Passwort. Selbst wenn Zugangsdaten sofort geändert werden, verschwinden Pläne und interne Strukturen nicht automatisch.

Die Berliner Behörden haben erklärt, dass derzeit keine Hinweise auf eine weiterhin bestehende Infiltration des Landesnetzes vorliegen. Die forensische Untersuchung dauert allerdings an. Das ist kein Widerspruch. „Kein aktueller Hinweis auf eine Infiltration“ bedeutet nicht, dass bereits vollständig geklärt wäre, welcher Angriffsweg genutzt wurde, wie weit sich die Täter bewegen konnten und auf welche Datenbestände sie zugegriffen haben. Aus technischer Sicht gehört deshalb nicht nur die ursprüngliche Eintrittsstelle untersucht. Entscheidend ist die gesamte Angriffskette. Welche Identitäten wurden kompromittiert? Welche Rechte besaßen diese Konten? Konnten sich die Täter lateral im Netz bewegen? Welche Dateiserver und Fachverfahren waren erreichbar? Welche Daten wurden lediglich gelesen, welche tatsächlich exfiltriert? Existieren Hinweise auf persistente Zugänge? Welche Protokolle stehen für den relevanten Zeitraum überhaupt noch zur Verfügung?

Besonders unangenehm wird die Frage, wenn Logging und Netzwerksegmentierung nicht auf einen solchen Fall vorbereitet waren. Gute Backups schützen gegen Datenverlust. Sie dokumentieren aber nicht, wer welche Daten kopiert hat. Ein Virenscanner findet möglicherweise Malware. Er sagt jedoch nicht zwangsläufig, welche legitimen Zugangsdaten ein Angreifer anschließend verwendet hat. Ransomware-Abwehr ist deshalb längst Identity Security, Netzwerkarchitektur, Privileged Access Management, Telemetrie, Egress Monitoring und Incident Response zugleich. Der Berliner Vorfall sollte folglich nicht auf die Frage reduziert werden, ob jemand einen einzelnen Server schlecht abgesichert hatte. Das eigentliche Thema ist, wie weit ein kompromittierter Akteur innerhalb einer komplexen Verwaltung kommen kann und wie schnell ein ungewöhnlicher Datenabfluss erkannt wird.

Wesentlich unterhaltsamer, wenn auch technisch ebenfalls interessant, ist die Geschichte rund um DLSS 5. NVIDIA hat DLSS 5 in dieser Woche offiziell für NBA 2K27 eingeführt. Im Mittelpunkt steht nicht mehr nur klassische Rekonstruktion oder Frame Generation. NVIDIA bezeichnet die neue Technik als 3D-Guided Neural Rendering. Dabei soll ein neuronales Modell unter Einbeziehung der vom Spiel bereitgestellten Geometrie-, Material-, Beleuchtungs- und Bewegungsinformationen zusätzliche visuelle Details erzeugen. Das eigentlich LeakWatch-taugliche Ereignis fand jedoch schon unmittelbar vor dem offiziellen Start statt. In einer frühen NBA-2K27-Version tauchte die Bibliothek nvngx_dlssnr.dll auf. Die Datei war damit verfügbar, bevor NVIDIA den vorgesehenen Rollout abgeschlossen hatte.

Und was bei PC-Spielern anschließend passiert, ist ungefähr so vorhersehbar wie Wasser, das einem Gefälle folgt. Die Datei wurde untersucht, extrahiert und innerhalb kürzester Zeit für andere Spiele nutzbar gemacht. Zunächst entstanden experimentelle Implementierungen über ReShade und andere Zwischenschichten, später wurde DLSS 5 unter anderem in OptiScaler integriert. Tom’s Hardware konnte bereits vor der offiziellen Veröffentlichung Tests mit Community-Mods durchführen. Interessant ist dabei nicht nur, dass DLSS 5 in Spielen lief, für die NVIDIA es nie vorgesehen hatte. Noch interessanter wurde die Geschichte durch die Hardware.

NVIDIA startete DLSS 5 offiziell zunächst auf der GeForce-RTX-50-Serie. Schon die frühen Modding-Versuche zeigten jedoch, dass zumindest Teile des Stacks nicht fundamental an Blackwell gebunden sind. Modder passten inkompatible CUDA-Komponenten an und brachten Neural Rendering auf RTX-40-Hardware zum Laufen. Weitere Experimente erreichten ältere RTX-Generationen, teilweise mit drastisch reduzierter Performance. Damit ist ausdrücklich nicht gesagt, dass NVIDIA einfach willkürlich einen Schalter umlegt und identische Leistung auf jeder älteren RTX-Karte möglich wäre. Unterschiedliche Datentypen, Tensor-Fähigkeiten, Durchsatz und Architekturdetails spielen weiterhin eine Rolle. Die Existenz einer grundsätzlich funktionierenden Implementierung ist aber dennoch bemerkenswert. Noch schöner für eine LeakWatch-Ausgabe wird die Geschichte dadurch, dass die Reise inzwischen nicht mehr bei NVIDIA endet.

Am 5. September wurden funktionierende Experimente auf AMD Radeon bekannt. Eine inoffizielle Implementierung kann DLSS 5 Neural Rendering auf Radeon RX 9000 ausführen, erste Tests existieren auch für RDNA-3-Hardware wie die Radeon RX 7900 XTX. Der Ansatz verwendet offenbar AMD-native HIP-Compute-Kernel, um Teile des neuronalen Workloads auszuführen. Die derzeitige Performance macht daraus noch lange keine praktische Alternative. Auf einer Radeon RX 9070 XT werden in einem veröffentlichten Test ungefähr 28 bis 30 FPS bei 1080p genannt. Der Code befindet sich außerdem in einem frühen Zustand und ist derzeit nicht einmal vollständig offen dokumentiert. Die Empfehlung kann deshalb nur lauten, solche Binärdateien nicht leichtfertig auf einem Produktivsystem auszuführen. Technisch ist das Experiment trotzdem interessant. Es zeigt, dass die Grenze zwischen einem proprietären Feature und den zugrunde liegenden Rechenoperationen wesentlich komplizierter ist als ein Marketinglogo auf einer Verpackung vermuten lässt.

Der Leak liefert außerdem einen seltenen Blick auf die tatsächliche Architektur einer solchen Technik. DLSS 5 ist nicht einfach ein Filter, der am Ende ein fertiges Bild hübscher macht. NVIDIA beschreibt das Frame als unveränderliches geometrisches Fundament, das durch zusätzliche Engine-Daten ergänzt wird. Das neuronale Modell soll Materialreaktionen, Lichttransport, Haut, Haare und ähnliche Aspekte verändern beziehungsweise ergänzen, ohne die vom Entwickler vorgegebene Szenengeometrie neu zu erfinden. Genau deshalb benötigen universelle Mods zusätzliche Informationen. Ohne Motion Vectors und andere Hilfsdaten kann ein Modell dieser Art nicht einfach zuverlässig auf jedes beliebige Bild losgelassen werden. Die Modding-Szene versucht deshalb, fehlende Informationen über zusätzliche Verfahren bereitzustellen oder vorhandene Renderpfade anzuzapfen. Damit wird aus dem eigentlichen Leak fast schon eine unabhängige Forschungsplattform. NVIDIA dürfte daran nur bedingt Freude haben. Für technisch Interessierte ist es dagegen ausgesprochen aufschlussreich.

Bei Intel kommt diese Woche ein klassischerer Leak hinzu. Eine Partnerfolie aus China soll darauf hinweisen, dass der kommende Sockel LGA1954 nicht nur Nova Lake-S aufnehmen soll, sondern für mehrere CPU-Generationen vorgesehen ist. Die Folie nennt beziehungsweise impliziert nach Nova Lake weitere Generationen wie Razor Lake und Hammer Lake. Sie stammt laut VideoCardz nicht direkt von Intel, weshalb die langfristige Kompatibilität noch nicht als bestätigt gelten darf. Das Interessante ist allerdings, dass der zentrale Ausgangspunkt inzwischen kein Gerücht mehr ist. Intel selbst hat LGA1954 bereits gemeinsam mit NVL-S in einem Design-In-Tool-Eintrag genannt. Dass Nova Lake-S diesen Sockel nutzt, gilt damit praktisch als offiziell belegt.

Die neue Folie ergänzt nun einen möglichen Zeitplan. Demnach soll die Massenproduktion von Nova Lake-S im vierten Quartal 2026 beginnen. Erste 28-Kern-Versionen könnten im ersten Quartal 2027 erscheinen. Größere 52-Kern-Modelle würden später folgen. Auch ein großer bLLC-Cache mit bis zu 288 MB wird erneut genannt. Das passt zu früheren Informationen über die großen Dual-Compute-Tile-Konfigurationen. Gerade beim Thema Sockellaufzeit ist Skepsis trotzdem angebracht. Eine Plattform kann elektrisch und mechanisch kompatibel sein, ohne dass daraus automatisch Unterstützung jedes zukünftigen Prozessors auf jedem Mainboard entsteht. BIOS-Größe, Spannungsversorgung, Signalintegrität, Firmware, Management Engine und Herstellersupport können darüber entscheiden, welche Kombination tatsächlich funktioniert. Trotzdem wäre eine mehrgenerationige LGA1954-Plattform eine deutliche Verbesserung gegenüber der Wahrnehmung vieler Intel-Desktop-Plattformen der vergangenen Jahre. Ob Intel dieses Versprechen wirklich bis Hammer Lake trägt, bleibt einer der interessanteren Punkte für die kommenden Monate.

Auch AMD liefert frisches Futter. Kepler_L2 berichtet unter Berufung auf interne Informationen von anvisierten Taktraten zwischen 3,1 und 3,4 GHz für RDNA 5. VideoCardz ordnet die Angabe ausdrücklich als Gerücht ein. AMD hat weder diese Frequenzen noch finale RDNA-5-Produkte bestätigt. Die Spanne wäre gegenüber aktuellen RDNA-4-Produkten zumindest auffällig, aber nicht absurd. Eine Radeon RX 9070 XT besitzt offiziell einen maximalen Boost von bis zu rund 2,97 GHz. 3,4 GHz wären damit kein völlig neuer Frequenzbereich, sondern ungefähr 14 Prozent mehr. Viel mehr lässt sich aus der Zahl momentan allerdings nicht seriös ableiten. Ein Zieltakt sagt nichts über die Zahl der Shader, die tatsächliche IPC, die Breite des Frontends, Cache-Hierarchie, Speicherbandbreite, Raytracing-Leistung oder Leistungsaufnahme aus. Vor allem ist unklar, ob sich die genannte Spanne auf diskrete High-End-GPUs, APUs oder mehrere Produktklassen bezieht. Die Meldung ist daher genau das, was ein guter Hardware-Leak sein sollte: interessant genug, um ihn zu beobachten, aber viel zu früh, um daraus Benchmark-Balken zu malen.

Deutlich weniger harmlos ist ein weiterer Vorfall aus dieser Woche. Coder bestätigte einen Angriff auf die eigene Module Registry. Zwischen 07:35 und 21:45 UTC am 31. August erlangte ein Angreifer Zugriff auf einen Cloudflare-API-Key und manipulierte die Infrastruktur vor registry.coder.com. Ein Teil der Registry-Anfragen wurde dadurch zu einem vom Angreifer kontrollierten Server umgeleitet. Dieser lieferte manipulierte Coder- beziehungsweise Terraform-Module aus. Die Module waren darauf ausgelegt, Zugangsdaten abzugreifen. Coder nennt unter anderem Cloud-Credentials für AWS, GCP und Azure als relevante Zielinformationen. Das Bemerkenswerte daran ist der Angriffsweg. Der Angreifer musste weder den eigentlichen Coder-Quellcode manipulieren noch den offiziellen Build-Prozess übernehmen. Er kompromittierte die Infrastruktur zwischen Nutzer und Registry.

Das ist eine wichtige Erinnerung daran, dass Software Supply Chain Security nicht beim Git-Repository endet. Eine perfekt signierte und geprüfte Quellcodebasis hilft nur begrenzt, wenn ein Angreifer Kontrolle darüber erhält, welcher Server einem Client die vermeintlich dazugehörigen Artefakte ausliefert. Coder erklärte, den Vorfall am selben Tag bereinigt zu haben. Betroffene Nutzer sollen insbesondere prüfen, ob während des Zeitfensters Module geladen wurden, und möglicherweise exponierte Zugangsdaten rotieren.

Auch klassische Perimeter-Geräte liefern diese Woche wieder Gründe, Updates nicht auf den nächsten Wartungsmonat zu verschieben. SonicWall veröffentlichte am 1. September eine Warnung zu zwei Schwachstellen der SMA-1000-Serie. CVE-2026-83548 wird mit CVSS 10.0 bewertet und betrifft einen vor der Authentifizierung erreichbaren SSRF-Pfad. CVE-2026-83549 ermöglicht unter bestimmten Voraussetzungen die Ausführung von Code nach erfolgreicher Authentifizierung. SonicWall bestätigt ausdrücklich, dass die Schwachstellen bereits aktiv ausgenutzt werden. Gerade Remote-Access-Appliances sind attraktive Ziele, weil sie per Definition von außen erreichbar sein sollen und gleichzeitig weitreichenden Zugang in interne Netze vermitteln. Ein ungepatchtes Gateway ist daher nicht einfach ein weiteres verwundbares Gerät. Es kann der Eingang in genau die Infrastruktur sein, die das Gerät eigentlich schützen soll.

PaperCut meldete Ende August zwei Schwachstellen in PaperCut NG und MF, CVE-2026-82078 und CVE-2026-81578. Die beiden Fehler können miteinander kombiniert werden, um Authentifizierung zu umgehen und aus der Ferne Code auf verwundbaren Systemen auszuführen. PaperCut reagierte mit mehreren kurzfristigen Sicherheitsupdates. In dieser Woche wurde bekannt, dass die bereits als Zero Days ausgenutzten Schwachstellen auch für Datendiebstahl verwendet werden. Das ist besonders relevant, weil Print-Management-Systeme in Unternehmen, Behörden und Bildungseinrichtungen häufig eine wenig glamouröse, aber weitreichend integrierte Rolle spielen. Sie besitzen Zugriff auf Verzeichnisdienste, Benutzerdaten, Druckaufträge und teilweise zusätzliche Infrastruktur. Der Druckserver mag im Organigramm unspektakulär aussehen. Aus Angreifersicht kann er trotzdem ein sehr brauchbares Sprungbrett sein.

WordPress bleibt ebenfalls zuverlässig dabei, Arbeit für Administratoren zu produzieren. CVE-2026-32475 in Elementor Pro wird inzwischen aktiv ausgenutzt. Die Schwachstelle betrifft die Verarbeitung von Datei-Uploads in Formularen. Durch eine fehlerhafte Validierung mehrerer Dateien kann ein Angreifer eine präparierte PHP-Datei einschleusen und anschließend Code auf dem Server ausführen. Die betroffenen Versionen reichen bis einschließlich Elementor Pro 4.2.1. Elementor hatte bereits am 19. August mit Version 4.2.2 Änderungen an der Sicherheit des Form-Widgets veröffentlicht. Wordfence meldete anschließend eine sehr hohe Zahl beobachteter Exploit-Versuche. Das zeigt einmal mehr das typische Zeitfenster moderner WordPress-Angriffe. Sobald eine Schwachstelle veröffentlicht und ein Patch verfügbar ist, beginnt nicht erst gemütlich eine lange Analysephase. Automatisierte Scanner suchen praktisch sofort nach ungepatchten Installationen. Wer eine große WordPress-Installation betreibt, sollte Plugin-Updates deshalb nicht nur nach neuen Funktionen bewerten. Ein Changelog-Eintrag wie „Improved code security enforcement“ kann wesentlich wichtiger sein als zehn neue Editor-Funktionen.

Auch JFrog Artifactory ist betroffen. CVE-2026-82329 beschreibt eine kritische Authentifizierungs-Schwachstelle, über die ein nicht authentifizierter Angreifer bei Netzwerkzugriff administrative Rechte erhalten kann. JFrog bestätigt, dass die Schwachstelle in der Standardkonfiguration verschiedener selbst gehosteter Artifactory-Versionen vorhanden ist und nennt konkrete gepatchte Versionen. In dieser Woche kamen Berichte hinzu, dass Angreifer die Lücke bereits verwenden, um sich selbst Administrator-Tokens auszustellen. Auch hier ist die Position des Produkts entscheidend. Artifactory ist kein beliebiger Webdienst. Repository Manager sitzen direkt in Software-Lieferketten. Wer dort administrative Kontrolle erhält, kann abhängig von der jeweiligen Umgebung Artefakte verändern, Zugriffe manipulieren und nachgelagerte Build- und Deployment-Prozesse beeinflussen. Die Grenze zwischen „Server kompromittiert“ und „Software Supply Chain kompromittiert“ wird dadurch ausgesprochen dünn.

Zwischen Berlin, Coder, Artifactory, PaperCut, Elementor und SonicWall besteht auf den ersten Blick wenig Gemeinsamkeit. Bei genauerer Betrachtung zieht sich aber ein ziemlich klarer roter Faden durch die Woche. Angegriffen werden bevorzugt Systeme, denen andere Systeme vertrauen. Ein Remote-Access-Gateway wird vertraut, weil es Benutzer ins interne Netz bringt. Ein Repository wird vertraut, weil es Softwarepakete liefert. Eine Terraform Registry wird vertraut, weil Infrastruktur daraus automatisch aufgebaut wird. Ein WordPress-Plugin erhält Vertrauen, weil es serverseitig PHP ausführen und Dateien verarbeiten darf. Ein Verwaltungsnetz enthält Vertrauen, weil Beschäftigte und Fachverfahren auf gemeinsame Daten zugreifen müssen. Je zentraler ein Dienst ist, desto interessanter ist ein erfolgreicher Angriff. Das erklärt auch, warum klassische Malware immer häufiger nur noch ein Teilstück der Angriffskette ist. Die wichtigere Frage lautet nicht unbedingt, welcher Trojaner eingesetzt wurde. Interessanter ist häufig, welche legitime Vertrauensbeziehung anschließend missbraucht werden konnte.

Die interessanteste Hardwaremeldung der Woche ist wahrscheinlich Intels möglicher Versuch, LGA1954 tatsächlich mehrere Generationen lang leben zu lassen. AMDs angebliche RDNA-5-Taktziele sind interessant, aber noch ausgesprochen dünn. Der technisch spannendste Software-Leak ist DLSS 5, weil die Modding-Szene innerhalb weniger Tage eindrucksvoll demonstriert hat, wie wenig Kontrolle ein Hersteller über ausgelieferte Binärdateien besitzt, sobald diese auf Millionen frei programmierbarer PCs landen. Der wichtigste Leak der Woche ist trotzdem Berlin. Dort geht es nicht um einen Benchmark einige Monate vor dem Launch und auch nicht um eine DLL, die jemand zu früh gefunden hat. Es geht um Daten von Verwaltung, Beschäftigten, Bürgern und Unternehmen, die eine kriminelle Gruppe erbeutet hat und inzwischen veröffentlicht. Dabei sollte die Größenordnung von 5,7 beziehungsweise 5,8 Terabyte weiterhin als Täterangabe behandelt werden, solange Berlin die tatsächliche Datenmenge nicht abschließend bestätigt hat. Dass überhaupt umfangreiche Daten entwendet und veröffentlicht wurden, ist dagegen keine Spekulation mehr. 

Ein Gerücht kann falsch sein. Ein Roadmap-Leak kann veraltet sein. Ein Engineering Sample kann niemals in den Handel kommen. Ein veröffentlichter Datensatz lässt sich dagegen nicht wieder zurück in den Server schieben. Das Internet vergisst nicht besonders gut. Kriminelle Archive leider noch weniger.

Was ist LeakWatch?
Im Rahmen dieses redaktionellen Projekts wird ein eigens progranmmierter und trainierter Bot zur speziellen Internet-Recherche des Autors genutzt, der die automatisierte Analyse relevanter Datenquellen übernimmt und gleichzeitig Übersetzungen erstellt. Ziel ist die Verwendung möglichst unverfälschter Primärquellen, weshalb sämtliche Links tabellarisch erfasst werden, um eine optionale vertiefende Recherche durch den interessierten Leser zu ermöglichen. Die automatisierte Suche und Extraktion wäre ohne KI-Unterstützung nur mit unverhältnismäßigem Aufwand realisierbar, dennoch erfolgen jede Auswertung und die eigentliche Texterstellung redaktionell und es wird zudem alles inhaltlich noch einmal geprüft, da die KI nicht alle Inhalte vollständig zuverlässig interpretieren oder formulieren kann. LeakWatch ist als periodisch erscheinendes Sicherheits- und Leak-Analyseformat konzipiert, das im Stil von igor’sLAB und unter Anwendung konkreter Vorgaben erstellt wird. Der Fokus liegt auf nachprüfbaren Ereignissen aus Primärquellen, technischer Einordnung und vollständig neutraler Bewertung ohne den Einfluss von bereits gefilterten Sekundärinformationen Dritter.