Currently browsing: Security

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.

Overview
The SignalRGB kernel driver, SignalIo.sys, contains two vulnerabilities involving improper access control and unsafe memory handling. The device object is created with an overly permissive Discretionary Access Control List (DACL) that allows user-mode processes to access privileged hardware operations through input/output control (IOCTL) commands. Additionally, several IOCTL handlers are susceptible to NULL pointer dereference conditions, which further enables low-privilege users to trigger kernel crashes and cause Denial of Service (DoS). Version 1.3.7.0 of the SignalRGB driver remediates these vulnerabilities.
Description
SignalRGB is a Windows application used for RGB lighting control and hardware monitoring. Its kernel component, SignalIo.sys, provides the low-level interfaces required to access and interact with hardware resources.
The SignalIo.sys driver exposes privileged functionality intended for administrative or security operations, but the device object is created without a restrictive security descriptor. Specifically, the driver does not apply security best practices by using either Security Descriptor Definition Language (SDDL) or the IoCreateDeviceSecure API, thereby allowing unprivileged user-mode processes to open handles to the device and issue privileged IOCTL requests.
CVE-2026-8049 The \.SignalIo device object is created without an explicit SDDL security descriptor and without FILE_DEVICE_SECURE_OPEN. This results in overly permissive default access control, allowing any authenticated local user to obtain a handle to the device and issue privileged IOCTLs.
CVE-2026-8050 Seven of the sixteen IOCTL handlers dereference the SystemBuffer pointer without first verifying that it is non-NULL. Sending an IOCTL with an empty input buffer causes a NULL pointer dereference, resulting in a kernel crash.
Impact
The device’s insufficient access control enables user-mode interaction with privileged IOCTL interfaces and sensitive driver functionality, including read/write access to the PCI configuration space of system devices. Additionally, an authenticated local attacker can trigger repeated kernel crashes by accessing the \.SignalIo device and sending NULL input buffers to any of the seven vulnerable IOCTLs.
Notably, the affected SignalRGB drivers already include custom kernel-enforced port whitelists to block I/O access to several high-risk ports, which helps to limit the scope of sensitive operations available through the IOCTL interface.
Solution
SignalRGB has remediated these vulnerabilities in the recent 1.3.7.0 driver release. Users and organizations should update and/or block the previous vulnerable driver version where possible and implement mitigations designed to reduce exposure to BYOVD attacks, including restricting administrative privileges, enforcing Microsoft’s recommended driver block rules, and enabling protections such as Windows Defender Application Control (WDAC) or an equivalent EDR solution for your environment.
Acknowledgements
Thanks to Shravan Kumar Sheri for researching and reporting this vulnerability, and to SignalRGB for their prompt engagement and remediation efforts. This document was written by Molly Jaconski.

Overview
A vulnerability has been discovered in the Haskell TLS software stack, commonly used by applications built in the Haskell programming language to securely connect to servers over the internet. Specifically, the libraries “crypton-x509-validation” fail to enforce a key security feature called NameConstraints, a standard defined in RFC 5280 that helps organizations control which domains a certificate authority (CA) is allowed to issue certificates for. This vulnerability allows an attacker with access to the sub-CA to create certificates that will validate successfully with any Haskell TLS connection, allowing the attacker access to full session visibility. Version 1.91 for crypton-x509-validation have been released to address the vulnerability, tracked as CVE-2026-9648.
Description
Haskell is a programming language often used in enterprise, academic, and financial systems such as banks, insurance companies, and data processing platforms, which use it for backend services like fraud detection, risk modeling, and other sensitive connections. The Haskell TLS software stack is the implementation used by Haskell applications to establish secure HTTPS or TLS connections to servers, just like OpenSSL or Go’s TLS libraries do in other ecosystems. A vulnerability has been discovered within the stack; crypton-x509-validation, which do not enforce the NameContstraints security feature that other libraries, such as OpenSSL or Go, do.
The description for CVE-2026-9648 is as follows:

The crypton-x509-validation Haskell library fails to enforce X.509 NameConstraints, allowing TLS clients to accept certificates whose Subject Alternative Names fall outside the issuing CA’s permitted subtrees. This oversight enables an attacker who compromises a name-constrained sub-CA to impersonate domains beyond its intended scope.

