Die Kalenderwoche 37 läuft zwar noch bis Sonntag, den 13. September 2026, aber schon am Samstagabend lässt sich ziemlich eindeutig feststellen, wo diesmal der Schwerpunkt liegt. Wer auf die übliche Mischung aus zu früh fotografierten Grafikkartenkartons, halb lesbaren Roadmaps und einem Engineering Sample wartet, bekommt zwar auch etwas geboten, die wirklich wichtigen Leaks dieser Woche haben jedoch eine wesentlich unangenehmere Qualität. Berlin beschäftigt sich weiterhin mit den Folgen des Datenabgriffs aus dem Landesnetz. Über das unmittelbar vor dieser Kalenderwoche liegende Wochenende veröffentlichten die Täter ein weiteres Datenpaket, das nach Angaben des Landes diesmal auch Zugangsdaten enthält. Seit dem 10. September existiert deshalb eine zentrale Anlaufstelle für möglicherweise Betroffene. Damit entwickelt sich der Fall von einem zunächst technisch betrachteten Cyberangriff zunehmend zu einem langfristigen Datenschutz- und Identitätsproblem.

Microsoft wiederum liefert mit dem September-Patchday eine Zahl, bei der man zunächst noch einmal nachsehen möchte, ob nicht versehentlich eine Null zu viel erfasst wurde. Je nach Zählweise werden 966 behobene Schwachstellen ausgewiesen, darunter zwei bereits aktiv ausgenutzte Zero Days. SAP legt parallel mehrere sehr kritische Sicherheitskorrekturen nach, eine davon erreicht den maximalen CVSS-Wert von 10,0. Bei JFrog Artifactory wird gleichzeitig sichtbar, wie schnell aus einer Schwachstelle ein realer Angriff auf eine Software-Lieferkette werden kann. Bei F5 taucht ein Linux-Rootkit auf, das seine Webshell nicht gemütlich auf die Festplatte legt, sondern direkt in laufende Prozesse injiziert. Android bekommt mit Mantax Otax eine Kombination aus Spyware und Ransomware, und bei einer mutmaßlich mit Vietnam verbundenen APIS-Infrastruktur lagen mehr als 220 Millionen Datensätze von Flugreisenden und Besatzungen erreichbar im Netz. Etwas klassische LeakWatch-Kost gibt es ebenfalls. NVIDIA soll für die GeForce RTX 5070 eine zweite GPU-Variante auf Basis des größeren GB203 vorbereiten, ohne dass die Karte dadurch zwangsläufig schneller wird. Apples A20 Pro wiederum taucht bereits in frühen Benchmark-Datenbanken auf. Und der DLSS-5-Leak der vergangenen Woche beginnt sich endgültig zu verselbstständigen, weil daraus inzwischen ein relativ bequem nutzbares Community-Paket für mehrere RTX-Generationen geworden ist.

Der Cyberangriff auf die Berliner Verwaltung war bereits in der vergangenen LeakWatch-Ausgabe der unangenehmste Fall der Woche. Inzwischen wird deutlicher, dass der eigentliche Schaden nicht mit dem Abfluss der Dateien endete. In der Nacht zum 6. September veröffentlichten die Angreifer ein weiteres Datenpaket. Nach Angaben der Berliner Senatskanzlei enthält dieses Paket auch Zugangsdaten. Die zuständige Senatsverwaltung für Stadtentwicklung, Bauen und Wohnen überprüfte daraufhin bestehende Sicherheitsmaßnahmen und verschärfte sie teilweise. Das führte gleichzeitig dazu, dass bestimmte Fachanwendungen vorübergehend nur eingeschränkt verfügbar sein konnten. Der Zeitpunkt liegt formal noch am Ende der KW 36. Die Folgen und die eigentliche Aufarbeitung bestimmen jedoch die gesamte laufende Woche. Am 10. September richtete Berlin eine zentrale Informations- und Kontaktstelle ein, über die sich Bürger, Unternehmen und andere möglicherweise Betroffene über den Stand des Vorfalls informieren können.

