Manchmal besteht eine LeakWatch-Woche aus einem unscharfen Foto eines Grafikkartenkartons, einer CPU-Zeile in irgendeiner Benchmark-Datenbank und einem Leaker, der mit drei Wörtern genügend Interpretationsspielraum für die nächsten vier Monate schafft. Kalenderwoche 38 ist nicht so eine Woche. Zwischen dem 14. und 20. September 2026 sind gleich mehrere Fälle aufgeschlagen, bei denen das Wort Leak sehr unterschiedliche Bedeutungen bekommt. Bei Gyazo wurden nach Unternehmensangaben rund 23,62 Millionen Benutzerdatensätze sowie ungefähr 490 Millionen Metadatensätze zu hochgeladenen Bildern unbefugt offengelegt. Beim Marketing- und Kommunikationsdienst Brevo reichte ein kompromittierter Cloudflare-Schlüssel aus, um Schadcode über legitime JavaScript-Dateien auf möglicherweise mehr als 100.000 Webseiten zu verteilen. Sicherheitsforscher veröffentlichten außerdem die Details einer Angriffskette, über die sie von einem Bild-Upload im OpenAI-Forum bis zu ChatGPT- und Codex-Konten von Mitarbeitern und schließlich zu einem internen Repository gelangten.

Cisco hat parallel eine bereits aktiv ausgenutzte Schwachstelle geschlossen, bei der ausgerechnet eine speziell präparierte E-Mail dazu führen kann, dass ein Secure Email Gateway Befehle mit Root-Rechten ausführt. Berlin arbeitet weiterhin den Datenabfluss aus dem Landesnetz auf und kann inzwischen konkreter beschreiben, woher ein wesentlicher Teil der veröffentlichten Daten stammt, ein vollständiges Lagebild existiert jedoch weiterhin nicht. Und dann wären da noch die klassischen Leaks. Bei Intel tauchen Z990-Mainboards in Transportdatenbanken, ein mutmaßliches Nova-Lake-Notebook in SiSoftware und gleichzeitig Gerüchte über gestrichene beziehungsweise verschobene Prozessorvarianten auf. AMD soll an einer eigenen Antwort auf neural gerendertes Licht nach Art von DLSS 5 arbeiten, wobei die dazu passenden Forschungsarbeiten ausgerechnet schon öffentlich bei AMD zu finden sind. Schließlich macht ein rund 192 GB großes Rockstar-Archiv die Runde, das zwar frisch im Rampenlicht steht, technisch aber aus dem Einbruch von 2022 stammen soll.

Die KW 38 zeigt damit ziemlich schön, dass ein Leak nicht unbedingt dort interessant wird, wo jemand die größte ZIP-Datei hochlädt. Manchmal genügt ein API-Key, ein zu großzügiger SSO-Token oder eine Metadatenbank, um erheblich mehr Schaden anzurichten.

Der vielleicht unterschätzteste Vorfall dieser Woche betrifft Gyazo. Der Dienst wird seit Jahren verwendet, um Screenshots, GIFs und kurze Bildschirmaufnahmen schnell hochzuladen und über einen Link zu teilen. Genau diese Einfachheit macht den Vorfall unangenehm, denn Screenshots sind häufig wesentlich informationsreicher, als ihre Besitzer im Moment des Uploads vermuten. Helpfeel, das Unternehmen hinter Gyazo, bestätigte am 16. September, dass ein Angreifer bereits am 11. September eine Schwachstelle im Image-Upload-Server ausgenutzt hatte und dadurch beliebige Befehle auf den betroffenen Systemen ausführen konnte. Noch am selben Abend wurde verdächtige Aktivität erkannt, bis zum frühen 12. September seien die identifizierten Zugriffswege blockiert und die unerlaubten Verbindungen beendet worden. Die anschließende Untersuchung zeigte jedoch, dass der Angreifer bereits Zugriff auf die Gyazo-Datenbank erhalten hatte.

Helpfeel beziffert den Umfang der offengelegten Benutzerinformationen derzeit auf ungefähr 23,62 Millionen Datensätze. Das entspricht ausdrücklich nicht zwingend 23,62 Millionen eindeutig identifizierbaren Personen, weil darunter beispielsweise auch anonyme Accounts ohne hinterlegte E-Mail-Adresse liegen. Zu den möglicherweise enthaltenen Informationen gehören Namen beziehungsweise frei gewählte Profiltexte, E-Mail-Adressen, Passwort-Hashes, Benutzer- und Geräte-IDs, Login-Session-IDs, Profilinformationen, Daten zur letzten Anmeldung, Tarif- und Abrechnungsstatus sowie in bestimmten Fällen Integrationstoken für X. Kreditkartendaten seien nach aktuellem Stand nicht abgeflossen.