NameConstraints are a security mechanism in digital certificates that tell a CA exactly which domains it’s allowed to issue certificates for. The crypton-x509-validation, which handle certificate validation in Haskell’s TLS connections, ignore these constraints entirely, so they never check whether a certificate’s Subject Alternative Name (SAN) falls within what the issuing CA is permitted to cover.
This enables a threat actor who gains access to a sub-CA key to create a certificate that includes a SAN for a protected domain, tricking Haskell clients into accepting it and enabling full impersonation of those services. Practically, a TA could set up a web server presenting the malicious CA, tracking any Haskell client to connect to the malicious web server, allowing them to capture any credentials or sensitive data transferred during the process.
Impact
An attacker that successfully exploits CVE-2026-9648 can capture any traffic sent between a Haskell client to their server, potentially giving access to sensitive financial information, credential theft, and secret theft.
This vulnerability is likely to affect industries that use delegated PKI structures, or structures that allow delegated systems to create and assign their own CAs. This is typical in banks or other financial industries.
Solution
The vulnerability requires considerable setup and victim interaction in order to be successful, but vulnerable parties should update their libraries to version 1.9.1 of the crypton-x509-validation libraries as soon as possible, as all version prior are vulnerable.
Acknowledgements
Thanks to the reporter, Ben Smyth.This document was written by Christopher Cullen.

Overview
Microsoft-signed UEFI bootloaders of the open-source shim project, primarily from version 0.9 and earlier, were identified as vulnerable to Secure Boot bypass. To mitigate this risk, the affected bootloaders will be added to the Microsoft UEFI Forbidden Signature Database (DBX). Once the DBX update is applied, these bootloaders will no longer be trusted for execution during the boot process.
An attacker could exploit these vulnerable shim bootloaders using a Bring Your Own Vulnerable Driver (BYOVD)-style technique to execute arbitrary code during the early boot phase, prior to operating system initialization, thereby bypassing Secure Boot protections.
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 the “Microsoft Corporation UEFI CA 2011” certificate. This Microsoft certificate is widely used to sign third-party boot components intended to run under Secure Boot.
The open-source UEFI shim project is a small, signed bootloader that Microsoft signed using the “Microsoft Corporation UEFI CA 2011” certificate. Shim acts as a bridge between the motherboard’s UEFI firmware and the operating system (typically a Linux distribution). Its purpose is to allow Linux distributions to boot with Secure Boot enabled without requiring every individual distribution’s key to be built into the motherboard’s NVRAM settings. In doing so, shim allows Linux distributions and other third parties to establish their own trust model through the use of Machine Owner Keys (MOKs), enabling additional bootloaders, kernels, and related components to execute within the Secure Boot chain. The shim project also introduced Secure Boot Advanced Targeting (SBAT), which provides a version-based revocation mechanism for boot components and simplifies future security updates and revocations.
Over time, multiple security vulnerabilities were identified and corrected in the upstream shim project. However, a number of vendors had previously forked or customized older versions of shim for their own products and boot environments. In many cases, these vendor-specific bootloaders were not updated after vulnerabilities in the upstream project became publicly known. As a result, vulnerable bootloaders remained signed and trusted by Secure Boot systems because they had not been revoked through the Microsoft-signed DBX revocation list. This created a long-term supply chain exposure in which outdated and vulnerable boot components could still be executed on fully patched systems.
Researchers from ESET identified multiple vulnerable shim bootloaders affected by these issues. The affected bootloaders will be added to Microsoft’s official DBX revocation list as part of this coordinated disclosure.

Impacted shim bootloaders
[Vendor and Product Information
Authenticode SHA hash
SHA256 file hash
CVE ID]

Spyrus WTGCreator () from UEFI shim loader(0.7 (or lower))
AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961
1D18DF4B15D3BC3DFFA1777A557075210DD0C53B
CVE-2026-8863

RedHat RedHat Enterprise Linux (7.2) from UEFI shim loader(0.9)
7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10
3F24DD838C5C9E35B104FA2F3B74AC6A5BF92FD2
CVE-2026-10797