Berlin beschreibt inzwischen auch etwas genauer, welche Art von Daten überhaupt betroffen sein kann. Der wesentliche Abfluss soll zwischen dem 7. und 12. August stattgefunden haben. Besonders betroffen waren demnach Bereiche der Senatsverwaltung für Mobilität, Verkehr, Klimaschutz und Umwelt sowie der Senatsverwaltung für Stadtentwicklung, Bauen und Wohnen. Die betroffenen Systeme wurden am 14. August vom Netz getrennt. Interessant ist dabei eine wichtige technische Einschränkung. Nach den bisherigen Erkenntnissen handelt es sich bei einem großen Teil des Materials offenbar nicht um sauber strukturierte Exporte aus einzelnen Fachverfahren, sondern um Daten aus gemeinsam genutzten und persönlichen Verzeichnissen von Beschäftigten. Das klingt zunächst weniger dramatisch als eine vollständig kopierte Bürgerdatenbank, muss es aber nicht sein. Gerade solche Dateiablagen enthalten häufig genau jene Mischung, die für spätere Angriffe besonders nützlich ist. Dazu können Korrespondenz, Tabellen, Antragsunterlagen, interne Listen, Kontaktdaten, Bewerbungen, Entwürfe, Rechnungen und andere Arbeitsunterlagen gehören. Berlin weist ausdrücklich darauf hin, dass personenbezogene Daten von Beschäftigten, Bürgern und Unternehmen betroffen sein können. Die Auswertung ist noch nicht abgeschlossen. 

Dass im zweiten veröffentlichten Paket nach Behördenangaben Zugangsdaten enthalten sind, verdient besondere Aufmerksamkeit. Dabei ist ausdrücklich noch nicht öffentlich geklärt, wie viele dieser Zugangsdaten zum Zeitpunkt der Veröffentlichung überhaupt noch gültig waren. Selbst ein bereits zurückgesetztes Passwort kann jedoch Informationen preisgeben. Benutzernamen verraten Namenskonventionen und interne Strukturen. E-Mail-Adressen lassen sich Organisationseinheiten zuordnen. Hostnamen können Rückschlüsse auf Systeme und Funktionen ermöglichen. Alte Kennwörter liefern bei Wiederverwendung oder ähnlichen Kennwortmustern Anhaltspunkte für weitere Angriffe. Werden solche Informationen anschließend mit E-Mails, Telefonnummern, Zuständigkeiten und echten Verwaltungsdokumenten kombiniert, steigt die Qualität möglicher Phishing-Angriffe erheblich.

Genau deshalb warnt Berlin Betroffene inzwischen ausdrücklich vor Kontaktversuchen, bei denen sich Kriminelle als Behörden, Arbeitgeber oder andere vertraute Stellen ausgeben könnten. Besonders problematisch sind beispielsweise geleakte Bewerbungsunterlagen, weil sich damit Nachrichten konstruieren lassen, die einen tatsächlichen Bewerbungsvorgang glaubwürdig aufgreifen. Der Vorfall zeigt damit recht anschaulich, warum die Frage nach der Größe eines Leaks allein wenig aussagt. Die von den mutmaßlichen Tätern genannte Datenmenge von rund 5,7 beziehungsweise 5,8 Terabyte bleibt weiterhin eine Täterangabe und wurde vom Land nicht unabhängig bestätigt. Für das reale Risiko ist ohnehin entscheidender, welche Informationen miteinander kombiniert werden können. Ein Gigabyte aus den richtigen Verzeichnissen kann unangenehmer sein als mehrere Terabyte bedeutungsloser Archivdaten.

Wer in dieser Woche Windows-Systeme administriert, bekommt ebenfalls Beschäftigung. Microsoft veröffentlichte am 8. September seine regulären Sicherheitsupdates. BleepingComputer kommt bei der Auswertung des gesamten September-Patchdays auf 966 behobene Schwachstellen. Darunter befinden sich 105 als kritisch eingestufte Probleme, 258 Remote-Code-Execution-Lücken und 438 Schwachstellen zur Rechteausweitung. Nach dieser Zählweise handelt es sich um den bislang größten Microsoft-Patchday. Die große Gesamtzahl sollte allerdings nicht so interpretiert werden, als gäbe es plötzlich 966 vollständig unabhängige Wege, einen beliebigen Windows-PC zu übernehmen. Microsoft-Produkte teilen Komponenten, Schwachstellen können mehrere Produktzweige betreffen und die Zählweise über den gesamten Update-Katalog produziert entsprechend große Summen. Wichtiger sind deshalb die beiden Schwachstellen, bei denen Microsoft bereits reale Angriffe beobachtet.

