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.

Overview
Multiple vendor-signed UEFI applications are vulnerable to Secure Boot bypass via a “Bring Your Own Vulnerable Driver” (BYOVD)-style attack. If a target system trusts the affected vendor’s certificate, an attacker can exploit these applications to execute arbitrary code during the early pre-boot phase before the operating system initializes. To mitigate this risk, system administrators should apply updates to the UEFI Forbidden Signature Database (DBX) that revoke trust in the affected vendor-signed binaries, preventing these vulnerable applications from executing during the boot process.
Description
The Unified Extensible Firmware Interface (UEFI) standard defines the modern firmware architecture used to initialize hardware and transfer control to the operating system during system startup. On systems with Secure Boot enabled, UEFI applications and drivers must be cryptographically signed and verified before execution. Trust for these signatures is established through several firmware-managed databases, including the authorized signature database (DB), which commonly contains certificates from original equipment manufacturer (OEM) vendors, operating system authorities, and other supply-chain partners in the UEFI ecosystem.
The UEFI shell is a command-line application that allows advanced users to interact directly with the UEFI environment to run diagnostics or special tasks prior to the operating system boot. Other UEFI applications, such as bootloaders, manage the operating system startup sequence or load specific drivers before the main OS initializes. Some of these applications possess functionalities that can manipulate system memory, modify sensitive NVRAM variables, or load raw drivers.
If a vendor-signed application inadvertently exposes these capabilities without strict access controls, attackers can abuse them to circumvent Secure Boot policies and execute unverified code. This exposure effectively results in an early compromise of the pre-boot environment, bypassing the Secure Boot policy.
Researchers from ESET identified multiple UEFI applications vulnerable to this type of abuse. To neutralize the risk, the affected binaries will be added to vendor-specific DBX revocation lists to prevent them from executing on the target systems.

Impacted UEFI Applications
[Vendor, Application and vulnerable function
Authenticode SHA hash
SHA256 file hash]

Acer `GRUB2` insmod
71DCE405964C67779DB92DBC01F683D6E29075AB
6cc0e9501420ec036f0ad74df2d17f4d6360f26585f265042537b9f8c2780c30
Acer `UEFI shell` mm,dmpstore
D275C2DFD884D2B7842C7F861C527A9FFC6E59DD
b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883
Acer `UEFI shell` mm,dmpstore
42C4923E676A9FD0A93C08631AD7A8244A8F2174
0784c30a83bfcc45bf42804e5729323987957f0a104fcb693d0ff10d76d5b42c
Acer `UEFI shell` mm,dmpstore
04BE47C873F116B85111FBF8EE9191C87CEE2619
b0af2158f11535d8458b8497a35e96d5afc76e43825f255d2d6aa2da74bad883
Acer Emdoor `UEFI shell` mm,setvar
CD5E3EAD6F78526BF9301DEEF66906618654F604
14a493007443c72050ce644562db1470e36bf9d04baf5dec6b046e32cbdbb61b
AMD `UEFI shell` mm,dmpstore
744565FBB35DB710BCC1547292204763C731DC55
58bc1e460a1b7e18e6ad12dae8020c38bd7b3d6217130dd127ae232e4b248406
ASUS schenker-tech.de(XMG) `UEFI shell` mm,dmpstore
DC18D31E46A541C9E42F9588554ADDC7DECE124B
61ee9a23c366a102ceb34c78af7816413769791658cdb668b02cb81ec94f7c70
ECS `UEFI Shell` mm,dmpstore
59BA2B5C239AF3CC7FCE74AA5E65AAA8CE3C454F
81da15d6acdfb7868ecea44d41c869c2295603af9a44a2d106d4c0e57d66908
Getac `UEFI Shell` mm,dmpstore
35FBD8ED5ED31D281A6146360CDEFE7E8CEC31DA
09d895bb03bdac3188ef61b09ab72b99492cfd0b785cbc3eb2eb75657a2f9fa0
GIGABYTE Maibenben `UEFI Shell` mm,setvar,dmpstore
6CC172CBFEEA24B2806B477F8EDF897334ECC486
2944da098861619e21b522a642235bb2ec189ff20ef96e100b2ffdd9a39c3416
Toshiba `UEFI Shell` mm,dmpstore
2EAE2807A4265D9C30EECA68A8C59C7A6D1ACFE7
cad246ae8a5db51f32f128896ccef5efc30e5d65c9d9722b449988d43da53d51
Uniwill Maingear schenker-tech.de(XMG) `UEFI Shell` mm,dmpstore
8CED62F9BD5C987A80598DA1E13414391BBB1ADE
55682bec887134a2ccaa2cd5458cd3fe6395ea93bb88c9dc541806428b14fc66

Impact
This vulnerability only impacts systems where the specific affected vendor’s certificate is trusted within the UEFI Authorized Signature Database (DB). On such systems, an attacker with administrative privileges or physical access could leverage the vulnerable application to bypass Secure Boot protections and execute arbitrary code before the operating system loads.
Code executed during this early boot phase can achieve persistent platform compromise, including the ability to load unsigned or malicious kernel components that survive system reboots and operating system reinstallations. Because this activity occurs before the operating system and endpoint security products initialize, malicious code executed through this technique may completely evade detection by standard security controls and endpoint detection and response (EDR) solutions.
Solution
Apply the latest firmware and software updates provided by your hardware or software vendor. Please refer to the Vendor Information section for details. Updated software packages will replace vulnerable UEFI applications with corrected versions that incorporate the latest upstream security fixes.Additionally, administrators should update and verify the UEFI DBX on affected systems to ensure the vulnerable binaries are revoked and can no longer execute during the boot process.
Acknowledgements
Thanks to Martin Smolar of ESET for researching and reporting this vulnerability. This document was written by Vijay Sarvepalli.