GNU Wget, versions 1.25.0 and earlier, contains a server-side request forgery (SSRF) vulnerability in its implementation of FTP passive mode. Because Wget does not properly validate IP addresses obtained from PASV responses, an attacker-controlled FTP endpoint can redirect the client’s connection to arbitrary IPs, potentially exposing internal network host and service responses. This vulnerability has been remediated in a recent update by GNU; see the Solutions section below for resolution guidance.
Description
GNU Wget is a widely used command-line utility for retrieving content over HTTP, HTTPS, and FTP. When operating over FTP in passive mode, Wget relies on the server’s PASV response to determine which IP address and port to use for the data connection.
CVE-2026-15146 GNU Wget does not validate the IP address provided by an FTP PASV response while operating in FTP passive mode. A malicious FTP server, or an HTTP server that redirects to an FTP URL, can exploit this behavior to redirect Wget’s data connection to an arbitrary IP address and port. This allows an attacker to forge server-side requests (SSRF) from the machine running Wget, potentially accessing localhost services or internal network resources.
This issue belongs to a known class of FTP PASV vulnerabilities such as CVE-2021-40491, which was previously remediated in GNU Inetutils.
Impact
A remote attacker controlling or influencing an FTP endpoint can induce Wget to establish connections to otherwise inaccessible internal network addresses. This may allow the attacker to retrieve service banners, access internal HTTP endpoints, or exfiltrate data from internal systems reachable by the victim host. Applications that embed Wget for automated retrieval are particularly susceptible, because the vulnerability may be triggered automatically through redirected requests and untrusted user-supplied URLs.
Solution
GNU Wget has remediated this issue in the 07/05/2026 commit 4f85853f641863d5915786a8413e1a213726a62b. Users are advised to update their version according to vendor guidance.
Acknowledgements
Thanks to Jeremy Brown for researching and reporting this vulnerability. This document was written by Molly Jaconski.
Vendor Information
One or more vendors are listed for this advisory. Please reference the full report for more information.
PayRange is a mobile payment app that allows users to pay for vending machines, laundromats, and other unattended machines using a smartphone with Bluetooth. Two vulnerabilities were discovered in version 7.0.7 of the PayRange app that is available in the Google Play store.
Description
A vulnerability (CVE-2026-13462) exists in the PayRange Android app that causes invalid SSL certificates to be accepted in application WebViews. A second vulnerability (CVE-2026-13461) exists that allows the injection of JavaScript, which can be used to escape the WebView sandbox and perform a number of dangerous actions on the user's device. These vulnerabilities were discovered in version 7.0.7 of the PayRange app.
The PayRange app bypasses Android's SSL trust chain and accepts certificates that match any of the following rules (including self-signed certificates):
Common Name ends with "payrange.com"
Common Name contains "stripe.com"
Common Name contains "fetlifestatus.com" AND any of these conditions are true:
Issuer Common Name is "R10"
Issuer Common Name is "R3"
Issuer Common Name contains "Network Solutions"
The attack vector is an on-path interception. If an attacker can direct traffic intended for a legitimate server to a device they control, they can negotiate a TLS connection with the user's device using any trusted certificate that matches the rule set. They are then able to inject content into the WebView and harvest credentials, issue malicious requests and read data entered by the user, including exchanges with the PayRange and Stripe servers.
Impact
An attacker may be able to intercept any information they can convince the user to send through the app. If the user is a machine operator, the injected JavaScript code can also connect to PayRange hardware and issue commands with the full permissions of the operator.
Solution
Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Apply the latest software updates provided by your hardware or software vendor as they become available.
Acknowledgements
Thanks to Tahi Wilton Geary for reporting this vulnerability. This document was written by Bob Kemerer.
Vendor Information
One or more vendors are listed for this advisory. Please reference the full report for more information.
Two vulnerabilities have been discovered in Xerte Online Toolkits, an open-source e-learning authoring toolsuite intended for the creation of learning materials within a web browser. CVE-2026-14261 tracks the persistence of the /setup/ directory after installation, which allows an unauthenticated attacker to reconfigure the application to point to a remote database they control in order to gain administrative access. CVE-2026-12116 tracks an editable antivirus binary path that can be redirected to a PHP interpreter, causing uploaded files to be executed as PHP code and resulting in remote code execution (RCE). Version v3.15.5 or v3.14.6 of Xerte Online Toolkits fixes these vulnerabilities.
Description
Xerte Online Toolkits is a suite of a free, open-source e-learning authoring tools that allows users to make educational materials directly in-browser. The toolset is installed from multiple packages, and creates a setup folder that persists after installation.
CVE-2026-14261
A vulnerability in Xerte Online Toolkits allows for authentication bypass and remote code execution via reinstallation through the /setup/ folder, enabling attackers to reinstall the service to a remote database they control.
CVE-2026-12116
A vulnerability in Xerte Online Toolkits allows for RCE through the antivirus binary path in the tools server settings. The antivirus binary runs on all uploaded files, but the path to the binary can be modified using the configuration menu. An attacker can achieve remote code execution by redirecting the path to a PHP interpreter, causing any uploaded PHP scripts to be executed.
During installation, Xerte creates a /setup/ folder to configure database connection settings. This folder persists post-installation without access controls or automatic cleanup, and /setup/index.php does not verify whether installation has completed. An attacker can revisit /setup/ and reconfigure the application to point to a remote database, thereby gaining administrative access.
After gaining admin privileges, an attacker can abuse CVE-2026-12116 by editing the antivirus binary path to point to a PHP interpreter. This causes any new uploaded files to be passed to the PHP runtime through website_code/php/import/fileupload.php, bypassing file extension checks and resulting in remote code execution.
Impact
Successful exploitation can allow full remote code execution on the affected server. This enables attackers to establish persistent access, exfiltrate data, or launch supply chain attacks by injecting malicious content into educational materials distributed by the platform.
Solution
These issues have been addressed in two commits:
- 8fec660 removes /setup/ automatically after installation/upgrade and blocks reuse.
- 8ef2062 moves sensitive configuration files, including the antivirus binary path, to server-side locations.
Users should take the following steps immediately:
1. Manually remove the initial installation /setup/ folder from installations.
2. Upgrade to Xerte v3.15.5 or v3.14.6 and run upgrade.php, which enforces automatic /setup/ removal and includes security hardening. If removal fails, the updated code still prevents exploitation.
This blog post: https://www.xerte.org.uk/index.php/en/news/blog/80-news/364-xerte-3-14-and-3-15-important-security-update contains more information and contact data for Xerte.
Acknowledgements
Thanks to the reporter, George Filippov from the Vexel Foundation. This document was written by Christopher Cullen.
Vendor Information
One or more vendors are listed for this advisory. Please reference the full report for more information.
Adalo’s no‑code application platform exposes complete user records through its database API for all applications built on both V1 and V2. Due to a platform-level flaw, authenticated users can retrieve full user data belonging to any Adalo application, regardless of configuration. This issue affects more than one million applications and placing developers and their end users at risk of data exposure that they cannot prevent or remediate.
Description
Adalo is a Software-as-a-Service (SaaS) provider for building no-code applications. In theory, each application or tenant (customer) is logically isolated with separate databases, users, and configurations.
CVE-2026-10706 Unrestricted Disclosure of Full User Records
The Adalo database API contains a flaw which allows the backend to return complete user records for every list component request, regardless of which fields the component is configured to display. The database does not enforce ownership‑aware, server‑side authorization checks, allowing authenticated users of any Adalo application to query database and table identifiers belonging to other applications and retrieve full records, including fields not requested. This issue is amplified by the permissive CORS policy, plaintext storage of all text files and evidence suggests that deleted records may remain accessible.
CVE-2026-10708 Exposure and Reuse of Long-Lived JWT Tokens
The JWT tokens are visible in client‑side requests and remain valid for approximately twenty days. Once copied, they can be reused from any external website or script to query the database API directly. Because the platform allows requests from any origin, attackers can repeatedly query the API and extract large volumes of user data without interacting with the application itself. The combination of exposed tokens, permissive CORS behavior, and large response limits enables persistent, automated harvesting of entire user databases using only a single token obtained from any visitor session.
Impact
These vulnerabilities affect all Adalo applications across both V1 and V2. Because they occur at the platform level, the entire population of Adalo‑built applications is impacted.
Exposure of Sensitive Information to an Unauthorized attacker (CVE-2026-10706) Attackers may extract full user records and correlate user behavior across multiple applications via dbId enumeration. The platform does not implement data minimization, privacy by design, or implement appropriate technical safeguards, allowing sensitive information to be exposed to unauthorized parties.
Insufficiently Protected Credentials (CVE-2026-10708) This vulnerability enables large‑scale data harvesting without requiring app‑specific secrets. A single request to a minimal leaderboard component may return user records containing emails, UUIDs, and custom fields. The combination of wildcard CORS behavior, long‑lived twenty‑day JWTs, and the absence of token revocation allows attackers to gather sensitive personal information from any Adalo application.
Solution
Adalo contains an access control weakness that may allow unauthorized users to bypass application boundaries under certain conditions. Adalo has acknowledged the issue, however, no patch is currently available. Customers and tenants should assume data in Adalo collections may be exposed, and avoid storing sensitive information there until a patch is deployed. Users should remain aware of increased phishing and identity theft risks and monitor their accounts for suspicious activity.
Acknowledgements
Thanks to the reporter Saud Darwish. This document was written by Laurie Tyzenhaus.
Vendor Information
One or more vendors are listed for this advisory. Please reference the full report for more information.
Several versions of Tenda firmware contain an undocumented authentication backdoor that grants administrative access to the devices' web management interfaces. An attacker can expoit this vulnerability, tracked as CVE-2026-11405, to bypass the password verification process and obtain full administrative control without valid credentials.
Tenda is a supplier of home and business network devices such as routers, switches, wireless access points, and video surveillance equipment. Most of these devices include web-based interfaces that allow users to perform configuration and management operations, which are protected by username/password authentication to prevent unauthorized modifications.
The web server binary /bin/httpd contains an undocumented backdoor authentication mechanism in the login() function. Initially, the function follows a normal authentication path using MD5-based password verification. However, if authentication fails, the function invokes GetValue("sys.rzadmin.password") to retrieve an alternate password value from the device configuration. It then performs a direct strcmp() comparison in plaintext between the user-supplied password and the configuration-stored value. A successful match grants role=2 admin-level access and creates a valid session.
The associated username is not validated, so any provided username will succeed when paired with the backdoor password. This backdoor authentication mechanism is not documented or visible through any administrative interface.
Impact
Successful exploitation grants full administrative access to the device's web interface, regardless of the configured administrator account credentials. With administrative control, an attacker can reconfigure the device, alter network settings, and disable security features, enabling broader compromise of the local network.
Solution
Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Since a patch is unavailable, we can only offer mitigation strategies. The following workarounds can help mitigate this vulnerability's impact until a fixed version is released:
Disable remote management on your device
If your device supports remote web management, disable it. Disabling this feature prevents attackers on external networks from accessing your device’s administrative dashboard over the internet.
Restrict local network exposure
Changing the default LAN IP address may reduce opportunistic discovery by automated scanners that target known default IP ranges. Note that this measure does not prevent deliberate or targeted network scanning.
Acknowledgements
Thanks to the reporter who wishes to remain anonymous. This document was written by Bob Kemerer.
Vendor Information
One or more vendors are listed for this advisory. Please reference the full report for more information.
HP Printers in the Deskjet 2800 Series running firmware version <=TBP1CN2612AR contain a missing authorization vulnerability tracked as CVE-2026-13753. This vulnerability allows unauthenticated access to the printer's webserver API endpoints, exposing Wi-Fi credentials, management configuration details, and sensitive security data normally restricted to administrative users.
Description
Modern HP printers provide a web-based management interface for configuring content such as Wi-Fi Direct settings, SNMP management access, and device security options. When accessed normally through the browser interface, these pages explicitly require administrator credentials before sensitive information is displayed. This information is protected because, for example, Wi-Fi Direct controls the printer's direct wireless connectivity, and SNMP configuration settings can reveal detailed information about the device's monitoring and management controls.
In affected firmware versions, the authorization requirement can be bypassed by sending direct, unauthenticated GET requests to multiple backend API endpoints. The affected endpoints return administrative configuration data without validating session state or authentication, including the Wi-Fi Direct SSID and plaintext passphrase, unique printer serial numbers and service IDs, and details about the device's administrative password state. This information is freely disclosed even though the corresponding web interface pages correctly enforce authentication, indicating an authorization flaw in the API layer.
Impact
A remote attacker with network access to the printer can bypass the web interface's authentication requirements and retrieve sensitive configuration data directly from backend APIs. Exposed information includes Wi-Fi Direct credentials, SNMP configuration details, device identity information, cloud service registration metadata, and other information involving the device's administrative security state. An attacker could use this information to gain unauthorized wireless access, perform reconnaissance on network or cloud integrations, impersonate the device, or facilitate further compromise of the printing environment.
Solution
Unfortunately, we were unable to reach HP to coordinate this vulnerability, so a firmware patch is not yet available. To limit the risk of this vulnerability, users should restrict network access to the printer's web interface by placing the device on a trusted or isolated network segment, disable Wi‑Fi Direct if it is not required, and limit SNMP access to trusted systems or disable it entirely. Firewall or access-control list (ACL) rules should be used to prevent untrusted hosts from reaching the printer's management ports, and discovery or cloud service features that are not needed should be disabled.
Acknowledgements
Thanks to Nguyễn Tiến Dũng for researching and reporting this vulnerability. This document was written by Molly Jaconski.
Vendor Information
One or more vendors are listed for this advisory. Please reference the full report for more information.
For 15 years (!), many of us who have touched cloud security have struggled with the shared responsibility model for cloud security. As with many “cyber things,” the theory is simple. Multiple vendors, consulting firms, and industry bodies have published deceptively clear matrices that depict exactly who is doing what for cloud security.
Everyone likes to present trivial cases: for example, the cloud provider is entirely responsible for the physical security of the data center, while the client is responsible for the application they just built and deployed within that cloud provider’s IaaS. In reality, many of the edge cases continue to cause pain to a lot of organizations.
Ok, so none of this is fundamentally new. However, in recent years, similar and more complex - dare I say sinister?- questions have emerged: What does shared responsibility look like for AI security?
Those who haven’t studied this topic in depth might assume there is no difference. Yet, there are fascinating, critical differences between shared responsibility for AI security and traditional cloud security, along with older related challenges like the shared security of outsourcing (that predate cloud).
Add AI with its probabilistic behaviors, untrusted user inputs, and nested vendor dependencies -and that finger-pointing cycle doesn’t just continue, it scales exponentially. When a customer-facing chatbot goes off the rails, the model provider blames your prompt engineering, the platform provider claims infrastructure isolation worked perfectly, and your internal application team swears it’s an upstream model limitation…
Put simply, what are the top 3 differences between shared responsibility for AI vs cloud? In my opinion:
A Broader Spectrum of Risk: The range of harms and risks we must consider is much wider. Shared responsibility for AI security frequently touches upon safety, privacy, ethical use, and the unique risk surfaces that emerge specifically in conversations about AI.
The Multi-Party Supply Chain: AI security is typically far more multi-party than traditional cloud security. For instance, one company builds the foundational model, another company fine-tunes it, a third party builds a Retrieval-Augmented Generation (RAG) architecture for you, and yet another party builds the consumer-facing application.
Non-deterministic Behavior: Unlike traditional cloud infrastructure where secure configurations yield predictable, deterministic outcomes, AI systems are non-deterministic. Because outputs can vary significantly based on user inputs, customers bear increased responsibility for implementing robust guardrails, continuous monitoring, and input/output filtering.
Early attempts to create a logical foundation for AI shared security responsibility produced some answers — and more questions.
In light of this being a tricky problem, here I really want to focus on one thing — a post-incident scenario. While shared responsibility covers numerous use cases (and numerous sources of confusion…), let’s examine a fairly straightforward situation: I am an enterprise end-user company that uses (maybe builds, maybe tunes, etc) AI in some form, then something blows up (digitally, as this is not IoT/ICS security blog). So:
Who takes a loss vs who is to blame?
Do I blame the model creator? The application developer? The model hosting platform? Or do I ultimately blame myself?
If you recall, many early challenges with the cloud shared responsibility model began with customers trying to blame the provider, only to discover they were actually at fault in the end. We tried to change this dynamic by introducing a “shared fate” model. While that specific terminology has seemingly fallen out of favor lately, the underlying philosophy remains: providers can probably do more to make AI usage inherently secure.
We recently wrapped up and approved Version 1.0 of the CoSAI AI Shared Responsibility Framework (AI SRF) through the Coalition for Secure AI and OASIS Open. The core mission here wasn’t to build more abstract compliance theater, but to solve a practical, glaring operational pain point: Who actually owns what when an AI system fails?
Under the CoSAI framework, accountability traces down the stack with absolute clarity:
The AI Model Provider (L5) is accountable for the base model’s inherent susceptibility to prompt injection and must document those boundaries explicitly within the model card.
The Cloud/Platform Provider (L4) is accountable for the blast-radius containment, ensuring infrastructure-level tenant process isolation held firm during the exploitation.
The Application Developer (L3) is accountable for failing to enforce application-level guardrails, input filtering, and localized data access controls that allowed the chatbot to hit the PII repository in the first place.
The Deploying Organization (L1/L2) is accountable for the ultimate governance failure: they did not properly classify the data or restrict the chatbot’s system-level access boundaries before pushing it live.
Layers
Also, the paper included a phased Implementation Playbook in the document to give security teams a somewhat specific path forward:
Phase 1 (Days 1–30): Map your entire AI system inventory and cross-reference vendor contracts against these five layers to highlight immediate responsibility gaps.
Phase 2 (Days 31–90): Establish a cross-layer governance committee and formally update vendor procurement contracts with clean, explicit accountability matrices.
Phase 3 (12 Months): Run layer-specific tabletop simulations to stress-test your incident response playbooks before an actual threat actor tests them for you.
Fun quotes:
“Ambiguous ownership is a growing liability for Al system deployments.” [A.C. — filed under ‘no shit, Sherlock’]
“Without explicitly assigned owners for detection, containment, and remediation, teams default to the finger-pointing cycle” [A.C. — this will get worse, then MUCH worse, then eventually better…]
“The framework turns ‘whose fault is this?’ into ‘which layer’s controls failed, and who owns remediation for each?’” [A.C. — this is beautifully, I probably wrote this :-)]
“There should be exactly one accountable party per component to prevent overlaps.” [A.C. — ideal world called, it wants its problem back! Real world picked up and said ‘get lost’]
“Clear accountability eliminates finger-pointing during incidents” [A.C. — clear evidence that Captain Obvious is alive!]
In the end, I hope this work enlightens people on just how complex this problem truly is. This paper is definitely not a silver bullet that solves everything overnight; we have years of discussions and evolving challenges ahead of us down this path. However, I think this paper serves as an excellent first step. Please make sure to check out the resources listed at the end of the paper as well (a lot of gems there!)
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-12166GFAC_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-12168GFAC_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.
Vendor Information
One or more vendors are listed for this advisory. Please reference the full report for more information.
One particular aspect of an agentic or AI-powered SOC (but NOT “humanless SOC”) has bothered me over the last few months: specifically, the people and process side of such a SOC. If you recall my blog posts (part 1, part 2 and this video) about AI SOC readiness, I hinted at certain elements of a traditional process stack and legacy personnel profiles (both technical and leadership) that make AI adoption inside SOC incredibly difficult.
So we (me and Augusto Barros @ Prophet Security) want to create a modernized people and process framework for a SOC powered by AI and intelligent agents. Otherwise, what I am observing is a lot of “robotic horse pulls a buggy” kind of operations — where everything is kept exactly the same as it was in 2003, but “AI SOC” tools are simply tacked on to perform some of the tasks.
Gemini visual of old SOC with “AI SOC” tools
I believe that people and process components must change far more dramatically, and such changes are a critical requirement for achieving “step change” SOC with AI capabilities. Simply adding AI tools and Ai agents to a 2003-style SOC will produce, at best, marginal results. Things would get better, but not better enough to counter the feared “bad guy with AI.”
The SOAR Analogy
The analogy I want to use here is SOAR adoption from 10+ years ago. Back then, organizations simply shifted a few processes — or even just specific tasks — to a machine, and then kept the rest of their operations exactly the same. Because of that, I observed a lot of SOAR tools being used strictly for alert enrichment or for dealing with one specific, isolated type of alert, like phishing. To follow this analogy to the present day, I now frequently see an “AI SOC” being utilized only for EDR alerts or only for phishing alerts (wow, what a coincidence!)
A First-Principles Approach
What I really want to build is a first-principles approach to the specific personnel, skills, processes, and practices required to run a true agentic SOC in the late 2020s.
Now, if you prefer incremental change, that is OK, I won’t judge. However, you must be aware that the same principles caused organizations to struggle with cloud adoption. People often hear that “lift and shift” is bad. Most consultants will tell you that “lift and shift” is fine as a first step, but you eventually need to modernize and take more steps. Unfortunately, many organizations never make that second step. The same risk applies to the AI SOC. 2003 SOC + AI = somewhat better 2003 SOC.
BTW, many artifacts of the modern, engineering-powered SOC — which we covered in our now-famous ASO (Autonomic Security Operations)paper back in 2021s — apply here as well. In fact, if you recall, one of our core principles was: Humans build machines; machines do the work.
In the context of an agentic SOC, that evolves into:
Today, humans build the machines with the help of other machines, and then the machines do the heavy lifting.
So, our questions so far:
What do humans do in an agentic SOC?
What do entry-level humans do?
What SOC processes stay the same despite AI?
What SOC processes can just go and vanish (triage)?
What processes get handed to machines?
Are there new processes for humans?
What is the new human role for validation?
How do we check AI quality without fully redoing the work?
How SOC metrics must change due to AI and agents? (some ideas)
What do humans and machines do jointly? What does it mean, practically?
How to HITL in a SOC without breaking the humans or machines?
What is the effective mechanism for the human-to-AI feedback loop so that corrections actually improve future SOC performance?
Is “fully automated” detection engineering a realistic goal, or does the dependency on local, inconsistent environment context make it inherently a hybrid human-machine effort?
What do humans do before SOC (TI) and after SOC (IR)?
What is the first step to move from a legacy SOC to an agentic SOC?
Can we run legacy and agentic SOC structures in parallel during transition, or does this duplication create operational friction?
Is it easier to move from a modern non-AI SOC (aka “SOCless D&R”) to an AI SOC?
Looking Ahead
This blog post is just the first part of the series. My goal here is simply to collect the right questions we need to be asking, but I promise we will provide concrete answers in upcoming posts. This research is being undertaken together with my former colleague, Augusto Barros, now at Prophet Security
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.
Vendor Information
One or more vendors are listed for this advisory. Please reference the full report for more information.
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.
Vendor Information
One or more vendors are listed for this advisory. Please reference the full report for more information.
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]
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.
Vendor Information
One or more vendors are listed for this advisory. Please reference the full report for more information.
Login