Schon das wäre ein großer Vorfall. Interessanter wird es aber bei den Bildern. Helpfeel bestätigt zusätzlich die unbefugte Offenlegung von ungefähr 490 Millionen Metadatensätzen zu Bildern, die überwiegend bis Januar 2019 registriert wurden. Das entspricht nach Unternehmensangaben ungefähr 14,4 Prozent der gesamten bildbezogenen Daten. Hinzu kommen Metadaten zu etwa 2,4 Millionen Bildern, die über bestimmte Filterkriterien separat abgerufen wurden. Und hier sollte man den Begriff Metadaten nicht vorschnell mit harmlosen Dateieigenschaften gleichsetzen.

Zu den betroffenen Informationen gehören laut Helpfeel Bild-IDs, Quell-IP-Adressen der Uploads, User-Agent-Daten, eventuell vorhandene EXIF-Positionsinformationen, per OCR ausgelesener Text, Bildtitel, Quell-URLs sowie Passwort-Hashes geschützter Bilder. Besonders kritisch ist die Bild-ID, denn sie wird zur Konstruktion der jeweiligen Gyazo-URL verwendet. Damit entsteht ein Problem, das weit über eine gewöhnliche Liste kompromittierter E-Mail-Adressen hinausgeht. Wenn aus geleakten Metadaten die URL eines Bildes rekonstruiert werden kann und das Bild anschließend noch erreichbar ist, werden aus Metadaten praktisch wieder Inhalte. Helpfeel hat deshalb die Anzeige eines Teils der Bilder vorübergehend deaktiviert. Zusätzlich bestätigt das Unternehmen, dass der Angreifer eine Liste privater Bilder erhalten hat. Ob und in welchem Umfang solche privaten Bilder tatsächlich betrachtet wurden, ist derzeit nicht abschließend geklärt. Helpfeel kann einen entsprechenden Zugriff ausdrücklich nicht ausschließen.

Gerade bei einem Screenshot-Dienst ist das unangenehm. Auf Screenshots landen Terminalfenster, interne Dashboards, E-Mails, Fehlermeldungen, Chatverläufe, Bestellungen, Rechnungen, IP-Adressen, Kundendaten, API-Antworten und gelegentlich sogar Zugangsdaten. Viele davon wurden möglicherweise nur für einige Sekunden mit einem Kollegen geteilt und anschließend vergessen. Ein Screenshot altert außerdem anders als ein Passwort. Ein Kennwort lässt sich ändern. Eine vor Jahren abgebildete interne Architektur, eine E-Mail-Adresse oder eine persönliche Unterhaltung wird dadurch nicht wieder geheim. Deshalb dürfte die eigentliche Bewertung des Gyazo-Vorfalls noch einige Zeit dauern. Die Zahl von 23,62 Millionen Benutzerdatensätzen ist groß, die 490 Millionen Metadatensätze könnten langfristig jedoch mindestens ebenso interessant sein. Helpfeel betont, dass die getrennt betriebenen Dienste Helpfeel und Cosense nach bisherigem Ermittlungsstand nicht über denselben Angriffsweg kompromittiert wurden. Diese Aussage gilt ausdrücklich für den derzeitigen Stand der Untersuchung.

Der technisch interessanteste Angriff der Woche dürfte Brevo sein, weil er sehr schön demonstriert, warum eine saubere Datei auf dem eigenen Server nicht automatisch bedeutet, dass Besucher auch diese saubere Datei erhalten. Brevo bestätigte in einem ausführlichen Post-Mortem, dass ein Angreifer am 14. September einen kompromittierten Cloudflare-API-Key verwendete, um einen Cloudflare Worker im Account des Unternehmens anzulegen. Dieser Worker veränderte die ausgehenden Antworten am CDN-Edge und injizierte Schadcode in Seiten von Brevo sowie in drei JavaScript-Dateien, die Kunden in ihren eigenen Webseiten einbetten. Der Angriff war laut Brevo ungefähr fünfeinhalb Stunden aktiv. Das Unternehmen gibt das gesamte relevante Fenster mit 15:01 bis 20:30 Uhr UTC an, ab 16:07 Uhr wurde die Manipulation auch auf die eingebetteten JavaScript-Dateien und sibforms.com ausgeweitet. Betroffen waren unter anderem Teile von brevo.com, sendinblue.com, Brevo-Formulare, das Conversations-Widget und der SDK-Loader. Die eigentliche Brevo-Anwendung, die API und der E-Mail-Versand seien dagegen nicht betroffen gewesen.