CVE-2026-81963 betrifft den Windows Update Stack. Durch eine fehlerhafte Auflösung von Links beziehungsweise Pfaden kann ein lokaler Angreifer seine Rechte bis auf SYSTEM-Niveau erhöhen. CVE-2026-85880 steckt in Windows ALPC und basiert auf einem Heap-basierten Pufferüberlauf. Auch hier kann ein Angreifer letztlich SYSTEM-Rechte erlangen. Beide Lücken wurden bereits vor beziehungsweise zum Zeitpunkt der Veröffentlichung der Updates aktiv ausgenutzt. Das ist eine wichtige Differenzierung. Beide Fehler sind nicht automatisch klassische Remote-Angriffe aus dem Internet. Ein Angreifer benötigt zunächst einen geeigneten lokalen Ausführungskontext. Genau solche Privilege-Escalation-Lücken sind aber hervorragende zweite Stufen einer Angriffskette. Ein eingeschleuster Prozess, ein kompromittierter Browser oder ein Benutzerkonto mit eingeschränkten Rechten wird erheblich interessanter, wenn anschließend ein bekannter Weg zu SYSTEM existiert.

966 CVEs wirken spektakulär, die Zahl ist aber auch ein Resultat der Größe heutiger Softwareplattformen. Windows besteht längst nicht mehr nur aus Kernel, Desktop und einigen Systemprogrammen. Dazu kommen Virtualisierung, Cloud-Anbindung, Office-Komponenten, Hyper-V, Windows Server, Netzwerkdienste, Authentifizierung, Entwicklungswerkzeuge, Datenbankkomponenten und zahlreiche gemeinsam verwendete Bibliotheken. Eine einzelne Sicherheitslücke kann dadurch quer durch mehrere Produkte laufen. Für Administratoren wird deshalb zunehmend wichtiger, nicht ausschließlich CVSS-Werte abzuarbeiten. Reale Ausnutzung, öffentliche Exploit-Verfügbarkeit, Erreichbarkeit des betroffenen Dienstes und die Stellung des Systems innerhalb der eigenen Infrastruktur sind mindestens ebenso wichtig. Ein Domain Controller mit einer aktiv ausgenutzten Rechteausweitung besitzt eine andere Priorität als ein deaktivierter Dienst auf einem isolierten Testsystem, selbst wenn die nackte CVSS-Zahl ähnlich aussieht.

SAP trägt ebenfalls zu einer arbeitsreichen Woche bei. Zum September Security Patch Day veröffentlichte SAP 19 neue Security Notes und aktualisierte zusätzlich eine bereits vorhandene Meldung. Besonders kritisch ist CVE-2026-44756 im Zusammenhang mit der Verarbeitung von SAP Extended Passports. SAP bewertet die Speicherfehler-Schwachstelle mit dem maximal möglichen CVSS-Wert von 10,0. Dazu kommt CVE-2026-58240 mit 9,8 Punkten. Hier fehlt unter bestimmten Bedingungen eine notwendige Authentifizierungsprüfung im SAP NetWeaver Message Server. CVE-2026-76969 erreicht 9,4 Punkte und betrifft die mögliche Offenlegung von Zugangsdaten in bestimmten Multitenant-Anwendungen des SAP Cloud Application Programming Model. Eine weitere Schwachstelle mit 9,0 Punkten betrifft unzureichende Zugriffskontrollen in SAP GUI for Java. Bei SAP-Systemen sollte man solche Meldungen nicht allein deshalb unterschätzen, weil die Produkte selten direkt auf einem typischen Endanwender-PC auftauchen. SAP sitzt in vielen Unternehmen genau dort, wo besonders wertvolle Daten verarbeitet werden. Finanzdaten, Personalinformationen, Lieferketten, Bestellungen, Produktion und Geschäftsprozesse laufen nicht selten durch dieselbe Plattform. Die technische Reichweite eines erfolgreichen Angriffs kann deshalb erheblich größer sein als bei einer isolierten Client-Anwendung.

