Ein proprietärer Kernel-Treiber, der eigentlich Cheater aus Online-Spielen fernhalten soll, öffnet stattdessen die Tür für Angreifer bis auf SYSTEM-Ebene. Das US-amerikanische CERT Coordination Center (CERT/CC) hat am 2. Juli 2026 unter der Kennung VU#639124 gleich drei Sicherheitslücken im Anti-Cheat-Treiber GFAC_Sys_x64.sys von Little Orbit offengelegt, dem Unternehmen hinter der GamersFirst-Anti-Cheat-Technik (GFAC). Besonders brisant: Der Hersteller hat bis heute nicht reagiert, ein Proof-of-Concept-Code liegt bereits öffentlich auf GitHub, und Millionen Spieler weltweit installieren solche Kernel-Treiber, ohne genau zu wissen, welche Rechte sie damit einem fremden Unternehmen auf dem eigenen PC einräumen.
Für die DACH-Region ist der Fall mehr als eine Randnotiz aus der IT-Sicherheitsszene. Kernel-Level-Anti-Cheat ist seit Jahren fester Bestandteil großer Online-Titel, von Shootern bis zu MMOs, und läuft mit den höchsten Rechten, die ein Windows-System überhaupt vergibt. Wenn ein solcher Treiber verwundbar ist, betrifft das nicht nur Gaming-PCs, sondern potenziell jedes System, auf dem das betroffene Spiel installiert wurde. Dieser Artikel ordnet die drei neuen CVEs ein, vergleicht GFAC mit etablierten Anti-Cheat-Systemen wie Vanguard, EasyAntiCheat und Javelin, und zeigt, warum Kernel-Treiber in Spielen seit Jahren ein wiederkehrendes Sicherheitsproblem sind.
Was ist GFAC und wer steckt hinter Little Orbit?
GamersFirst Anti-Cheat, kurz GFAC, ist eine proprietäre Anti-Cheat-Lösung, die ursprünglich unter der Marke GamersFirst für Free-to-Play-Titel entwickelt wurde und mittlerweile vom Publisher Little Orbit weitergeführt wird. Wie die meisten modernen Anti-Cheat-Systeme setzt GFAC nicht nur auf Software, die im normalen Nutzerkontext läuft, sondern installiert einen Kernel-Mode-Treiber mit der Bezeichnung GFAC_Sys_x64.sys. Dieser Treiber läuft mit den höchsten Rechten des Betriebssystems und kann so tief in Windows-Prozesse hineinschauen, dass er Cheat-Software erkennen soll, bevor sie überhaupt aktiv wird.
Genau diese Tiefe ist aber auch das Problem. Ein Kernel-Treiber, der mit SYSTEM-Rechten arbeitet, muss jede einzelne Anfrage, die von einem gewöhnlichen Benutzerprozess kommt, strikt validieren. Tut er das nicht, verwandelt sich ein Schutzmechanismus in ein Einstiegstor für genau die Angriffe, die er verhindern sollte. Laut der CERT/CC-Beschreibung liegt exakt dieses Muster bei GFAC vor: Der Treiber verarbeitet Nachrichten über eine sogenannte Minifilter-Kommunikationsschnittstelle, ohne die Eingaben aus dem Benutzerkontext ausreichend zu prüfen.
Die drei CVEs im Detail: CVE-2026-12166, -12167 und -12168
CERT/CC hat die Schwachstellen in drei separate CVE-Einträge aufgeteilt, die jeweils einen eigenen Angriffspfad beschreiben, sich in der Praxis aber gegenseitig verstärken können. Die Entdeckung wird Lucian Alexandru Necula zugeschrieben, verfasst wurde die Vulnerability Note von Michael Bragg bei CERT/CC. Little Orbit wurde laut Angabe von CERT/CC am 14. Mai 2026 kontaktiert, reagierte aber nicht, weshalb die Lücken am 2. Juli 2026 ohne koordinierte Herstellerantwort veröffentlicht wurden.
CVE-2026-12166 beschreibt eine NULL-Pointer-Dereferenz in der Initialisierungs- und Anfragenverarbeitung des Treibers. Ein lokaler Angreifer kann den fehlerhaften Codepfad auslösen, sodass der Treiber auf eine als NULL zugewiesene Speicheradresse liest oder schreibt. Das Ergebnis ist in der Regel ein klassischer Systemabsturz, bekannt als Blue Screen of Death. Für sich allein ist das vor allem ein Denial-of-Service-Problem, aber in Kombination mit den beiden anderen Lücken wird es gefährlicher.
CVE-2026-12167 betrifft die Zugriffskontrolle der Minifilter-Kommunikationsschnittstelle selbst. Die Sicherheitsdeskriptoren, die eigentlich regeln sollen, wer mit dem Treiber kommunizieren darf, sind nicht restriktiv genug gesetzt. Dadurch können Prozesse mit niedrigen lokalen Rechten überhaupt erst eine Verbindung zu Funktionen aufbauen, die normalerweise nur vertrauenswürdigen, privilegierten Prozessen vorbehalten sein sollten. Diese Lücke ist technisch gesehen die Eingangstür, durch die die eigentlich kritische dritte Schwachstelle erst erreichbar wird.
CVE-2026-12168 ist die schwerwiegendste der drei Lücken. Der Treiber validiert vom Benutzer übergebene Speicheradressen nicht ausreichend, bevor er Schreiboperationen durchführt. Ein Angreifer kann eine manipulierte Anfrage mit einer Zieladresse und einem Datenwert übermitteln und den Treiber so dazu bringen, beliebige Daten an eine beliebige Stelle im Kernel-Speicher zu schreiben. Dieses sogenannte Write-what-where-Muster lässt sich gezielt nutzen, um sensible Betriebssystemstrukturen zu manipulieren, etwa Prozess-Sicherheitstoken. Das Ergebnis: eine vollständige Rechteausweitung auf SYSTEM-Ebene, also die höchste lokale Berechtigungsstufe unter Windows.
| CVE-Kennung | Art der Schwachstelle | Direkte Folge | Voraussetzung |
|---|---|---|---|
| CVE-2026-12166 | NULL-Pointer-Dereferenz bei Initialisierung | Systemabsturz (Blue Screen of Death) | Lokaler Zugriff, GFAC installiert |
| CVE-2026-12167 | Zu schwache Sicherheitsdeskriptoren am Kommunikationsport | Niedrig privilegierte Prozesse erhalten Zugriff auf geschützte Funktionen | Lokaler Zugriff, GFAC installiert |
| CVE-2026-12168 | Fehlende Validierung von Speicheradressen (Write-what-where) | Beliebiger Kernel-Schreibzugriff, Rechteausweitung auf SYSTEM | Lokaler Zugriff, meist in Kombination mit CVE-2026-12167 |
Wie ein Angreifer tatsächlich SYSTEM-Rechte erlangt
Der eigentliche Angriffspfad ist nüchtern betrachtet keine exotische Zero-Click-Attacke aus dem Internet, sondern eine lokale Rechteausweitung. Das bedeutet: Ein Angreifer braucht zunächst irgendeine Form von Zugriff auf das Zielsystem, etwa über ein kompromittiertes Benutzerkonto, einen bereits eingeschleusten Schadcode mit eingeschränkten Rechten, oder physischen Zugriff auf einen gemeinsam genutzten Rechner. Von dort aus wird GFAC zum Hebel, mit dem aus einem eingeschränkten Konto ein Administratorkonto wird.
Praktisch läuft das laut CERT/CC in zwei Schritten ab. Zuerst nutzt der Angreifer die laxen Zugriffsrechte aus CVE-2026-12167, um überhaupt eine Verbindung zur privilegierten Kommunikationsschnittstelle des Treibers aufzubauen, die eigentlich verschlossen sein sollte. Danach missbraucht er die fehlende Adressvalidierung aus CVE-2026-12168, um gezielt Daten in den Kernel-Speicher zu schreiben und damit das Sicherheitstoken seines eigenen Prozesses zu manipulieren. Windows vertraut diesem Token blind, sobald es im Kernel-Speicher als gültig markiert ist, wodurch der Prozess faktisch zu SYSTEM aufsteigt. Genau dieses Muster, bei dem ein scheinbar harmloser Treiber-Fehler zu vollständiger Systemkontrolle führt, ist auch der Grund, warum Sicherheitsforscher seit Jahren fordern, dass Treiber mit Kernel-Rechten besonders streng geprüft werden, etwa im Rahmen von automatisierten Schwachstellen-Scans vor der Veröffentlichung.
Warum Little Orbit schweigt und was das für Patches bedeutet
Ein zentrales Detail der CERT/CC-Meldung ist, dass die koordinierte Offenlegung in diesem Fall nicht funktioniert hat. In der offiziellen Vulnerability Note heißt es wörtlich auf Englisch, man habe den Hersteller nicht erreichen können, um die Lücken koordiniert zu melden. Das bedeutet in der Praxis: Es existiert zum Zeitpunkt der Veröffentlichung kein offizieller Patch, keine Zeitangabe für ein Update und keine öffentliche Stellungnahme von Little Orbit. CERT/CC rät deshalb zu einer eher ungewöhnlich drastischen Übergangsmaßnahme, nämlich betroffene Spiele, die auf GFAC setzen, vorübergehend zu deinstallieren oder gar nicht erst zu installieren, bis eine Korrektur vorliegt.
Diese Schweigepraxis ist kein Einzelfall in der Spielebranche, aber bei einem Treiber mit Kernel-Rechten wiegt sie deutlich schwerer als bei einer gewöhnlichen Applikationslücke. Während große Anti-Cheat-Anbieter wie Riot Games mit Vanguard oder Epic Games mit Easy Anti-Cheat eigene Security-Teams und öffentliche Bug-Bounty-Programme unterhalten, wirkt GFAC wie ein Nebenprodukt eines kleineren Publishers, das seit Jahren kaum aktiv weiterentwickelt wird. Für Spieler bedeutet das konkret: Ein Sicherheitsproblem in einem Nischen-Anti-Cheat kann genauso lange offen bleiben wie es der Hersteller eben zulässt, denn ohne Antwort gibt es auch keinen verbindlichen Zeitplan für einen Fix.
Öffentlicher Exploit-Code verschärft die Dringlichkeit
Zusätzlich brisant ist, dass zu allen drei CVE-Nummern bereits Proof-of-Concept-Code öffentlich auf GitHub verfügbar ist. Für Sicherheitsforscher ist das üblich und Teil der verantwortungsvollen Offenlegung, sobald ein Hersteller über Wochen hinweg nicht reagiert. Für die Angriffsfläche in freier Wildbahn bedeutet es aber auch, dass die Hürde, diese Lücken tatsächlich auszunutzen, erheblich sinkt. Wer Windows-Kernel-Programmierung beherrscht, muss die Schwachstelle nicht mehr selbst finden, sondern kann auf bereits dokumentierten Code zurückgreifen.
Dieses Muster, offener Exploit-Code plus untätiger Hersteller, ist in der Sicherheitsbranche ein bekannter Beschleuniger für reale Angriffe. Es erinnert an Fälle, in denen verwundbare, aber weit verbreitete Treiber von Kriminellen gezielt als sogenannte Bring-your-own-vulnerable-driver-Werkzeuge missbraucht wurden, um Endpoint-Schutzsoftware zu umgehen oder Ransomware mit erhöhten Rechten auszuführen. Genau dieses Risiko, dass ein eigentlich spielbezogener Treiber zweckentfremdet wird, macht aus einer Nischen-Anti-Cheat-Lücke ein Thema, das auch IT-Sicherheitsteams in Unternehmen beachten sollten, sobald Mitarbeitende Firmengeräte auch privat zum Spielen nutzen.
Historischer Kontext: Anti-Cheat-Treiber als wiederkehrendes Sicherheitsrisiko
GFAC ist bei Weitem nicht der erste Kernel-Treiber aus der Gaming-Branche, der zum Sicherheitsproblem wurde. Die Diskussion um invasive Anti-Cheat-Software reicht Jahre zurück, von Capcoms umstrittenem Treiber in Resident Evil-Titeln, der 2020 öffentliche Kritik auslöste, bis zu wiederholten Debatten rund um Riot Games’ Vanguard, das dauerhaft im Kernel-Modus läuft und bereits mehrfach Gegenstand von Sicherheitsanalysen war. Auch Treiber aus dem Umfeld anderer bekannter Titel wurden in der Vergangenheit von Angreifern zweckentfremdet, um Sicherheitssoftware auf fremden Systemen zu deaktivieren, ganz unabhängig vom eigentlichen Spiel.
Der gemeinsame Nenner all dieser Fälle ist immer derselbe: Sobald ein Hersteller aus Wettbewerbsgründen Kernel-Rechte beansprucht, um Cheater zuverlässiger zu erkennen, steigt automatisch der Schaden, den ein Programmierfehler in genau diesem Code anrichten kann. Eine Analyse des Fachportals Cyber Station bringt es auf den Punkt: Anti-Cheat-Software soll eigentlich Schutz bieten, kann aber genau durch ihre privilegierte Stellung selbst zum Sicherheitsrisiko werden. Diese Doppelrolle, Schutzmechanismus und potenzielles Einfallstor zugleich, ist die eigentliche Lehre aus dem GFAC-Fall.
Marktvergleich: Wie GFAC gegenüber Vanguard, EasyAntiCheat und Javelin abschneidet
Der Anti-Cheat-Markt ist in den vergangenen Jahren deutlich gewachsen und laut Branchendaten des Analysedienstes VoxBooster inzwischen auf ein Marktvolumen von rund 180 Millionen US-Dollar geschätzt, getrieben vor allem durch die zunehmende Verbreitung von DMA-basierten Cheat-Geräten, die Soft- und Hardware-Erkennung gleichermaßen umgehen sollen. In diesem Markt tummeln sich sehr unterschiedlich ausgestattete Anbieter, von milliardenschweren Publishern bis zu kleinen Nischenlösungen wie GFAC.
Electronic Arts etwa hat sein eigenes System Javelin Anti-Cheat erst im September 2026 mit einem größeren Update versehen, das unter anderem eine verbesserte Erkennung von DMA-Angriffen einführt und als Teil eines mehrjährigen Investitionsprogramms in Anti-Cheat-Technik vermarktet wird. Riot Games wiederum setzt bei Vanguard konsequent auf einen dauerhaft aktiven Kernel-Treiber, über den unser Vergleichsartikel zur Vanguard-Anti-Cheat-Akzeptanz unter Spielern bereits berichtet hat. Beide Systeme haben eigene Security-Teams, veröffentlichen technische Erklärungen zu ihrer Architektur und reagieren öffentlich auf Kritik, ein Kontrast, der im Vergleich zum schweigenden Little Orbit besonders auffällt.
| Anti-Cheat-System | Betreiber | Kernel-Zugriff | Reaktion auf aktuelle Sicherheitsfragen |
|---|---|---|---|
| GFAC (GamersFirst Anti-Cheat) | Little Orbit | Ja, dauerhaft (GFAC_Sys_x64.sys) | Keine Reaktion auf CERT/CC-Meldung VU#639124 |
| Vanguard | Riot Games | Ja, dauerhaft | Eigenes Security-Team, öffentliche technische Kommunikation |
| Easy Anti-Cheat | Epic Games | Ja, dauerhaft bei vielen Titeln | Teil eines großen Publisher-Sicherheitsteams |
| Javelin Anti-Cheat | Electronic Arts | Ja, mit Update im September 2026 ausgebaut | Aktives Update-Programm, neue Anti-DMA-Erkennung |
Was Cheat-Entwicklung mit der aktuellen Lücke zu tun hat
Interessant ist der GFAC-Fall auch deshalb, weil er zeigt, wie eng Anti-Cheat-Sicherheit und die Cheat-Szene selbst miteinander verzahnt sind. Fachportale wie CriticalHit beschreiben für 2026 mehrere Cheat-Kategorien, die aktuelle Anti-Cheat-Systeme weiterhin kaum zuverlässig erkennen, darunter DMA-Hardware-Cheats, die komplett außerhalb des überwachten Prozessraums arbeiten. Wenn nun ausgerechnet der Schutzmechanismus selbst verwundbar ist, kehrt sich das Kräfteverhältnis in doppelter Hinsicht um: Cheater könnten die Lücke nutzen, um Erkennung zu umgehen, während gleichzeitig jeder andere Angreifer dieselbe Lücke für ganz andere Zwecke missbrauchen kann, etwa zur Verbreitung von Schadsoftware über ein kompromittiertes Gaming-Netzwerk.
Ein Beitrag des Entwicklerblogs Bubble beschreibt die Beziehung zwischen Anti-Cheat-Herstellern und Cheat-Entwicklern treffend als ein Rennen, das keine Seite endgültig gewinnen kann, aber dennoch fortlaufend weitergeführt werden muss. Genau in diesem Wettlauf ist jede neu entdeckte Treiberschwachstelle ein Rückschlag, der das Vertrauen in das gesamte System untergräbt, selbst wenn am Ende nur ein einzelner, kleinerer Anbieter betroffen ist.
Risiken für Unternehmen und Privatanwender in der DACH-Region
Für IT-Verantwortliche in deutschen, österreichischen und Schweizer Unternehmen ist der Fall vor allem deshalb relevant, weil Gaming-Treiber auf Firmengeräten keine Seltenheit sind, insbesondere in Bring-your-own-device-Umgebungen oder auf Geräten, die Mitarbeitende auch privat nutzen. Eine lokale Rechteausweitung auf SYSTEM-Ebene ist aus Sicht der Endpoint-Sicherheit nicht automatisch harmlos, nur weil der ursprüngliche Zweck des Treibers ein Spiel betrifft. Wer bereits mit eingeschränkten Rechten Zugriff auf ein System hat, etwa über Phishing oder ein kompromittiertes Nutzerkonto, kann genau solche Treiberlücken nutzen, um sich lateral im Netzwerk zu bewegen oder Schutzsoftware zu deaktivieren.
Sicherheitsteams, die ohnehin mit Werkzeugen zur Priorisierung von Schwachstellen arbeiten, etwa im Abgleich mit Listen wie der CISA Known Exploited Vulnerabilities-Liste, sollten GFAC-bezogene Systeme vorerst genauer im Blick behalten, selbst wenn die Lücke noch nicht offiziell als aktiv ausgenutzt gemeldet wurde. Die Kombination aus unreagierendem Hersteller, öffentlichem Exploit-Code und SYSTEM-Rechten ist in der Praxis genau das Muster, das aus einer theoretischen Lücke sehr schnell eine praktisch ausgenutzte macht.
Was Spieler und Administratoren jetzt konkret tun sollten
CERT/CC nennt in seiner Meldung explizit drei kurzfristige Maßnahmen, solange kein offizieller Patch vorliegt. Erstens sollte der lokale Zugriff auf betroffene Systeme auf vertrauenswürdige Nutzer beschränkt werden, was gerade bei gemeinsam genutzten Familiencomputern oder Internetcafés relevant ist. Zweitens empfiehlt CERT/CC eine aktive Überwachung auf unautorisierte Interaktionen mit dem GFAC-Treiber, was in der Praxis jedoch vor allem für Unternehmen mit entsprechender Endpoint-Detection-Infrastruktur umsetzbar ist. Drittens, und das ist die für Privatspieler relevanteste Maßnahme, sollten Spiele, die auf GFAC setzen, bis zu einem verfügbaren Update deinstalliert oder zumindest nicht aktiv betrieben werden.
Wer unsicher ist, ob ein installiertes Spiel auf GFAC zurückgreift, kann im Windows-Gerätemanager oder über die Dienstübersicht nach Prozessen und Treibern mit dem Namen GFAC oder GamersFirst suchen. Da es bislang keine offizielle Stellungnahme von Little Orbit gibt, bleibt als sicherste Option tatsächlich der vollständige Verzicht auf die Nutzung, bis sich das ändert.
Marktauswirkungen: Vertrauen in Nischen-Anti-Cheat sinkt weiter
Über die rein technische Dimension hinaus hat der Fall auch eine Marktdimension. Spieler und Communities reagieren auf öffentlich gewordene Anti-Cheat-Lücken zunehmend empfindlich, weil Kernel-Zugriff grundsätzlich ein Vertrauensvorschuss ist, den Nutzer dem Hersteller geben. Bricht dieses Vertrauen bei einem kleineren Anbieter wie Little Orbit weg, drohen Spielerabwanderung und Reputationsschäden für die betroffenen Titel, selbst wenn die Spiele selbst technisch einwandfrei funktionieren. Größere Publisher wie EA oder Riot Games investieren nicht zufällig in öffentliche Kommunikation rund um ihre Anti-Cheat-Systeme, denn genau diese Transparenz wirkt Vertrauensverlust entgegen, während Stillschweigen wie im aktuellen Fall das Gegenteil bewirkt.
Langfristig dürfte dieser Vorfall auch die Debatte befeuern, ob kleinere Studios und Publisher kritische Sicherheitsinfrastruktur wie Kernel-Anti-Cheat überhaupt noch selbst entwickeln sollten, oder ob eine Konsolidierung auf wenige, intensiv geprüfte Standardlösungen für die gesamte Branche sinnvoller wäre. Ein Blick auf andere Bereiche der IT-Sicherheit zeigt, dass ähnliche Konsolidierungswellen bereits stattgefunden haben, etwa bei Zertifikatsverwaltung oder Schwachstellen-Scannern, wo sich der Markt zunehmend auf wenige etablierte Anbieter konzentriert.
Einordnung: Verantwortungsvolle Offenlegung ohne Hersteller-Echo
Der Ablauf der Offenlegung selbst ist lehrbuchhaft, auch wenn er ohne Hersteller-Beteiligung endete. Necula entdeckte die Schwachstellen, meldete sie an CERT/CC, das Institut kontaktierte den Hersteller am 14. Mai 2026 und wartete rund sieben Wochen auf eine Reaktion, bevor es die Details am 2. Juli 2026 öffentlich machte. Dieses Vorgehen folgt dem international etablierten Standard für koordinierte Offenlegung, bei dem Herstellern grundsätzlich eine angemessene Frist eingeräumt wird, bevor technische Details publiziert werden. Dass Little Orbit diese Frist verstreichen ließ, ändert nichts am Prozess selbst, verschiebt aber das Risiko eindeutig auf die Nutzerseite.
Für die Software-Lieferkette insgesamt ist das ein Warnsignal, wie es auch im Kontext anderer kritischer Lücken immer wieder auftaucht, etwa wenn kritische Zero-Days in weitverbreiteter Sicherheitssoftware ohne rechtzeitigen Patch bleiben. Je kleiner und ressourcenärmer ein Hersteller ist, desto größer ist die Gefahr, dass eine koordinierte Offenlegung ins Leere läuft und die Lücke faktisch unbegrenzt offen bleibt.
Prognosen: Wie sich der Fall GFAC weiterentwickeln dürfte
- Little Orbit wird mittelfristig unter öffentlichem Druck stehen, zumindest eine Stellungnahme oder einen Patch-Fahrplan zu veröffentlichen, sobald Medien und Spieler-Communities über VU#639124 breiter berichten.
- Es ist wahrscheinlich, dass Sicherheitsforscher die bereits öffentlichen Proof-of-Concept-Exploits weiter verfeinern und in Tools zur Erkennung verwundbarer Kernel-Treiber integrieren, ähnlich wie es bei früheren Bring-your-own-vulnerable-driver-Fällen üblich war.
- Größere Anti-Cheat-Anbieter wie EA mit Javelin und Riot mit Vanguard werden den Vorfall voraussichtlich nutzen, um ihre eigenen, aktiver gepflegten Systeme als vertrauenswürdigere Alternative zu positionieren.
- Die Debatte um verpflichtende Sicherheitsaudits für Kernel-Treiber in Spielen dürfte an Fahrt gewinnen, insbesondere in Communities rund um Windows-Sicherheit und bei Anbietern von Endpoint-Schutzlösungen.
- Sollte Little Orbit auch mittelfristig nicht reagieren, ist ein Rückgang der Spielerzahlen bei GFAC-abhängigen Titeln plausibel, da sicherheitsbewusste Spieler zunehmend auf alternative Plattformen oder Titel mit transparenteren Anti-Cheat-Systemen ausweichen könnten.
Fazit: Ein kleiner Treiber mit großer Angriffsfläche
Der Fall GFAC zeigt im Kleinen ein Problem, das die gesamte Gaming-Branche im Großen betrifft: Kernel-Level-Anti-Cheat bringt einen echten Sicherheitsgewinn gegen Cheater, aber nur dann, wenn der Hersteller die damit verbundene Verantwortung auch tatsächlich trägt. Drei CVEs, ein unerreichbarer Hersteller und bereits öffentlicher Exploit-Code sind in Kombination keine theoretische Bedrohung mehr, sondern ein sehr konkretes Risiko für jeden, der die betroffene Software installiert hat. Bis Little Orbit reagiert, bleibt Spielern und IT-Verantwortlichen nur die von CERT/CC empfohlene Brute-Force-Lösung: Zugriff einschränken, Systeme überwachen, und im Zweifel die betroffene Software komplett entfernen.
Häufig gestellte Fragen zur GFAC-Sicherheitslücke
Was ist GFAC_Sys_x64.sys genau?
Es handelt sich um den Kernel-Mode-Treiber der GamersFirst-Anti-Cheat-Technik (GFAC) von Little Orbit. Er läuft mit den höchsten Rechten des Betriebssystems, um Cheat-Software in Spielen zu erkennen, die auf GFAC setzen.
Welche CVE-Nummern betreffen die aktuelle Sicherheitslücke?
Es sind drei Kennungen vergeben: CVE-2026-12166 (Systemabsturz durch NULL-Pointer-Dereferenz), CVE-2026-12167 (unzureichende Zugriffskontrolle) und CVE-2026-12168 (beliebiger Kernel-Schreibzugriff mit Rechteausweitung auf SYSTEM).
Gibt es bereits einen Patch von Little Orbit?
Nein. CERT/CC gibt an, den Hersteller nicht erreicht zu haben, weder vor der Veröffentlichung am 2. Juli 2026 noch danach. Ein offizieller Patch oder Zeitplan liegt bislang nicht vor.
Kann die Lücke aus der Ferne ausgenutzt werden?
Nein, es handelt sich um lokale Rechteausweitungen. Ein Angreifer benötigt bereits irgendeine Form von Zugriff auf das Zielsystem, etwa über ein kompromittiertes Benutzerkonto oder physischen Zugang, bevor er die Lücken ausnutzen kann.
Ist Proof-of-Concept-Code für die Lücken öffentlich verfügbar?
Ja, zu allen drei CVE-Nummern existiert bereits öffentlicher Exploit-Code, was die Hürde für eine tatsächliche Ausnutzung deutlich senkt.
Was sollten Spieler jetzt tun?
CERT/CC empfiehlt, Spiele, die auf GFAC setzen, bis zu einem verfügbaren Update zu deinstallieren oder nicht aktiv zu nutzen, den lokalen Systemzugriff auf vertrauenswürdige Personen zu beschränken und auf ungewöhnliche Interaktionen mit dem Treiber zu achten.
Wie unterscheidet sich GFAC von Anti-Cheat-Systemen wie Vanguard oder Javelin?
Alle genannten Systeme nutzen Kernel-Treiber, doch Vanguard von Riot Games und Javelin von Electronic Arts werden von großen, aktiv kommunizierenden Security-Teams betreut. GFAC wirkt im Vergleich dazu deutlich weniger aktiv gepflegt, was sich aktuell in der fehlenden Reaktion auf VU#639124 zeigt.
Wie groß ist der Anti-Cheat-Markt insgesamt?
Branchenanalysen von VoxBooster schätzen den globalen Markt für Anti-Cheat-Software 2026 auf rund 180 Millionen US-Dollar, mit deutlichem Wachstum im Bereich der Erkennung von DMA-basierten Hardware-Cheats.