RedHat CentOS (7.2) from UEFI shim loader(0.9)
EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A
E133BE08E8AD17AC00E3C8ED215499C5F3C54E64
CVE-2026-10797

baramundi software baramundi Management Suite (up to 2024R1) from UEFI shim loader(0.8)
FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5
8637D7EFA23A8A5738F2E4AACB6C9919B405AA2C
CVE-2026-8863

WhiteCanyon/Blancco WipeDrive (versions 8.0.0 through 8.1.3.) from UEFI shim loader(0.7)
a0de9333442c1bf9349a460141ae5e80f911955c6506040fa3d021bf6c1ae3e4
8A402AFCD3C23D9253BBEA08576113C63E448AD0
CVE-2026-8863

Finland’s Matriculation Examination Board Abitti 1 (1.0) from UEFI shim loader(0.8)
95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06
8A83FA30DBF0073F33EAD298A7D5CD69A47C3A4B
CVE-2026-8863

NTC IT ROSA, LLC ROSA Linux (R10, R9) from UEFI shim loader(0.9)
236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B
8F9E8DB8E2C2157C2A591F2BE070FF96BFE318C7
CVE-2026-8863

Oracle America, Inc. OracleLinux (7.2) from UEFI shim loader(0.9)
5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B
A16136899A12AD214FA4FBA60072BA72FBAB8BCA
CVE-2026-8863

PC-Doctor, Inc. PC Doctor Service Center (15, 16) from UEFI shim loader(0.9)
8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963
BC01320D8FF8343B348EF8F3C947A66EB8FD9CE2
CVE-2026-8863
OpenSuse OpenSuse UEFI Shim loader (0.9)
410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373
3CF8BEB1E2885F51CA04002425C4F3C796D105BC
CVE-2026-8863

OpenSuse OpenSuse Shim (2.1) from UEFI Shim loader (0.9)
96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629
6DB5266E80C9D51CDD54421E736DF2E6E6879A56
CVE not provided

Impact
An attacker with administrative privileges or the ability to modify the boot process could use one of the vulnerable shim bootloaders to bypass Secure Boot protections and execute arbitrary code before the operating system loads. Code executed during this early boot phase may achieve persistent compromise of the platform, including the ability to load unsigned or malicious kernel components that can survive system reboots and, in some cases, operating system reinstallation. Because this activity occurs before the operating system and many security products initialize, malicious code executed through this technique may evade detection by operating system security controls and Endpoint Detection and Response (EDR) solutions.
Solution
Apply a Patch
Apply the latest software updates along with latest bootloader updates as provided by your hardware or software vendor. See the Vendor Information section for details. Updated software should replace any vulnerable shim bootloaders with versions that incorporate the latest upstream security fixes and SBAT protections. Additionally, Microsoft DBX updates should be applied to all UEFI-based systems to ensure that vulnerable bootloaders can no longer be executed during the Secure Boot process.
Recommendations for Enterprises and Developers
Because modifications to the DBX (Forbidden Signature Database) can affect system boot behavior, vendors and administrators should thoroughly test these updates before broad deployment to ensure systems remain bootable. When deploying Secure Boot updates, it is recommended the latest authorized signature database (DB) is updated before applying DBX revocations. In practice, this means updating trusted boot applications and certificates first, followed by deployment of the revocation list. Failure to follow this order may cause systems to reject newly updated boot components. Enterprises, virtualization providers, and cloud operators managing large-scale deployments should prioritize validation and deployment of these updates to prevent the execution of vulnerable or unsigned binaries during physical or virtual machine startup. Microsoft also provides DBX update files and related tooling through the following repository: SecureBoot Objects
Audit tools such as Check-UEFISecureBootVariables for Windows systems using PowerShell, and uefi-dbx-audit for Linux systems, can be used to help verify that current DBX updates have been applied to UEFI-based laptops, desktops, servers, and virtual machines with Secure Boot enabled. These tools can also assist enterprise administrators in identifying revoked or vulnerable boot components present on a system. Audit and verification capabilities may vary depending on platform firmware implementation and support for revocation mechanisms such as SBAT and the newer Microsoft-specific Secure Version Numbering (SVN) enforcement.
Acknowledgements
Thanks to Martin Smolar of ESET for researching and reporting this vulnerability. This document was written by Vijay Sarvepalli.