JFrog Artifactory war bereits in der vergangenen Woche Thema, die Geschichte wird aber eher unangenehmer als besser. CVE-2026-82329 ermöglicht unter bestimmten Standardkonfigurationen einem nicht authentifizierten Angreifer über das Netzwerk den Erhalt administrativer Rechte. JFrog veröffentlichte korrigierte Versionen und zusätzliche sicherheitsrelevante Konfigurationsänderungen. Inzwischen liegen Berichte über reale Angriffe vor, bei denen zusätzlich CVE-2026-42016 und CVE-2026-42018 miteinander kombiniert wurden. Beobachtete Angreifer konnten sich teilweise innerhalb weniger Minuten administrative Konten verschaffen. Anschließend wurden unter anderem manipulierte Groovy-Plug-ins, langlebige Tokens und ein in Rust geschriebener Backdoor eingesetzt. Die Angriffe sollen zwischen Mitte August und Anfang September beobachtet worden sein. Besonders interessant ist dabei das Verhalten nach der eigentlichen Kompromittierung. Die Angreifer beschränkten sich nicht darauf, einen Webserver zu übernehmen, sondern suchten gezielt nach Repositories, Tokens, Benutzerkonten, Konfigurationsdaten und Cluster-Informationen. Und genau damit wird aus einer Artifactory-Lücke ein Supply-Chain-Problem.

Artifactory wird gerade deshalb eingesetzt, weil andere Systeme seiner Ausgabe vertrauen. Build-Server laden dort Bibliotheken und Artefakte. Entwickler beziehen Pakete daraus. Automatisierte Deployment-Pipelines verteilen Software weiter. Interne Anwendungen erwarten, dass ein Artefakt aus dem eigenen Repository vertrauenswürdig ist. Wird genau dieser Vertrauensanker kompromittiert, kann ein Angreifer theoretisch wesentlich weiter kommen als mit einer einzelnen infizierten Arbeitsstation. Das bedeutet nicht automatisch, dass in den jetzt beobachteten Angriffen tatsächlich manipulierte Software an Endkunden verteilt wurde. Dafür gibt es in den vorliegenden Berichten keinen allgemeinen Nachweis. Das Risiko ergibt sich vielmehr aus der Position des kompromittierten Systems. Supply-Chain-Sicherheit besteht deshalb nicht nur daraus, Quellcode zu prüfen und Builds zu signieren. Die Server, die Pakete verteilen, Tokens speichern und Build-Prozesse versorgen, gehören selbst zu den hochwertigsten Angriffszielen einer Entwicklungsumgebung.

Noch interessanter wird es bei F5 BIG-IP APM. Sicherheitsforscher haben einen Linux-Rootkit analysiert, der kompromittierte BIG-IP-Systeme dazu verwendet, eine Webshell direkt in den Arbeitsspeicher laufender Prozesse einzuschleusen. Das bedeutet, dass die eigentliche Hintertür nicht zwangsläufig als klassische Webshell-Datei im Dateisystem auftauchen muss. Der von Forschern unter anderem als PoisonedRefresh bezeichnete Ansatz soll sich in laufende Webserver-Prozesse einklinken. Sophos geht laut dem Bericht davon aus, dass der Rootkit wahrscheinlich als zweite Stufe nach einer initialen Kompromittierung eingesetzt wird. Als möglicher Eintrittsweg wird CVE-2025-53521 genannt, eine kritische Schwachstelle, deren Bewertung F5 später von einem Denial-of-Service-Problem auf eine Remote-Code-Execution-Lücke korrigierte. Die genaue initiale Angriffskette ist allerdings nicht in jedem beobachteten Fall zweifelsfrei belegt. Es wäre deshalb zu weitgehend, CVE-2025-53521 pauschal als bestätigten Eintrittspunkt jedes Angriffs darzustellen. Der technisch interessantere Punkt ist ohnehin die Persistenz beziehungsweise Tarnung.

Viele klassische Incident-Response-Abläufe beginnen mit Dateien. Welche Datei wurde verändert? Welche unbekannte PHP-Datei liegt im Webroot? Welche Binärdatei besitzt einen ungewöhnlichen Hash? Welche Bibliothek wurde nachinstalliert? Bei einem rein im Speicher aktiven Implantat greifen solche Methoden nur begrenzt. Ein kompromittierter Prozess kann manipuliert sein, obwohl sein ursprüngliches Programm auf der Festplatte vollkommen korrekt aussieht. Nach einem Neustart kann das Implantat zunächst verschwunden sein, aber über eine andere Persistenzkomponente erneut geladen werden. Deshalb gewinnen Speicheranalyse, Prozessintegrität, Netzwerk-Telemetrie und die Überwachung ungewöhnlicher Laufzeitveränderungen an Bedeutung. Gerade bei einem VPN- beziehungsweise Access-System ist das kritisch. Ein kompromittiertes Gateway sitzt nicht irgendwo am Rand des Netzes, weil es unwichtig wäre. Es sitzt dort, weil es externe Verbindungen kontrolliert und intern eine besonders vertrauenswürdige Rolle besitzt.