Die Besonderheit steckt im Ort der Manipulation. Die Quelldateien auf den Brevo-Systemen wurden nicht verändert. Der Schadcode wurde auf dem Weg zum Nutzer am Cloudflare-Edge eingefügt. Ein Integritätscheck, der ausschließlich die Dateien auf dem Origin-Server untersucht, konnte deshalb problemlos melden, dass alles unverändert sei. Der Browser des Besuchers bekam trotzdem etwas anderes geliefert. Das ist die Sorte Problem, bei der sich jemand nach einer halben Nacht Fehlersuche irgendwann fragt, ob die Realität einen persönlich beleidigen möchte.

Der injizierte Code zeigte ausgewählten Besuchern eine gefälschte Cloudflare-Seite mit der Aufforderung, eine vermeintliche Verifikation durchzuführen. Dazu sollten Windows-Nutzer Win+R drücken, anschließend den Inhalt der Zwischenablage einfügen und ausführen. Diese als ClickFix bekannte Social-Engineering-Methode ist technisch ausgesprochen simpel und psychologisch erstaunlich wirksam. Der Schadcode legt den eigentlichen Befehl in die Zwischenablage, die Webseite erklärt anschließend dem Opfer Schritt für Schritt, wie dieser auszuführen ist. Damit umgeht der Angriff einen Teil der klassischen Browser-Sicherheitsgrenzen, denn am Ende startet nicht die Webseite direkt das Programm, sondern der Benutzer selbst. Auf WordPress-Webseiten mit eingebettetem Brevo-Code ging der Angriff noch einen Schritt weiter. War der Besucher gleichzeitig als Administrator angemeldet, versuchte das Skript laut Brevo automatisch, ein WordPress-Plugin zu installieren und zu aktivieren. Die Sicherheitsfirma Sansec kommt anhand der Verbreitung der betroffenen Brevo-Skripte zu dem Schluss, dass mehr als 100.000 Webseiten während des Angriffsfeldes potenziell schädlichen Code ausgeliefert haben könnten. Diese Zahl stammt nicht aus Brevos Post-Mortem, sondern aus der Analyse von Sansec und sollte deshalb genau so eingeordnet werden.

Brevo benennt die Ursache ungewöhnlich konkret: Ein langlebiger Cloudflare-API-Key mit weitreichenden Account-Rechten war im Quellcode einer Anwendung gespeichert und wurde vom Angreifer erlangt. Mit diesem Schlüssel konnten neue Workers, Routen und DNS-Einträge angelegt werden, ohne dass eine entsprechende Änderung einen Alarm auslöste. Der Angreifer konnte außerdem Sicherheitsheader wie die Content-Security-Policy aus den über den Worker ausgelieferten Antworten entfernen. Das ist ein fast schon lehrbuchartiges Beispiel für ein Secret, das technisch funktioniert und organisatorisch trotzdem falsch behandelt wurde. Brevo hat den Schlüssel inzwischen widerrufen und nach eigenen Angaben auf kurzlebige, enger eingeschränkte Tokens umgestellt. Künftig sollen Cloudflare-Zugangsdaten zentral über HashiCorp Vault verwaltet und automatisch rotiert werden. Änderungen an Workers, DNS, Routen und Kontozugängen sollen zusätzlich in das Security-Monitoring einfließen.

Interessant ist auch die Vorgeschichte. Bereits am 10. September hatte Brevo einen separaten Vorfall bekannt gegeben, bei dem eine fehlerhafte Abgrenzung in der SAML-SSO-Implementierung den Zugriff auf 138 Kundenkonten ermöglichte. Bei sechs Accounts wurden Phishing-Mails versendet, aus 43 Accounts Kontakte exportiert. Brevo beschreibt diesen Vorfall getrennt vom späteren ClickFix-Angriff. Zwei unterschiedliche Sicherheitsprobleme innerhalb weniger Tage sind kein Beweis für einen gemeinsamen Ursprung. Sie machen die Woche für Brevo aber nicht angenehmer.