Overview
Version 3.0.7 of the Securly Chrome Extension contains multiple vulnerabilities involving insecure data transmission, weak cryptography, and improper access control. These issues may expose sensitive filtering rules, enable the manipulation of downloaded configuration files, and allow unauthenticated access to protected resources. An attacker could exploit these weakness to steal configuration information, induce a Denial of Service (DoS), or modify content blocking rules for student users.
Description
The Securly Chrome Extension is a browser add-on commonly used in K–12 school-managed Chromebooks to enforce internet safety policies, filter or block websites, and provide activity monitoring for students. It is an element of the Securly classroom management platform, which helps schools comply with web filtering requirements and safely manage student online access.
CVE-2026-8874
Version 3.0.7 of the Securly Chrome Extension downloads JSON files containing crisis alert keywords and filtering rules over unencrypted HTTP via the Fetch API. Other endpoints in the same extension correctly fetch Internet Watch Foundation (IWF) and Children’s Internet Protection Act (CIPA) data over HTTPS, demonstrating an inconsistent implementation of TLS.
CVE-2026-8876
The Securly Chrome Extension contains hardcoded, plaintext AES passphrases in securly.min.js. These keys decrypt crisis alert keyword data and intervention site data.
CVE-2026-8878
The Securly Chrome Extension exposes multiple publicly accessible endpoints that allow unauthenticated access to sensitive data. The exposed information consists of SHA-1 hashes that are inadequately obfuscated using a simple Caesar cipher, which can be easily reversed to recover the original hash values and access the protected data.
CVE-2026-8879
The Securly Chrome Extension dynamically registers content13.min.js as a content script via chrome.scripting.registerContentScripts() at runtime. This script is NOT declared in manifest.json and bypasses Chrome Web Store static security review. It runs on all URLs and immediately hides all page content, creates a full-page overlay, pauses all videos, and only restores content when the service worker confirms the page passes filtering. If Securly’s servers are unreachable, pages remain indefinitely hidden.
CVE-2026-8881
The Securly Chrome Extension uses EVP_BytesToKey key derivation with MD5 and a single iteration for AES encryption. MD5 has been broken since 2004 and a single iteration provides no key stretching. This weak derivation method significantly reduces the effective security of the encryption, making the protected data vulnerable to efficient offline cracking.
CVE-2026-8888
The Securly Chrome Extension downloads config.json over HTTP and compiles server-provided patterns as JavaScript regular expressions via new RegExp() without complexity validation. An on-path attacker can inject specific patterns to cause catastrophic backtracking, resulting in denial of service on all browsing.
CVE-2026-8889
The Securly Chrome Extension uses deprecated SHA-1 hashing for IWF CSAM URL matching (25,020 hashes) and CIPA blocklist matching (12,352 hashes).
Impact
These vulnerabilities collectively enable multiple attack paths and threaten the security and privacy of student users, for which the extension may be academically mandatory. The HTTP configuration downloads (CVE‑2026‑8874, CVE‑2026‑8888) and weak cryptographic primitives (CVE‑2026‑8876, CVE‑2026‑8881, CVE‑2026‑8889) allow a network‑adjacent attacker to intercept, modify, or decrypt data related to keyword filtering. The presence of unauthenticated, publicly accessible endpoints with trivially reversible obfuscation (CVE‑2026‑8878) further exposes internal keyword lists, blocklists, and rule definitions. These weaknesses enable the reconstruction and manipulation of the extension’s filtering logic. For student users, this could result in exposure to content that the filtering system is intended to block, or the inappropriate blocking of legitimate educational resources. Additionally, the undeclared, dynamically‑registered content script (CVE‑2026‑8879) can be abused to fully obscure web pages, leading to DoS conditions for end users.
Solution
Unfortunately, Securly could not be reached for coordination of these vulnerabilities. Until a patch is available, administrators can lower their potential exposure by restricting usage of the extension on untrusted or public networks, installing school-managed VPNs on the underlying devices, and monitoring for unexpected or abnormal filtering behavior.
Acknowledgements
Thanks to the reporter Santh for discovering and researching these vulnerabilities. This document was written by Molly Jaconski.