Auch auf Android-Seite gibt es diese Woche einen bemerkenswerten Fund. Zimperiums zLabs beschreibt eine Malware-Familie namens Mantax Otax, die vor allem mit indonesischen Akteuren in Verbindung gebracht wird. Die Schadsoftware kombiniert Funktionen klassischer Spyware mit Ransomware-Elementen. Die Verteilung erfolgt nicht regulär über Google Play, sondern über bösartige APK-Dateien und Social Engineering. Nach der Installation versucht die Anwendung umfangreiche Berechtigungen zu erhalten, insbesondere über Androids Accessibility-Funktionen. Sind diese Rechte vorhanden, kann die Malware unter anderem Bildschirmaktivitäten aufzeichnen, Browserhistorien auslesen, Kontakte, Anruflisten und SMS erfassen, Dateien sammeln und unbemerkt Fotos aufnehmen. Selbst die Displaysperre beziehungsweise PIN-Eingaben gehören zu den interessanten Zielen.

Auf älteren Android-Versionen kann Mantax Otax zusätzlich Benutzerdaten verschlüsseln und anschließend über eine Chat-Oberfläche Lösegeld verlangen. Bei neueren Android-Versionen erschweren die inzwischen stärkeren Speicherbeschränkungen diesen Teil des Angriffs, die Spionagefunktionen bleiben dadurch aber nicht automatisch wirkungslos. Technisch auffällig ist auch die C2-Infrastruktur. Die Malware kann den jeweils aktiven Steuerungsserver über Informationen auf GitHub ermitteln und anschließend unter anderem Firebase für persistente Kommunikation verwenden. Das ist ein Muster, das bei moderner Malware immer wieder auftaucht. Seriöse Cloud- und Entwicklerdienste werden nicht angegriffen, sondern als Bestandteil der eigenen Infrastruktur missbraucht, weil deren Domains im normalen Netzwerkverkehr wesentlich weniger verdächtig wirken als ein frisch registrierter Malware-Server.

Ein anderer Fall dieser Woche zeigt, dass ein Leak nicht zwingend einen besonders ausgefeilten Angreifer benötigt. Sicherheitsforscher von Kinryū Labs fanden eine offen erreichbare Infrastruktur mit mehr als 220 Millionen Datensätzen aus sogenannten Advance Passenger Information Systems, kurz APIS. Die Daten scheinen mit einer vietnamesischen Organisation in Verbindung zu stehen, der konkrete Betreiber konnte jedoch nicht abschließend bestätigt werden. Die gefundenen Indizes enthielten ungefähr 210,3 Millionen Passagierdatensätze und weitere 10,5 Millionen Einträge zu Besatzungsmitgliedern. Zusammen ergibt das rund 220,8 Millionen Datensätze. Dabei handelt es sich ausdrücklich nicht um 220 Millionen eindeutig verschiedene Menschen. Vielflieger tauchen naturgemäß mehrfach auf. Der Zeitraum der gespeicherten Informationen reicht laut Analyse von Januar 2017 bis April 2026.

Enthalten waren unter anderem Namen, Geburtsdaten, Geschlecht, Nationalität, Passnummern beziehungsweise andere Reisedokumentnummern, deren Ablaufdaten und Ausstellerstaaten sowie Fluggesellschaften, Flugnummern, Start- und Zielflughäfen, Sitzinformationen und Gepäckreferenzen. Besonders bemerkenswert ist die Ursache. Der offensichtliche öffentliche Endpunkt verlangte zwar eine Authentifizierung und antwortete entsprechend mit HTTP 401. Über einen alternativen Cloud-Pfad ließ sich das dahinterliegende System jedoch trotzdem erreichen. Dort funktionierten offenbar Standardzugangsdaten. Das ist keine spektakuläre Zero-Day-Kette. Es ist wesentlich banaler und gerade deshalb lehrreich.