Ein weiterer bemerkenswerter Fall wurde in dieser Woche öffentlich, obwohl der eigentliche Zugriff bereits Ende Juli stattgefunden hatte. Das Sicherheitsteam Hacktron beschreibt eine Angriffskette, mit der es am 25. Juli zunächst Codeausführung auf dem bei OpenAI eingesetzten Discourse-Forum erreichte, anschließend eine Schwäche im OpenAI-SSO ausnutzte und dadurch Zugriff auf ChatGPT- und Codex-Konten mehrerer Mitarbeiter demonstrieren konnte. Über eine an Codex gekoppelte GitHub-Integration wurde schließlich ein harmloser Pull Request in einem internen OpenAI-Repository erzeugt. Wichtig ist die Einordnung: Das war kein krimineller Einbruch mit anschließendem Datendiebstahl, sondern verantwortete Sicherheitsforschung. Die Forscher meldeten die Schwachstellen an OpenAI und Discourse, stoppten die weitere Untersuchung nach dem Proof of Concept und erhielten für die OpenAI-seitige Schwachstelle später eine Bug-Bounty-Prämie von 6.500 US-Dollar.

Technisch ist die Kette trotzdem bemerkenswert. Die Eintrittsstelle war die Bildverarbeitung des Discourse-Forums. HEIC- und HEIF-Bilder durchliefen einen Pfad über ImageMagick und eine verwundbare libheif-Version. Die Forscher entwickelten daraus einen funktionierenden Heap-Overflow-Exploit und erreichten Remote Code Execution. Anschließend zeigte sich, dass die für die Anmeldung im OpenAI-Community-Forum ausgegebenen Sign-in-Tokens zu weitreichende Rechte besaßen. Damit wurde aus einer Schwachstelle in einer Bildbibliothek plötzlich ein Identity-Problem. Dieser Punkt ist wichtiger als die Frage, welche Bilddatei den Heap Overflow auslösen konnte.

Die Forumskompromittierung allein hätte zunächst den Discourse-Dienst betroffen. Erst die zu großzügigen Berechtigungen der OpenAI-Anmeldetokens ermöglichten die Bewegung von dort in ChatGPT- und Codex-Konten. Hacktron demonstrierte anschließend den Zugriff auf das Konto eines OpenAI-Mitarbeiters, dessen Codex-Umgebung mit der GitHub-Organisation von OpenAI verbunden war. Die Forscher ließen darüber einen Pull Request in einem internen Monorepository erzeugen, ohne nach eigener Darstellung den eigentlichen Quellcode auszulesen. OpenAI teilte SecurityWeek mit, dass die eigene Untersuchung begrenzte Zugriffe auf Metadaten und Commits privater Repositories sowie den von den Forschern angelegten README-Pull-Request festgestellt habe. Einen verifizierten Zugriff der Forscher auf Slack-Nachrichten bestätigte OpenAI dagegen nicht. Das Unternehmen erklärte außerdem, die Berechtigungen der Community-Sign-in-Tokens eingeschränkt und betroffene Tokens sowie Sitzungen widerrufen zu haben.

Nach Angaben Hacktrons bestätigte OpenAI die Behebung des eigenen SSO-Problems ungefähr 14 Stunden nach der Meldung. Discourse hatte für seinen Teil der Kette innerhalb von zwei Tagen eine Korrektur vorbereitet und ergänzte zusätzlich eine Sandbox für die Bildverarbeitung. Zusätzliche Aufmerksamkeit bekommt der Fall dadurch, dass Hacktron mehrere Claude-Modelle zur Exploit-Entwicklung verwendete. Nach Darstellung der Forscher scheiterte Claude Opus 4.8 zunächst daran, einen unter ASLR zuverlässig funktionierenden Exploit zu erzeugen. Mit Opus 5 gelang später ein funktionsfähiger ARM64-Exploit und anschließend die Portierung auf die von Discourse verwendete x86-64-Umgebung. Das sollte weder als vollständig autonomer Cyberangriff noch als Beweis dafür verstanden werden, dass ein Sprachmodell künftig auf Knopfdruck jede beliebige Infrastruktur übernimmt. Hacktron betont selbst, dass erfahrene menschliche Führung weiterhin wichtig war.

Was sich verändert, ist der Aufwand. Exploitentwicklung, Portierung zwischen Plattformen, Analyse von Bibliotheken und Anpassung an unbekannte Zielumgebungen können durch solche Werkzeuge deutlich schneller werden. Genau dort liegt die langfristige Bedeutung des Falls. Die frühere Schutzwirkung von Komplexität wird schwächer. Ein Bug, dessen Ausnutzung früher einen Spezialisten mehrere Wochen beschäftigt hätte, muss dadurch nicht plötzlich trivial werden. Die Kosten dafür können aber sinken.