Overview
VoLTE deployments on Verizon’s IMS network have operated without negotiated SIP integrity protection. In observed test conditions, SIP signaling—including registration, call setup, and messaging—traveled without IPsec ESP encapsulation and without SIP Security Agreement headers, exposing it to interception and modification by on-path attackers.
Recent carrier configuration updates, including Apple’s iOS 26.5 carrier bundle released on May 11, 2026, include IMS IPsec–related settings. However, such configuration entries do not confirm active deployment, successful negotiation, or functional protection in production.
Description
CVE-2026-10629
Verizon IMS deployments were observed transmitting SIP signaling without integrity protection. REGISTER exchanges lacked Security-Client, Security-Server, and Security-Verify headers, and no ESP-encapsulated SIP traffic was detected during subsequent signaling such as INVITE, MESSAGE, BYE, and UPDATE. This pattern persisted across devices, operating systems, and network conditions, indicating a deliberate network configuration rather than a transient issue.
Per 3GPP TS 33.203 and GSMA IR.92, SIP signaling between the UE and P-CSCF must be protected using IPsec ESP following IMS AKA authentication, with negotiation occurring during registration. The absence of this protection allows attackers to manipulate SIP signaling undetected, enabling call hijacking, spoofing, denial-of-service, and misrouting of emergency calls.
Verizon initially acknowledged the issue and stated that integrity support would be available upon request and extended broadly later in the year. However, the company has since ceased participation in coordination, including follow-up discussions and draft review, and has not provided verifiable evidence of mitigation. As remediation remains unconfirmed, this disclosure proceeds to inform users of an ongoing security exposure.
Independent verification would require observation of successful SIP security negotiation, ESP-protected traffic, or official confirmation from Verizon.
Impact
Without integrity protection, on-path attackers can intercept, replay, or alter SIP messages with no risk of detection. This undermines core VoLTE security assumptions and enables signaling spoofing, call disruption, and manipulation of emergency routing.
Although recent configuration changes suggest potential progress, their operational status remains unverified. Until protections are confirmed, the risk persists.
Solution
Remediation requires coordinated network and device-side changes. Verizon must enable and enforce SIP security negotiation and ESP protection in its IMS core infrastructure, and devices must receive and apply correct carrier configuration to support IPsec.
Verification should confirm successful SIP security negotiation and ESP-protected signaling, either through observed headers, traffic capture, or operator confirmation.
Until then, organizations relying on high-assurance VoLTE should treat signaling as untrusted
Acknowledgements
The authors thank DongWon Lee, Jeongmin Choi, and CheolJun Park from Kyung Hee University for their technical analysis, coordination efforts, and identification of the iOS 26.5 configuration updates. Their work has advanced understanding of this issue and ensured disclosures remain grounded in observable evidence.
This report was prepared by Timur Snoke, with AI-assisted drafting to support clarity and accuracy.

Overview
A stored cross-site scripting (XSS) vulnerability has been discovered in Appsmith, specifically in the CodeMirror based SQL query editor’s autocomplete renderer. CVE-2026-7299 has been assigned to track the vulnerability. An attacker with developer level access to a shared PostgreSQL datasource can inject arbitrary JavaScript by creating malicious database objects whose names contain XSS payloads. Successful exploitation leads to arbitrary JavaScript execution in the browser of any workspace member who triggers SQL autocomplete, enabling session hijacking, privilege escalation, or credential theft. Version 2.1 of Appsmith fixes CVE-2026-7299.
Description
Appsmith is an open source, low code platform intended to allow developers to build internal tools, dashboards, and applications using a UI builder, database and API integrations, and JavaScript customization. Appsmith can also be deployable either self-hosted or via the cloud. A vulnerability, tracked as CVE-2026-7299, has been discovered, allowing for XSS within the SQL query editors autocomplete function.
The vulnerability description is below.
CVE-2026-7299
Appsmith’s SQL query editor’s autocomplete functionality fails to sanitize database object names before rendering them in innerHTML, allowing an authenticated Developer to inject persistent XSS by a malicious table or column names triggering arbitrary code execution in the sessions of other workspace members when they interact with the same datasource.
This vulnerability requires an account with developer access. A developer Appsmith account is an account designed to create, edit, and delete apps within a workspace they are assigned to. When an administrator opens the SQL editor and triggers autocomplete (e.g., by typing SELECT * FROM), the malicious table name executes their stored payload, which can allow for privesc.
Impact
Successful exploitation of CVE-2026-7299 leads to arbitrary code execution in the browser of any workspace member who triggers SQL autocomplete, enabling session hijacking, privilege escalation, or credential theft.
Solution
Version 2.1 of Appsmith fixes this vulnerability. Users should update their installations as soon as possible.
Acknowledgements
Thanks to the reporter, Stuart Beck. This document was written by Christopher Cullen.vrf26-04-DQBSN_exploit.py