Solche Fehlkonfigurationen entstehen häufig, wenn unterschiedliche Infrastrukturkomponenten unabhängig voneinander betrachtet werden. Der öffentliche Endpunkt ist abgesichert, der Reverse Proxy funktioniert, die Anwendung verlangt eine Anmeldung. Damit sieht die Oberfläche zunächst korrekt geschützt aus. Wenn jedoch dieselbe Datenbank oder Suchinstanz über eine andere Cloud-Adresse direkt erreichbar bleibt, existiert diese Schutzschicht faktisch nur auf einem von mehreren Wegen. Die Forscher meldeten das Problem am 3. Juni. Bis zum 8. Juni soll der offene Zugang geschlossen worden sein. Entscheidend ist jedoch ein weiterer Punkt: Es gibt nach bisherigem Stand keinen Nachweis, dass Kriminelle die Daten tatsächlich zuvor kopiert haben. Gleichzeitig fehlen offenbar ausreichende Serverprotokolle, um einen solchen Zugriff sicher auszuschließen. Das ist deshalb zunächst eine bestätigte massive Datenexposition, aber kein bestätigter krimineller Datendiebstahl. Genau diese Trennung ist wichtig.

Anthropic veröffentlichte am 10. September einen neuen Threat-Intelligence-Bericht zur missbräuchlichen Nutzung von Claude. Der Bericht deckt von Dezember 2025 bis August 2026 beobachtete Aktivitäten ab und beschreibt unter anderem Cyberangriffe, Einflussoperationen, Betrug, Überwachung und militärisch relevante Versuche. Besonders interessant ist ein von Anthropic als GTG-20006 bezeichneter Akteur, dessen Verhalten nach Einschätzung des Unternehmens mit öffentlichen Berichten über die russische Gruppe Midnight Blizzard übereinstimmt. Claude soll in diesem Zusammenhang für automatisierte beziehungsweise teilautomatisierte Arbeitsschritte bei Operationen gegen ukrainische und europäische Regierungs- und Militärziele sowie diplomatische und verteidigungsnahe Organisationen verwendet worden sein. Wichtig ist die Formulierung.

Das ist Anthropics eigene Attribution und Analyse. Sie sollte nicht als unabhängig bewiesene Identität des Akteurs missverstanden werden. Bemerkenswert ist weniger, dass ein Angreifer ein Sprachmodell nach Code fragt. Das passiert längst. Interessanter ist der zunehmende Grad der Arbeitsteilung. Modelle werden für Reconnaissance, Codeanalyse, Skripterstellung, Verarbeitung gestohlener Informationen und die Automatisierung wiederkehrender Schritte  ingesetzt. Damit sinkt nicht zwangsläufig die technische Mindestanforderung für jeden komplexen Angriff auf null. Ein Modell ersetzt weder Infrastrukturzugriff noch Exploits. Es kann aber die Zeit reduzieren, die ein Mensch für viele einzelne Teilschritte benötigt.

Noch ungewöhnlicher ist ein weiterer von Anthropic beschriebener Fall. Russische Akteure sollen Claude verwendet haben, um Software für autonom agierende FPV-Kamikaze-Drohnen beziehungsweise Drohnenschwärme zu entwickeln. Nach Angaben Anthropics gibt es allerdings keinen Nachweis, dass daraus tatsächlich ein einsatzfähiges Waffensystem entstand. Ein erwähnter Test scheint vielmehr gescheitert zu sein, woraufhin die Entwickler erneut das Modell zur Fehlersuche verwendeten. Gerade diese Einschränkung ist wichtig. Zwischen einem vom Modell erzeugten Stück Software und einer funktionierenden autonomen Waffe liegen Sensorik, Navigation, Funk, Mechanik, Echtzeitsteuerung und eine Menge sehr realer Physik. Der Fall zeigt trotzdem, dass die Diskussion über KI-Missbrauch nicht mehr sinnvoll auf Phishing-Texte und ein paar Python-Skripte reduziert werden kann.

