Overview
The GamersFirst Anti-Cheat (GFAC) driver GFAC.sys contains multiple local privilege escalations and denial-of-service vulnerabilities stemming from insecure handling of user-controlled input through a minifilter communication port. A local attacker can abuse these flaws to perform arbitrary kernel memory writes, obtain privilege escalation to SYSTEM, or trigger a system crash.
Description
GFAC is a proprietary anti-cheat software developed by video game publisher Little Orbit. GFAC includes a kernel-mode driver, GFAC_Sys_x64.sys, that exposes privileged functionality to user-mode applications through a minifilter communication port. Although these low-level interfaces are necessary for the software’s operation, vulnerabilities can arise if user-mode access is not properly restricted and validated.
CVE-2026-12166 GFAC_Sys_x64.sys contains a NULL pointer dereference condition in its initialization and request handling logic. A local attacker can trigger the vulnerable code path, causing the driver to read or write to a memory address assigned as NULL. Successful exploitation results in a system crash (“blue screen of death”).
CVE-2026-12167 The minifilter communication port that GFAC_Sys_x64.sys exposes does not enforce sufficiently restrictive security descriptors. As a result, low-privileged users can establish connections to the driver and access functions intended only for trusted processes. [RM1.1][MB1.2][RM1.3]User access to privileged functions could help an attacker take advantage of other weaknesses in the driver.
CVE-2026-12168 GFAC_Sys_x64.sys processes messages received through a minifilter communication port without properly validating user-supplied memory addresses before performing write operations. An attacker can provide a crafted request containing a desired destination address and data value, causing the driver to write arbitrary data to kernel memory. This write-what-where condition can be leveraged to modify sensitive operating system structures, such as process security tokens, resulting in privilege escalation to SYSTEM.
Impact
Multiple vulnerabilities in the driver may allow local attackers to crash the system, escalate privileges to SYSTEM, or execute unauthorized code. Due to insufficient access controls, privileged driver functionality is exposed to untrusted users, increasing the likelihood and impact of exploitation.
Solution
Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Users should restrict local access to trusted users and monitor systems for unauthorized interactions with GFAC. Where available, games that utilize GFAC should be disabled or removed until an update is available to address the identified vulnerabilities.
Acknowledgements
Thanks to Lucian Alexandru Necula for identifying and disclosing these vulnerabilities. This document was written by Michael Bragg.

Overview
Two vulnerabilities have been identified in FastStone Image Viewer 8.3 that may allow remote code execution or control-flow corruption when processing specially crafted image files. The affected components include the JPEG 2000 (JP2) parser and the PSD file parser. An attacker can exploit these vulnerabilities by causing the application to automatically or interactively process malicious image files.
Description
FastStone Image Viewer is a software tool for browsing, editing, and managing images, offering features like full‑screen viewing, batch processing, red‑eye removal, and a wide range of editing effects. It supports virtually all major image and RAW formats and includes conveniences like slideshows, comparison tools, scanner support, and screen capture.
CVE-2026-30040 A critical heap-based buffer overflow vulnerability exists in FastStone Image Viewer, versions 8.3 and earlier. The issue is triggered during the parsing of JPEG 2000 (JP2) files due to a malformed QCD (quantization default, 0xFF5C) marker in the FSViewer.exe process. By exploiting this flaw, a remote attacker can overwrite the EIP (instruction pointer) and execute arbitrary code in the context of the current process via a crafted JP2 file.
Notably, this issue does not require the victim to directly open the crafted JP2 file. When the application enumerates directories during automatic thumbnail generation, files within two directory levels are parsed by the JP2 decoder. If the malicious JP2 file is present within this enumeration range (for example in the user’s Downloads folder), the vulnerability is triggered automatically.
CVE-2026-30041 An integer overflow vulnerability exists in the PSD parser of FastStone Image Viewer, versions 8.3 and earlier. The vulnerability is caused by a lack of proper validation for the height value in PSD files, leading to a subsequent heap-based buffer overflow. Successful exploitation could allow a remote attacker to execute arbitrary code or cause a persistent denial-of-service (crash) via a crafted PSD file.
Impact
Successful exploitation of CVE-2026-30040 could allow arbitrary code execution in the context of the user running FastStone Image Viewer. Additionally, an attacker could exploit CVE-2026-30041 to overwrite the instruction pointer and control the program’s execution flow, crashing the application or potentially enabling arbitrary code execution. The impact severity depends on the privileges of the user running the application. Code executed under elevated permissions would result in significantly higher risk.
Solution
Unfortunately, we were unable to reach the vendor for coordination, and a patch is not yet available. To limit the risk of this vulnerability, run the software using a restricted local account and enforce policies that prevent users from downloading or saving JP2 or PSD files from untrusted sources.
Acknowledgements
This vulnerability was disclosed by Sunghun Oh. This document was written by Bob Kemerer.