Cisco liefert in derselben Woche ein wesentlich klassischeres, dafür unmittelbar aktiv ausgenutztes Sicherheitsproblem. CVE-2026-76461 betrifft die E-Mail-Verarbeitung von AsyncOS auf Cisco Secure Email Gateway. Ein nicht authentifizierter Angreifer kann eine präparierte E-Mail mit manipulierten SQL-Anweisungen an ein betroffenes Gerät senden. Bei erfolgreicher Ausnutzung kann daraus die Ausführung beliebiger Befehle mit Root-Rechten auf dem zugrunde liegenden Betriebssystem entstehen. Cisco bewertet die Schwachstelle mit CVSS 9,8. Das ist ausgerechnet bei einem Secure Email Gateway eine ausgesprochen unangenehme Kombination.

Der Dienst muss eingehende E-Mails aus nicht vertrauenswürdigen Quellen annehmen, weil genau das seine Aufgabe ist. Ein Angreifer benötigt für diese Schwachstelle laut Cisco weder Zugangsdaten noch eine vorherige authentifizierte Sitzung. Die speziell präparierte E-Mail selbst bildet den Angriffsvektor. Cisco bestätigt außerdem, dass die Schwachstelle bereits praktisch ausgenutzt wurde. Einen Workaround gibt es nicht, die Abhilfe besteht im Update auf eine korrigierte AsyncOS-Version. Parallel veröffentlichte Cisco weitere Hardening-Updates für Secure Email Gateway und Secure Email and Web Manager. Bei einem Gateway mit Root-Kompromittierung ist außerdem nicht nur das Gerät selbst relevant. Ein solcher Server sieht Mailverkehr, kann Anmeldedaten und interne Strukturen beobachten und steht an einem strategisch sehr günstigen Punkt zwischen Internet und Unternehmensnetz.

Auch der Berliner Verwaltungsangriff bleibt in KW 38 relevant, diesmal allerdings nicht wegen eines weiteren bestätigten Einbruchs. Die zentrale Informationsseite des Landes wurde am 14. September aktualisiert, die Senatsverwaltung für Mobilität, Verkehr, Klimaschutz und Umwelt veröffentlichte am 15. September zusätzliche Informationen für betroffene Bürger. Berlin bestätigt weiterhin, dass die Täter Daten aus dem Landesnetz kopiert und am 4. September im Darknet veröffentlicht haben. Der wesentliche Abfluss soll nach aktuellem Erkenntnisstand zwischen dem 7. und 12. August erfolgt sein. Neu beziehungsweise inzwischen deutlicher formuliert ist die Art des Materials.

Nach Angaben des Landes handelt es sich überwiegend um unstrukturierte Daten aus gemeinsam genutzten und persönlichen Verzeichnissen von Beschäftigten der betroffenen Behörden und nicht primär um vollständige Exporte bestimmter Fachverfahren. Darin können trotzdem personenbezogene Daten von Beschäftigten, Bürgern und Unternehmen enthalten sein. Das macht den Fall nicht kleiner, sondern nur schwieriger auszuwerten. Eine strukturierte Datenbank besitzt Felder, Tabellen und bekannte Beziehungen. Ein Verzeichnis mit Dokumenten, Tabellen, PDFs, E-Mails und Arbeitskopien muss dagegen Datei für Datei klassifiziert werden. Erst dann lässt sich feststellen, welche Person mit welchem Datentyp betroffen ist und welches daraus entstehende Risiko vorliegt. Berlin erklärt deshalb weiterhin, dass eine abschließende Analyse Zeit benötigt und betroffene Personen beziehungsweise Gruppen risikobasiert informiert werden sollen, sobald genügend gesicherte Erkenntnisse vorliegen. Der Angriff selbst ist damit kein neues KW-38-Ereignis mehr. Die Phase danach ist es sehr wohl. Und diese Phase kann für Betroffene erheblich länger dauern als die technische Wiederherstellung eines Servers.