Zurück in deutlich harmlosere Gefilde. Der DLSS-5-Fall aus der vergangenen Woche liefert inzwischen ein schönes Beispiel dafür, was passiert, wenn eine proprietäre Runtime einmal außerhalb des ursprünglich vorgesehenen Auslieferungswegs verfügbar ist. Auf GitHub entwickelt sich DLSS Unlocked inzwischen schnell weiter. Das Projekt bündelt mehrere bereits bestehende Community-Ansätze und versucht, Funktionen wie Neural Rendering, Frame Generation und Multi Frame Generation auf RTX-Generationen verfügbar zu machen, die NVIDIA dafür teilweise nicht offiziell vorgesehen hat. Innerhalb der laufenden Woche erschienen mehrere neue Versionen. Unterstützt beziehungsweise adressiert werden inzwischen RTX-20-, RTX-30- und RTX-40-Karten. Je nach Generation unterscheiden sich die verwendeten Wege deutlich. Teilweise werden NVIDIA-Funktionen genutzt, teilweise dient AMDs FSR 3.1 als Interpolationspfad. Neuere Varianten experimentieren zusätzlich mit hardwarebeschleunigten Pfaden auf Turing und Ampere.

Das ist nicht mit offizieller NVIDIA-Unterstützung zu verwechseln. Ebenso bedeutet die Tatsache, dass eine Funktion irgendwie läuft, nicht, dass sie auf älteren GPUs dieselbe Qualität, Stabilität oder Performance erreicht wie auf der offiziell vorgesehenen Architektur. 

Der interessante Teil ist nicht einmal die konkrete Mod. Die spannendere Erkenntnis lautet, dass Softwaresegmentierung nur so lange wirklich kontrollierbar bleibt, wie alle beteiligten Komponenten unter Kontrolle des Herstellers stehen. Sobald eine DLL, ein Modell oder ein ausführbarer Bestandteil auf normalen PCs landet, kann er analysiert, gepatcht, umgeleitet und in andere Softwareketten eingebaut werden. NVIDIA kann offizielle Supportgrenzen setzen. Es kann Treiber optimieren. Es kann bestimmte Hardware voraussetzen. Es kann Spielehersteller nur für bestimmte Konfigurationen zertifizieren. Was es nicht zuverlässig verhindern kann, ist die Neugier von Leuten mit Debugger, Hex-Editor und zu viel Freizeit. Das war bei DLSS schon immer so. DLSS 5 macht es nur besonders anschaulich.

Damit kommen wir zu einem klassischen Hardware-Leak. Nach einem Bericht von VideoCardz unter Berufung auf den Leaker hongxing2020 soll NVIDIA eine weitere Variante der GeForce RTX 5070 vorbereiten. Statt des regulär verwendeten GB205 könnte diese Version einen stärker deaktivierten GB203-Chip verwenden. Das klingt zunächst nach einem Upgrade, denn GB203 ist der größere Chip. Genau das muss es aber nicht sein. Es gibt bislang keinen belastbaren Hinweis darauf, dass die angebliche GB203-Version zusätzliche CUDA-Kerne, mehr Speicher, ein breiteres Speicherinterface oder höhere Taktraten bekommt. Das naheliegendere Szenario wäre eine zusätzliche Salvage-Konfiguration. Ein teilweise defekter GB203 muss nicht weggeworfen werden, wenn genügend funktionierende Einheiten vorhanden sind, um daraus eine RTX 5070 mit exakt denselben freigeschalteten Ressourcen wie beim GB205-Modell zu machen. NVIDIA verwendet solche Strategien nicht zum ersten Mal. Auch bei anderen GeForce-Modellen existieren Varianten, bei denen ein größerer Chip stärker beschnitten wird und am Ende dieselben offiziellen Spezifikationen erfüllt.

Für Käufer entsteht daraus trotzdem eine interessante Frage. Zwei Grafikkarten mit identischer Produktbezeichnung können intern unterschiedliche Dies besitzen. Das muss für Leistung und Funktionsumfang vollkommen irrelevant sein, solange dieselben Ressourcen aktiviert sind und dieselben Taktraten gelten. Theoretisch können sich trotzdem minimale Unterschiede bei Leistungsaufnahme, Spannung, thermischem Verhalten oder Overclocking ergeben.Solange keine realen Karten vermessen wurden, wäre jede Behauptung darüber jedoch reine Spekulation. Bislang fehlen außerdem konkrete Device-IDs, Boardvarianten, Markttermine und eine Bestätigung durch NVIDIA. Die Meldung bleibt deshalb ein klassischer Hardware-Leak, kein bestätigtes Produktupdate. Und genau so sollte man ihn auch behandeln.