Overview
Microsoft Windows Recovery Environment (WinRE) provides a mechanism for recovering and repairing Windows systems using an alternate boot environment. Under certain platform implementations, access to WinRE may allow an attacker to bypass firmware security controls, including administrator-configured UEFI/BIOS passwords. An attacker with physical or administrative access to a device may be able to leverage WinRE-related boot mechanisms to circumvent firmware protections and gain unauthorized access to system resources.
Description
Microsoft Windows versions 10 and 11 include the WinRE capability, a recovery platform that supports features such as the F11 recovery menu and the Reset this PC functionalities. WinRE is commonly used for system recovery, troubleshooting, and remote support scenarios.
When WinRE is invoked, the system reboots into a recovery environment that may use an alternate boot path from the standard operating system startup sequence. Depending on the platform and firmware implementation, the alternate boot path may not consistently enforce the same UEFI/BIOS security controls that are applied during a normal boot process.
A security concern has been identified in certain WinRE implementations where administrative UEFI/BIOS passwords may not be enforced during specific recovery operations. This inconsistency in the boot execution path may allow an attacker with physical access to a device to bypass firmware-level protections. Such scenarios are commonly associated with “Evil Maid” attacks, in which an attacker gains temporary physical access to an unattended system and modifies its boot configuration or security settings.
In UEFI-based systems, the UEFI boot manager supports the BootNext variable, which specifies a one-time boot target stored in non-volatile memory (NVRAM). The UEFI trust model assumes that only privileged software or the platform owner can modify NVRAM variables; however, the BootNext variable itself is not authenticated and takes precedence over the normal BootOrder configuration during the next boot cycle. When Secure Boot is enabled, firmware validates the integrity and signature of the boot application specified by BootNext before execution. The UEFI specification does not explicitly mandate a full platform reset when the BootNext variable is configured, leaving reset-handling and user authentication flows to the specific implementation. Consequently, the effectiveness of pre-boot security controls (such as UEFI/BIOS password protections and BitLocker full-disk encryption) can be bypassed via recovery environments like WinRE, provided a user has the privileges required to initiate such recovery.
Organizations with high security requirements for their devices should not rely solely on UEFI/BIOS passwords to protect systems where WinRE or such recovery environments are accessible to untrusted users. Additional controls should be implemented to protect against both physical-access and privileged-user attacks.
Impact
An attacker with access to the Windows Recovery Environment may be able to bypass administrator-configured UEFI/BIOS password protections on affected systems. Depending on the device configuration and firmware implementation, an attacker may also be able to perform actions that weaken or circumvent BitLocker full-disk encryption protections, potentially resulting in unauthorized access to sensitive data.
Solution
Microsoft has published an advisory related to recovery-environment hardening and secure boot configurations, including mitigations for vulnerabilities affecting WinRE mechanisms. Organizations should review applicable vendor guidance and evaluate whether their systems are susceptible to WinRE-based firmware security bypasses.
In addition to standard recommendations (e.g., enabling Secure Boot), the following mitigations are advised for highly sensitive systems:

Disable or restrict WinRE on systems where recovery functionality is not operationally required.
Require administrative authorization with ephemeral one-time access before enabling or invoking recovery environments.
Enable BitLocker with TPM + PIN or TPM + Startup Key to ensure additional authentication is required during recovery and pre-boot scenarios.
Enable restrictions of pluggable media with EFI System Partitions (ESP) and any modifications to sensitive items in UEFI NVRAM such as BootNext and BootOrder.
Deploy endpoint detection and response (EDR) solutions or end-point restrictions that support pre-boot security along with remote attestation and measured boot technologies to detect or block unauthorized boot modifications.
Implement physical security controls, including device locks, secure storage, tamper-evident protections, and chain-of-custody procedures for high-value systems.

These recommendations should be evaluated in accordance with organizational recovery requirements and operational constraints. Some of the recommendations were adapted from Eclypsium research blog
Acknowledgements
Thanks to Beatriz Fresno Naumova for reporting this vulnerability. This document was written by Vijay Sarvepalli.