Zur Erholung darf es nun wieder um Silizium gehen. Bei Intel wird die Informationslage rund um Nova Lake inzwischen derart dicht, dass nicht mehr jede einzelne Meldung für sich besonders spektakulär wirkt. Zusammengenommen ergibt sich jedoch ein zunehmend konkretes Bild der nächsten Plattform. Am 17. September tauchten in Transport- beziehungsweise Zolldaten mehrere ASRock-Mainboards mit dem bislang nicht offiziell vorgestellten Z990-Chipsatz auf. Genannt werden unter anderem Modelle aus den Reihen Challenger, Pro RS, Steel Legend und Taichi. Die Datensätze sollen bereits im Juli verschickte montierte Mainboards beziehungsweise PCBs aus Taiwan und Vietnam zeigen. Das beweist noch keine laufende Serienproduktion, spricht aber zumindest dafür, dass entsprechende Designs physisch in Validierung oder Vorserienphase existieren.

Intel hat LGA1954 als Sockel für Nova Lake bereits anderweitig bestätigt, Z990 selbst jedoch noch nicht offiziell detailliert. Deshalb bleibt die Verbindung zwischen den aufgetauchten Boards und den finalen Retail-Produkten formal ein Leak. Am selben Tag tauchte außerdem ein bislang unveröffentlichtes HP EliteBook X G3i in der SiSoftware-Datenbank auf. Das System verwendet einen unbekannten Intel-Prozessor mit der generischen Kennung „Genuine Intel 0000“. Gemeldet werden 20 Kerne, bis zu 4,6 GHz und 18 MB L3-Cache. Die Plattform wird gleichzeitig als virtualisiert erkannt und besitzt eine ungewöhnliche Topologie, weshalb die gemeldeten Einzelwerte mit Vorsicht behandelt werden müssen. Interessant ist vor allem der Produktname. Das aktuelle EliteBook X G2i basiert auf Panther Lake. Ein G3i würde logisch in die nachfolgende Generation passen, und die gemeldeten 4-MB-L2-Blöcke würden zu bisherigen Berichten über die Coyote-Cove-Konfiguration von Nova Lake passen.

Weniger erfreulich für Freunde leistungsfähiger integrierter Grafik ist ein weiteres Gerücht dieser Woche. Der Leaker Jaykihn behauptet, Intel habe die geplante Nova-Lake-S-Variante mit zwölf Xe3P-Grafikkernen gestrichen beziehungsweise in die nachfolgende Razor-Lake-S-Generation verschoben. Die bislang kolportierte Nova-Lake-Konfiguration kombinierte vier P-Cores, acht E-Cores und vier Low-Power-E-Cores mit einer ungewöhnlich großen integrierten GPU aus zwölf Xe3P-Kernen. Für Desktop-Systeme wäre das interessant gewesen, weil Intel damit eine Klasse adressiert hätte, die bislang eher AMD mit seinen größeren APUs besetzt. Nach dem aktuellen Gerücht soll genau dieses Produkt nun nicht unter Nova Lake erscheinen. Mobile Nova-Lake-Varianten mit großer Grafik sind davon nicht zwangsläufig betroffen.

Intel selbst hat weder die ursprüngliche 12-Xe-Desktop-Konfiguration noch ihre angebliche Verschiebung offiziell bestätigt. Der Informationsstand gehört daher klar in die Gerüchtekategorie. Die Kombination aus realen Transportdaten, Benchmark-Datenbanken und klassischen Leaker-Aussagen ist trotzdem interessant, weil die Beweisqualität sehr unterschiedlich ist. Ein Mainboard in einer Zoll- oder Versanddatenbank ist etwas anderes als ein Satz auf X. Beides kann am Ende stimmen, sollte aber nicht mit derselben Sicherheit formuliert werden.

Fast schon amüsant ist ein weiteres Intel-Gerücht: Jaykihn zufolge soll Intel eine neue Raptor-Lake-Next-CPU als Ersatz für den Core i5-14600K vorbereiten. Statt sechs Performance- und acht Efficiency-Cores des bisherigen 14600K soll das neue Modell acht P-Cores und acht E-Cores besitzen, also insgesamt 16 Kerne und 24 Threads. Die Leistungsaufnahme wird erneut mit einer 125-Watt-Klasse in Verbindung gebracht. Intel hat dieses Modell nicht offiziell angekündigt. Sollte der Bericht stimmen, wäre es dennoch bemerkenswert, wie langlebig Raptor Lake geworden ist. Während parallel Nova Lake mit neuem Sockel, neuen Mainboards und neuen Kernarchitekturen vorbereitet wird, könnte Intel am anderen Ende des Marktes weiterhin Silizium aus der LGA1700-Ära neu sortieren. Aus Herstellersicht wäre das nicht irrational. Ein etablierter Prozess, vorhandene Dies und eine riesige installierte Plattformbasis lassen sich wirtschaftlich noch lange nutzen, solange der Markt entsprechende Produkte abnimmt. Der Name einer Architektur ist schließlich kein Mindesthaltbarkeitsdatum.