Apple hat seine neue iPhone-Generation inzwischen offiziell vorgestellt. Die ersten Geräte befinden sich aber noch nicht regulär in den Händen der Käufer, und trotzdem tauchen bereits Benchmark-Einträge für den A20 Pro auf. Frühe Geekbench-7-Einträge werden einem iPhone 18 Pro und iPhone 18 Pro Max zugeschrieben. Genannt werden ungefähr 4.719 beziehungsweise 4.725 Punkte im Single-Core-Test und 12.677 beziehungsweise 12.575 Punkte im Multi-Core-Test. Der Sechskern-Prozessor soll dabei Taktfrequenzen von ungefähr 4,93 GHz erreichen. Gegenüber dem A19 Pro würden sich daraus grob 20 bis knapp 30 Prozent Vorsprung ergeben, je nachdem, welcher Vergleichswert herangezogen wird. Das sind beachtliche Zahlen. Sie sind aber noch kein belastbarer Test.

Öffentliche Benchmark-Datenbanken sind für LeakWatch wunderbar und für endgültige Aussagen gefährlich. Ein Eintrag kann echt sein. Er kann aber auch auf Vorserien-Firmware laufen, eine ungewöhnliche thermische Umgebung haben oder bewusst manipuliert worden sein. Selbst bei einem echten Gerät ist ein einzelner Durchlauf statistisch nahezu wertlos. Interessanter ist deshalb zunächst die Kombination aus Modellkennung, Kernausstattung und gemeldeter Taktrate. Knapp 5 GHz in einem Smartphone-SoC wären technisch bemerkenswert, aber aufgrund kurzer Boost-Zustände nicht mit einem dauerhaft mit 5 GHz laufenden Desktop-Prozessor gleichzusetzen. Wie schnell und effizient der A20 Pro tatsächlich ist, lässt sich erst beurteilen, wenn Seriengeräte unter kontrollierten Bedingungen getestet werden können. Bis dahin bleibt der Geekbench-Eintrag ein ziemlich plausibler, aber eben unbestätigter Vorabwert.

KW 37 ist eine dieser LeakWatch-Wochen, in denen das klassische Hardwaregerücht fast zur Erholung wird. Ob eine RTX 5070 irgendwann mit GB203 oder GB205 ausgeliefert wird, kann für Hardware-Enthusiasten interessant sein. Ob der A20 Pro tatsächlich knapp 5 GHz erreicht, wird sich spätestens mit den ersten Seriengeräten klären. Und dass DLSS-Modder eine einmal veröffentlichte Runtime auseinandernehmen, ist ungefähr so überraschend wie die Feststellung, dass Wasser nass ist. Die anderen Themen dieser Woche sind unangenehmer. Berlin muss inzwischen nicht mehr nur untersuchen, wie Angreifer in das Verwaltungsnetz kamen. Das Land muss damit umgehen, dass Daten außerhalb der eigenen Kontrolle liegen und Zugangsinformationen veröffentlicht wurden. Dieser Schaden lässt sich nicht mit einem Backup zurückspielen.

Microsoft schließt gleichzeitig fast tausend gemeldete Schwachstellen, zwei davon werden bereits praktisch ausgenutzt. SAP muss einen Fehler mit CVSS 10,0 korrigieren. Artifactory zeigt, wie schnell aus einem Repository ein Sprungbrett in eine Software-Lieferkette werden kann. Ein F5-Implantat versteckt sich im Arbeitsspeicher, und Mantax Otax demonstriert auf Android, dass Ransomware und Spyware inzwischen problemlos im selben Paket reisen können. Der vielleicht lehrreichste Fall ist trotzdem die offen erreichbare Fluggastdatenbank. Dafür brauchte es nach aktuellem Kenntnisstand keinen spektakulären Zero Day, keinen ausgefeilten Kernel-Exploit und möglicherweise überhaupt keinen Angreifer. Eine alternative Cloud-Adresse und Standardzugangsdaten reichten. Sicherheit scheitert eben nicht immer dort, wo die Technik besonders kompliziert ist. Manchmal scheitert sie an der Tür, von der niemand mehr wusste, dass sie noch existiert.

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.