Overview
The Collibra Platform Agent contains vulnerabilities that can be chained by a remote, unauthenticated attacker to achieve remote code execution. An attacker can exploit these issues by uploading a crafted ZIP archive that writes attacker-controlled files to arbitrary locations on the server once extracted, resulting in code execution.
Description
Collibra Platform (CP) and Collibra Platform Self-Hosted (CPSH), an enterprise grade, cloud-based platform designed to help organizations locate, understand, trust, and manage their data assets. The Collibra Agent of CP and CPSH that is installed on the host system is an independent service that listens on different port than the web interface and have the following vulnerabilities.
CVE-2026-10622 Privileged REST endpoints exposed under /rest/* do not properly enforce authentication or authorization. This allows a remote, unauthenticated attacker to interact with sensitive application functionality and gather information useful for further exploitation, including identifying suitable filesystem locations or application paths.
Additionally, the web services hosting the vulnerable REST endpoint was observed to bind to all available network interfaces regardless of the setting passed to the installer script. This behavior may increase exposure in deployments where administrators believe access is restricted to specific interfaces or trusted networks.
CVE-2026-10621 A Zip Slip vulnerability during extraction is exposed through POST /rest/restore and enables path traversal. When a ZIP archive is processed, file paths contained within the archive are not properly validated or canonicalized before extraction.
A remote attacker can supply a crafted ZIP archive containing directory traversal sequences, such as ../, to write files outside of the intended extraction directory. This may allow attackers to write custom files to arbitrary locations on the underlying host.
In an observed exploitation path, this arbitrary file write can be used to place a malicious JSP file into a web-accessible directory, enabling remote code execution when the file is subsequently requested over HTTP.
Impact
A remote, unauthenticated attacker can chain these vulnerabilities to achieve remote code execution on the affected system. An attacker who successfully exploits these issues may be able to:
– install a persistent web shell
– read, modify, or delete application data
– disrupt system availability
– potentially pivot further into surrounding environment
Because exploitation does not require authentication, deployments reachable across public internet may be at significant risk.
Solution
Collibra has released the following versions to address these vulnerabilities.
Collibra Plaform (SaaS):
2026.05
2026.04.5
2026.03.4
2026.02.6
2025.11.7
2025.10.9
Collibra Platform Self Hosted (on-prem):
2026.03 (Build 2026.03.356)
2025.10 (Build 2025.10.399)
Users are strongly encouraged to update to the fixed release as soon as possible. Refer to Collibra documentation and release notes for patching and deployment guidance.
Administrators should ensure that interfaces exposing REST endpoints are not exposed to untrusted networks and should restrict access to management interfaces wherever possible.
Acknowledgements
Thanks to the reporter who wishes to remain anonymous. This document was written by Michael Bragg.
VU#873170.2
Path traversal in restore handler in Collibra Agent, allows an attacker to write arbitrary files via a crafted ZIP archive. Collibra Agent fails to properly validate and canonicalize file path during ZIP extraction, this can allow an attacker to write files outside the intended extraction directory.
VU#873170.1
Improper Authentication in REST API in Collibra Agent, allows a remote unauthenticated attacker to access privileged functionality via exposed /rest/* endpoints.