AMD taucht diese Woche weniger durch konkrete Hardware als durch ein interessantes Zusammenspiel aus Gerücht und öffentlich sichtbarer Forschung auf. Kepler_L2 behauptet, AMD werde auf einer kommenden GPU-Generation eine eigene Form von „Neural Lighting“ anbieten, die konzeptionell in Richtung von NVIDIAs DLSS 5 geht. Dabei soll klassische Shaderarbeit teilweise durch neuronale Modelle ersetzt werden. Ob diese Technik tatsächlich nur auf RDNA 5 verfügbar wäre, ist nicht bestätigt. Kepler hält dies aufgrund der Rechenlast für wahrscheinlich. Diese konkrete Produktbehauptung ist ein Leak beziehungsweise Gerücht. Die zugrunde liegende Forschungsrichtung ist dagegen real und öffentlich. AMD hat am 9. September auf GPUOpen eine Arbeit über zeitlich stabiles generatives Global Illumination mit einem einstufigen Diffusionsmodell veröffentlicht. Das Modell verwendet unter anderem direkte Beleuchtung, Geometrie, Normalen, Materialien, Lighting-Hinweise und Bewegungsvektoren, um indirekte Beleuchtung zu generieren und über mehrere Frames stabil zu halten.

Bereits im August veröffentlichte AMD außerdem ein leichtgewichtiges Attention-Modell für indirekte Beleuchtung, das G-Buffer-Daten mit Reflective Shadow Maps kombiniert und dadurch Informationen über Geometrie außerhalb des aktuellen Bildausschnitts berücksichtigen kann. Das ist noch kein Beweis dafür, dass ein kommendes Radeon-Produkt exakt diese Modelle verwendet. Es zeigt aber, dass die behauptete Entwicklungsrichtung technisch keineswegs aus dem Nichts kommt.

Der zweite große GPU-Rumor dieser Woche betrifft nicht Funktionen, sondern den Kalender. Kepler_L2 zufolge könnte AMD 2027 lediglich eine einzelne neue AT2-GPU veröffentlichen, während ein größerer Teil der RDNA-5-Familie sowie NVIDIAs nächste GeForce-Generation auf Rubin-Basis erst 2028 erscheinen soll. NVIDIA und AMD haben einen solchen Consumer-Zeitplan nicht bestätigt. Gerade bei Roadmaps über mehr als ein Jahr sollte man hier vorsichtig bleiben. Produktpläne hängen an Foundry-Kapazitäten, Speicherpreisen, Packaging, Konkurrenzprodukten, Lagerbeständen und nicht zuletzt daran, wie gut sich die aktuelle Generation verkauft. Ein interner Zieltermin kann stimmen und trotzdem sechs Monate später wertlos sein. Interessant ist der Bericht dennoch, weil er zu der auffällig langen Lebensdauer der aktuellen GPU-Generation passen würde. Ob daraus tatsächlich eine zweijährige Durststrecke bis zu einer breiten neuen GeForce- beziehungsweise Radeon-Generation wird, lässt sich daraus noch nicht ableiten. Das ist einer jener Leaks, die man abheftet und in einem Jahr wieder hervorholt. Entweder mit „war erstaunlich präzise“ oder mit „nun ja“.

Zum Abschluss gibt es einen Leak in der klassischen Bedeutung, nur mit einem wichtigen Haken. Seit dem 18. September verbreitet sich ein ungefähr 192 GB großes Rockstar-Entwicklungsarchiv. Darin befinden sich laut RockstarIntel und weiteren Auswertungen GTA-V-Quellmaterial, Entwicklungswerkzeuge, Debug-Builds, verworfene Inhalte sowie frühe Assets, die GTA VI zugeschrieben werden. Das klingt zunächst nach einem neuen großen Rockstar-Einbruch. Genau das soll es aber nicht sein. Die Dateien werden dem bereits bekannten Angriff aus dem Jahr 2022 zugerechnet und sollen innerhalb bestimmter Kreise schon länger kursiert haben. VideoCardz berichtet sogar, dass das vollständige Archiv bereits 2025 auf einem Discord-Server geteilt worden sein soll, dort aber weitgehend unbeachtet blieb. Neu ist also vor allem die breite öffentliche Verbreitung und Analyse.

Unter den Dateien befinden sich offenbar sehr frühe GTA-VI-Blockouts. Metadaten einzelner Map-Dateien sollen bis 2015 zurückreichen. Solche Daten sind für die Entwicklungsgeschichte interessant, aber ungeeignet, um daraus aktuelle Aussagen über die finale Spielwelt abzuleiten. Zwischen einem Blockout von 2015 und einem Produkt von 2026 liegen elf Jahre Entwicklung. Wesentlich umfangreicher scheint der GTA-V-Anteil zu sein. Gefunden wurden unter anderem Hinweise auf gestrichene Einzelspieler-Inhalte, Material zum nie veröffentlichten Liberty-City-Projekt, verworfene Missionen, Fahrzeuge, Dialoge und Inhalte des geplanten Agent-Trevor-DLC. Auch hier gilt allerdings dieselbe Regel wie bei jedem großen Datenarchiv aus inoffizieller Quelle. Einzelne Dateien können authentisch sein, ohne dass jede Interpretation der Community ebenfalls stimmt.

Der Rockstar-Fall zeigt außerdem einen interessanten Unterschied zwischen Zeitpunkt des Diebstahls und Zeitpunkt der tatsächlichen Wirkung. Daten können jahrelang in kleinen Gruppen kursieren und erst später eine große Öffentlichkeit erreichen. Aus Sicht des betroffenen Unternehmens ist der ursprüngliche Sicherheitsvorfall alt. Aus Sicht von Entwicklern, Rechteinhabern und betroffenen Mitarbeitern kann der Schaden trotzdem gerade erst beginnen, wenn Millionen Menschen plötzlich Zugriff auf die Inhalte erhalten. Dasselbe Grundprinzip gilt auch für personenbezogene Daten. Ein Datenabfluss ist nicht erledigt, nur weil der ursprüngliche Angreifer längst aus dem Netz entfernt wurde. Kopien können später erneut auftauchen, mit anderen Datensätzen zusammengeführt oder für völlig neue Angriffskampagnen verwendet werden. Daten besitzen keine Rückruffunktion.

KW 38 hat zwar genug klassische Hardwaregerüchte geliefert, der gemeinsame Nenner der wirklich interessanten Fälle liegt aber woanders. Bei Gyazo wurde Vertrauen in private beziehungsweise kaum beachtete Screenshots zum Problem. Bei Brevo war es das Vertrauen von Webseiten in extern eingebettetes JavaScript. Beim OpenAI-Fall war es die Vertrauenskette vom Forum über SSO bis zu Codex und GitHub. Beim Cisco Secure Email Gateway ist ausgerechnet das System angreifbar, das schädliche E-Mails abfangen soll. Und Berlin arbeitet weiterhin Daten aus Verzeichnissen auf, die intern deshalb nutzbar waren, weil Mitarbeiter darauf vertrauen mussten, dass diese Dateien innerhalb der Verwaltung bleiben. Das eigentliche Sicherheitsproblem besteht daher selten nur aus einer einzelnen Schwachstelle. Es entsteht dort, wo ein kompromittierter Bestandteil mehr darf, als er für seine eigentliche Aufgabe benötigen würde.

Der Brevo-Fall ist dafür fast das perfekte Beispiel. Ein Cloudflare-Schlüssel war mächtig genug, um am Edge Inhalte zu verändern, DNS zu kontrollieren und Sicherheitsheader zu entfernen. Die Dateien auf dem eigentlichen Server blieben unangetastet und konnten gleichzeitig vollkommen sauber aussehen. Beim OpenAI-Fall war es ähnlich. Eine Bildbibliothek in einem Forum hätte niemals Zugriff auf interne Repositories haben sollen. Sie hatte ihn auch nicht direkt. Erst die Kombination aus Forum, zu weitreichendem SSO, Mitarbeiterkonto, Codex und GitHub machte die vollständige Kette möglich. Genau das ist die Sorte Angriff, gegen die einfache Checklisten zunehmend schlecht funktionieren.

Und dann sitzt Intel daneben, verschickt vermutlich schon Z990-Boards durch die Weltgeschichte, während noch diskutiert wird, welche Nova-Lake-Version überhaupt gestrichen wurde. Wenigstens auf Hardware-Leaks ist noch Verlass.

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.