US-CERT.gov

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:

1. Disable or restrict WinRE on systems where recovery functionality is not operationally required.
2. Require administrative authorization with ephemeral one-time access before enabling or invoking recovery environments.
3. Enable BitLocker with TPM + PIN or TPM + Startup Key to ensure additional authentication is required during recovery and pre-boot scenarios.
4. Enable restrictions of pluggable media with EFI System Partitions (ESP) and any modifications to sensitive items in UEFI NVRAM such as BootNext and BootOrder.
5. 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.
6. 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. 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 coordination 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 pending from vendor RedHat CentOS (7.2) from UEFI shim loader(0.9) EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A E133BE08E8AD17AC00E3C8ED215499C5F3C54E64 CVE pending from vendor baramundi 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 Shim (10.1) from UEFI Shim loader (0.9) 410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373 3CF8BEB1E2885F51CA04002425C4F3C796D105BC CVE not provided 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 historically lacked IPsec-based integrity protection for SIP signaling, contravening well-established requirements in 3GPP TS 33.203 and GSMA IR.92. As a result, SIP messages—including registration (REGISTER), call setup (INVITE), and messaging (MESSAGE)—were transmitted in plaintext without cryptographic guarantees of integrity or authenticity. Passive analysis of live traffic over multiple months confirmed the consistent absence of SIP Security Agreement headers and ESP traffic, indicating a systematic configuration decision rather than an isolated anomaly.

In response to repeated follow-up inquiries, Verizon stated on [insert date] that integrity support is “currently available at their request” and will be extended to all UEs “starting later this year.” Separately, the researchers recently observed that Apple’s iOS 26.5 carrier bundle (released May 11, 2026) includes IMS IPsec-related configuration entries—an indication that device-side support may now be active or enabled in newer software. While this change is promising, its real-world impact remains uncertain: there is no evidence yet that Verizon has modified its network to enforce IPsec, that the configuration is being activated per session, or that integrity is functionally operational in production deployments. Absent explicit verification (e.g., captured ESP traffic or official confirmation), this may reflect preparatory software changes rather than an end-to-end security upgrade.

The vulnerability remains active for the vast majority of Verizon VoLTE users during the unprotected period, and until network-level enforcement is observed and confirmed, the risk of on-path signaling manipulation endures.

Description

VU#615987.1
SIP signaling stack in Verizon IMS (unspecified version) implements SIP signaling without IPsec integrity protection (missing Security-Client/Security-Server headers and ESP traffic), which allows an on-path attacker to compromise confidentiality, integrity, and authenticity of VoLTE signaling via passive monitoring and active manipulation of unsecured SIP messages over the radio and core network.

According to 3GPP TS 33.203 and GSMA IR.92, SIP signaling between the UE and P-CSCF in IMS networks must be protected using IPsec ESP with mandatory integrity following IMS AKA authentication. This protection is negotiated via SIP Security Agreement headers (Security-Client, Security-Server, Security-Verify) during registration and results in integrity-protected ESP traffic for all subsequent signaling messages.

However, observations conducted over several weeks on Verizon’s network showed no such headers in use. The REGISTER exchange lacked any security negotiation, and post-registration SIP traffic—including INVITE, MESSAGE, BYE, and UPDATE—traversed the network in plaintext over standard UDP/TCP, with no ESP encapsulation. This pattern was consistent across device models and network conditions, indicating a systemic configuration decision rather than a transient issue. The absence of integrity checking means any modification to SIP messages—including redirection of emergency calls or injection of fake message payloads—would go undetected by both the UE and the IMS core.

No technical justification for this deviation from globally adopted security practices has been provided by Verizon, and prior engagement failed to elicit a substantive response beyond the recent, non-binding commitment to future deployment.

Impact

The lack of IPsec integrity protection enables on-path attackers—including those controlling femtocells, compromised base stations, or IMS intermediaries—to intercept, modify, replay, or inject SIP messages without detection. These capabilities permit call hijacking, spoofing of SMS-over-IMS, denial-of-service through forged BYE or CANCEL, and manipulation of emergency call routing—without requiring compromise of the UE, SIM, or backend infrastructure. Because SIP signaling lacks cryptographic integrity, all such modifications go unnoticed by both the UE and the IMS core, undermining core security assumptions of VoLTE. While the recently observed iOS 26.5 configuration change may signal progress toward a more secure implementation, its operational impact is yet to be demonstrated; until then, the risk remains real and unmitigated for users on unprotected deployments.

Solution

Until the vulnerability is fully mitigated by Verizon, users and enterprises should continue to assume VoLTE signaling is untrusted for high-assurance operations.

Acknowledgements

Thanks to DongWon Lee, Jeongmin Choi, and CheolJun Park from Kyung Hee University for their thorough technical report, persistent follow-up efforts, and the additional observation regarding iOS 26.5. Their work has significantly advanced the understanding of this issue and helped keep the discussion grounded in observable behavior.
This AI-assisted document was written by Timur Snoke.

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.

Overview

The PCTCore64.sys Windows kernel driver from PC Tools Internet Security exposes its \\.\PCTCoreDriver device interface with no access control, allowing any user-mode process to interact with the driver and invoke privileged IOCTL (I/O Control) commands. In a Bring Your Own Vulnerable Driver (BYOVD) scenario, a local attacker with the ability to load a Windows driver can exploit the exposed interface to perform sensitive low-level operations on the target device.

Description

PCTCore64.sys is a Windows kernel driver that implements system monitoring and protection functionality on local Windows systems. The driver creates a Windows Driver Model (WDM) device object \\.\PCTCoreDriver via IoCreateDevice and provides user-mode access through a DOS device symbolic link via IoCreateSymbolicLink.

The driver exposes privileged functionality intended for administrative or security operations; however, the device object is created without a restrictive security descriptor. Specifically, the driver does not apply security best practices using either Security Descriptor Definition Language (SDDL) or the IoCreateDeviceSecure API, allowing unprivileged user-mode processes to open handles to the device and issue privileged IOCTL requests.

As a result, an attacker may invoke IOCTL handlers capable of performing sensitive low-level operations, including:

• System-wide handle enumeration
• Cross-process handle manipulation
• Credential extraction from lsass.exe
• Forced termination of arbitrary processes, including Protected Process Light (PPL)-protected processes

Although the original PC Tools Internet Security product line was discontinued in 2013 and is no longer maintained, the driver remains signed and can still be abused in BYOVD attacks. An attacker may load the vulnerable driver on a target system and leverage the exposed IOCTL interface to access privileged kernel functionality.

One vulnerable IOCTL permits the acquisition of a PROCESS_ALL_ACCESS handle to sensitive processes such as lsass.exe, enabling credential theft operations including extraction of NTLM hashes and Kerberos authentication material. Additional IOCTL handlers permit the termination of arbitrary processes regardless of PPL protections, enabling attackers to disable security software such as Microsoft Defender and other critical system services. Other exposed interfaces enable arbitrary handle operations against external processes, potentially resulting in process instability, crashes, or undefined behavior. Collectively, these vulnerabilities can be exploited to provide a practical attack path for credential theft, defense evasion, privilege escalation, and broader system compromise.

CVE-2026-8501 Improper access control in the PCTCore64.sys Windows kernel driver from PC Tools Internet Security allows user-mode processes to access the PCTCoreDriver WDM device interface and invoke privileged IOCTL handlers. A local attacker with the ability to access or load the affected driver can exploit this vulnerability to perform sensitive and privileged operations on the target system.

Impact

A local attacker with the ability to load a Windows kernel driver may exploit the vulnerable PCTCore64.sys driver to access sensitive processes such as lsass.exe and other PPL-protected services. Successful exploitation can enable credential theft, arbitrary process termination, denial-of-service (DoS) conditions, and broader system compromise through privileged kernel-level operations.

Solution

The PC Tools Internet Security product line and its PCTCore64.sys driver are no longer actively maintained and should not be used in production environments. Organizations should remove and block the vulnerable driver where possible and implement mitigations designed to reduce exposure to BYOVD attacks, including restricting administrative privileges, enforcing Microsoft recommended driver block rules, and enabling protections such as Hypervisor-Protected Code Integrity (HVCI), Windows Defender Application Control (WDAC), and Credential Guard.

Acknowledgements

Thanks to Tzachi Hazan for researching and reporting this vulnerability. This document was written by Molly Jaconski.

Overview

Casdoor versions 2.362.0 and earlier contain several identity and access management vulnerabilities that enable broad authentication bypass and privilege escalation. These flaws relate to Casdoor’s Security Assertion Markup Language (SAML) processing, account binding, and token exchange mechanisms. An attacker able to interact with Casdoor’s authentication interface may impersonate users, bypass multifactor authentication (MFA), forge and replay assertions, and achieve persistent unauthorized access.

Description

Casdoor is an open-source identity and access management (IAM) platform and Model Context Protocol (MCP) gateway that provides authentication, single sign-on, and multi-protocol identity services. It is designed to centralize and streamline access control, allowing organizations to manage user identities and permissions across multiple applications and environments.

CVE-2026-9090
Casdoor versions 2.362.0 and earlier contain a vulnerability that allows an attacker to bypass authentication by supplying an arbitrary signing certificate. The buildSpCertificateStore function extracts the X.509 certificate directly from the incoming SAMLResponse instead of using the trusted pre-configured Identity Provider certificate, allowing an attacker to forge assertions signed with an attacker-controlled key.

CVE-2026-9091
A logic flaw in Casdoor's social‑login binding flow allows users to bypass configured MFA requirements. The binding‑rule code path in controllers/auth.go calls HandleLoggedIn directly without invoking checkMfaEnable. Any user authenticating via this path is logged in without MFA enforcement.

CVE-2026-9092
Casdoor contains a vulnerability involving unverified email binding that may enable account takeover. The getExistUserByBindingRule function matches users by email address without checking the email_verified claim returned from upstream providers, and the idp.UserInfo struct does not include a EmailVerified field. Therefore, an attacker can supply an unverified email claim from an upstream provider to take over accounts that use the same email address.

CVE-2026-9093
Casdoor's SAML service provider implementation does not validate the AudienceRestriction element in SAML assertions. Casdoor never sets the AudienceURI field to specify which service provider the assertion is intended for, and does not check for audience mismatch warnings alerted by WarningInfo.NotInAudience. As a result, Casdoor may improperly accept assertions that were issued for a different service provider.

CVE-2026-9094
Casdoor contains a vulnerability that enables cross-organization token exchange. The GetTokenExchangeToken function in object/token_oauth.go validates JWT signatures but does not verify that the token's user belongs to the same organization as the target application. This can result in privilege escalation across organizational boundaries.

CVE-2026-9095
Casdoor maps SAML assertions to user sessions without replay protection. The ParseSamlResponse() function in object/saml_sp.go calls sp.RetrieveAssertionInfo() and immediately maps the result to a user session. There is no assertion ID cache, OneTimeUse condition enforcement, or replay detection anywhere in the SAML SP code path. As a result, an attacker can replay a previously captured SAML assertion to obtain an authenticated session for the assertion’s subject, including administrator accounts, without needing the user’s password or MFA credentials.

CVE-2026-9096
Casdoor does not enforce SAML assertion time bounds. The gosaml2 library reports all time-validation results, including NotOnOrAfter and NotBefore, in the assertionInfo.WarningInfo field. However, ParseSamlResponse() never reads this field, meaning that time bounds are computed by the library but silently discarded before the user session is issued.

CVE-2026-9097
Casdoor does not verify that a JWT used for token exchange is still active. The GetTokenExchangeToken() function in object/token_oauth.go validates the JWT signature and parses its claims, but never queries the Token table to verify whether the subject token has been revoked or invalidated. Because the revocation check is entirely absent, administrators are unable to terminate active sessions or revoke compromised tokens.

CVE-2026-9098
The SAML callback handler in controllers/auth.go accepts any well-formed SAMLResponse sent to /api/acs without verifying that it corresponds to an AuthnRequest previously issued by Casdoor. Additionally, if an administrator disables or deletes an identity provider (IdP) after a SAML flow has started, the handler still processes the response using the provider snapshot loaded at the start of the request. As a result, an attacker controlling a registered upstream IdP can send unsolicited SAML responses, or replay a legitimately captured response in a different session or after the original flow has ended. In both cases, Casdoor accepts the response and issues a session, enabling persistent unauthorized access.

Impact

Exploitation of these vulnerabilities can allow attackers to impersonate users, bypass authentication controls, and escalate privileges across Casdoor deployments.

CVE‑2026‑9090, CVE‑2026‑9093, CVE‑2026‑9095, CVE‑2026‑9096, CVE‑2026‑9098:
Multiple flaws in SAML processing allow assertion forgery or replay, misuse of assertions across sessions, and the processing of expired or unsolicited SAML responses. Because certificate trust is not enforced, time bounds and audience restrictions are ignored, and responses are not correlated to prior AuthnRequests, attackers can submit malicious or previously-captured assertions to obtain authenticated sessions for arbitrary users, including administrators.

CVE‑2026‑9091, CVE‑2026‑9092:
Weaknesses in MFA protection and binding logic further contribute to the risk of account compromise, enabling attackers to bypass MFA and potentially take over other accounts via unverified email claims. An attacker can exploit these flaws to gain persistent unauthorized access by bypassing configured authentication requirements or security controls.

CVE‑2026‑9094, CVE‑2026‑9097:
The discovered token-exchange flaws enable cross‑organization privilege escalation and prevent administrators from reliably revoking tokens. Because user‑organization membership is not validated and token revocation status is not checked, compromised or malicious tokens may be exchanged for elevated privileges in other organizations, and administrators cannot reliably terminate active sessions.

Solution

Unfortunately, we were unable to reach the Casdoor team to coordinate this vulnerability, and a patch is not yet available. Users are advised to implement stricter identity governance controls and utilize external validation tools to better enforce application boundaries. Restrict identity provider (IdP) usage only to trusted providers, reinforce high-privilege accounts with additional authentication paths such as downstream MFA, and monitor logs for any unusual SAML or token activity to reduce the exploitability of these issues.

Acknowledgements

We extend our thanks to Zixu (Jason) Zhou (University of Toronto, PhD student), David Lie (University of Toronto, Professor), Ilya Grishchenko (University of Toronto, Postdoc), and Xiangyu Guo (University of Toronto, PhD student) for researching and reporting these vulnerabilities. This document was written by Molly Jaconski.

Overview

A privilege escalation vulnerability, nicknamed "Dirty Frag," has been discovered in the Linux kernel versions 4.10 and later. This vulnerability is a result of chaining together two previously discovered vulnerabilities, xfrm-ESP Page-Cache Write CVE-2026-43284 and the RxRPC Page-Cache Write CVE-2026-43500. This vulnerability was publicly disclosed on May 07, 2026.

Description

Dirty Frag is a Linux kernel vulnerability affecting the IPv4/IPv6 fragmentation and reassembly subsystem. The issue stems from improper handling of overlapping or malformed fragment offsets during the reassembly process. An attacker capable of sending crafted network packets to a vulnerable host can exploit the flaw to trigger memory corruption conditions.

The publicly documented proof of concept demonstrates that fragmentation logic can be manipulated such that the kernel processes inconsistent fragment states, enabling a controlled write out-of-bounds scenario. When successfully exploited, this can result in local or remote denial of service (kernel panic) and, depending on configuration and kernel build options, may create a primitive for more advanced memory manipulation.

The vulnerability arises from insufficient validation of fragment metadata during reassembly, specifically around:

• Incorrect or incomplete enforcement of fragment boundary checks
• Acceptance of overlapping fragments in unsafe sequences
• Inadequate cleanup when transitions occur between valid and invalid fragment states

The fragment queue logic in affected kernels does not fully verify that fragment offsets, sizes, and overlap conditions remain consistent throughout reassembly. This allows malformed sequences to be processed without proper rejection.

Impact

The primary security concern is potential privilege escalation, similar in nature to the previously disclosed VU#260001 ("Copy Fail") vulnerability.

Depending on system configuration, kernel hardening features, and network exposure, successful exploitation may result in:

• Local or remote denial of service through kernel panic
• Memory corruption within the Linux networking stack
• Privilege escalation
• Container escape in certain containerized environments
• Additional exploit primitives when chained with other vulnerabilities

Solution Update Linux distribution

Update your distribution’s kernel package as soon as vendor patches become available. Most major Linux distributions are expected to release fixes through their standard update channels.

Workarounds (if patching is not immediately possible):

1) Disable at-risk modules (if loaded and loadable):
Use the following command to remove the modules in which the vulnerabilities occur and clear the page cache.
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; echo 3 > /proc/sys/vm/drop_caches; true"

Note: you can verify if a module is currently being used using lsmod and the Used field or reviewing refcnt data in /sys/module/<module_name>/refcnt for e.g., cat /sys/module/esp4/refcnt

2) If affected modules esp4, esp6, rxrpc are compiled into the kernel (not a dynamic module), the following parameter can be added to grub, systemd-boot, or grubby, depending on your boot configuration:
initcall_blacklist=esp4,esp6,rxrpc
This prevents the module from initializing at boot time. A system reboot is required for this change to take effect.

Mitigation for Containers

For containerized environments, where this vulnerability may be leveraged for container escape, consider applying one or more of the following mitigations:

• Secure computing (seccomp) filtering: Restrict or deny system calls that create sockets using the AF_ALG address family (protocol 38) and AF_RXRPC (protocol 33) .
• AppArmor policies: Use AppArmor to block creation of AF_ALG sockets and AF_RXRPC via the network alg rule.
• eBPF-based enforcement: Deploy BPF-based controls to deny socket creation with address family AF_ALG (38) and AF_RXRPC (33).

Acknowledgements

This vulnerability was disclosed by Hyunwoo Kim. This document was written by Bob Kemerer.

Overview

Three vulnerabilities have been discovered in the SGLang project, two enabling remote code execution (RCE), and one regarding a path traversal vulnerability. In order for an attacker to exploit these vulnerabilities, the multimodal generation mode must be enabled, and an attacker must have network access to the SGLang service. No patch is available at this time, and no response was obtained from the project maintainers during coordination.

Description

SGLang is an open-source framework for serving large language models (LLMs) and multimodal AI models, supporting models such as Qwen, DeepSeek, Mistral, and Skywork, and is compatible with OpenAI APIs. Three vulnerabilities have been discovered within the tool and are tracked as follows:

CVE-2026-7301
The multimodal generation runtime scheduler's ROUTER socket contains a sink that calls pickle.loads() on incoming messages, enabling RCE when exposed to the internet.

This vulnerability is distinct from CVE-2026-3060 and CVE-2026-3059, which would be open to the Internet via the ZMQ broker, which automatically binded to all network interfaces without user awareness. CVE-2026-7301 is exposed to the internet by default through the scheduler host, which binds to 0.0.0.0 by default.

CVE-2026-7302
The multimodal generation runtime is vulnerable to an unauthenticated path traversal vulnerability, allowing an attacker to write arbitrary files anywhere the server process has write access, by including ../ sequences in the upload filename when sent to specific endpoints.

CVE-2026-7304
The multimodal generation runtime is vulnerable to unauthenticated remote code execution when the --enable-custom-logit-processor option is enabled, as Python objects loaded via dill.loads() will be deserialized without validation.

Impact

If exploited, these vulnerabilities could allow an unauthenticated attacker to achieve remote code execution or arbitrary file writes on the host running SGLang. Deployments that expose the affected interface to untrusted networks are at the highest risk of exploitation.

Solution

Until a patch is available, affected users should consider the following mitigations:

Mitigation

• Restrict access to the service interfaces and ensure they are not exposed to untrusted networks.
• Implement network segmentation and access controls to prevent unauthorized interaction with the vulnerable endpoints.

Acknowledgements

Thanks to the reporter, Alon Shakevsky. This document was written by Christopher Cullen.

Overview

dnsmasq is affected by multiple memory safety and input validation vulnerabilities, including heap buffer overflows, heap corruption, and code execution flaws. Collectively, these vulnerabilities enable attackers to poison cached DNS records, bypass security controls, crash the dnsmasq process, or under certain conditions, achieve local privilege escalation. dnsmasq has released version 2.92rel2 to fix the vulnerabilities.

Description

dnsmasq is an open-source networking tool that provides DNS forwarding, DHCP, and network boot services for small-to-medium sized networks and home routing devices. It can also function as a DNS resolver, which is the primary exploitation use case for several of the vulnerabilities described below, tracked collectively as CVE-2026-2291, CVE-2026-4890, CVE-2026-4891, CVE-2026-4892, CVE-2026-4893, and CVE-2026-5172.

CVE-2026-2291
dnsmasq's extract_name() function can be abused to cause a heap buffer overflow, enabling an attacker to inject false DNS cache entries. This could cause DNS queries to be redirected to attacker-controlled IP addresses or result in a Denial of Service (DoS).

CVE-2026-4890
An infinite-loop flaw in the DNSSEC validation of dnsmasq allows remote attackers to cause Denial of Service (DoS) conditions via a crafted DNS packet.

CVE-2026-4891
A heap-based out-of-bounds read vulnerability in the DNSSEC validation of dnsmasq allows remote attackers to leak memory information via a crafted DNS packet.

CVE-2026-4892
A heap-based out-of-bounds write vulnerability in the DHCPv6 implementation of dnsmasq allows local attackers to execute arbitrary code with root privileges via a crafted DHCPv6 packet.

CVE-2026-4893
An information disclosure vulnerability in dnsmasq allows remote attackers to bypass source checks via a crafted DNS packet containing RFC 7871 client-subnet information.

CVE-2026-5172
A buffer overflow vulnerability in dnsmasq’s extract_addresses() function allows attackers to trigger a heap out-of-bounds read and crash dnsmasq by exploiting a malformed DNS response.

Impact

These vulnerabilities collectively pose various risks:

DoS (CVE-2026-2291, CVE-2026-4890, CVE-2026-5172) — dnsmasq may crash or become unresponsive, terminating DNS resolution and affecting dependent services.

Cache Poisoning / Redirection (CVE-2026-2291, CVE-2026-4893) — Attackers may overwrite cache entries or manipulate response routing, enabling the silent redirection of users to malicious domains.

Information Disclosure (CVE-2026-4891, CVE-2026-4893) — Internal memory and network information may be inadvertently exposed.

Local Privilege Escalation (CVE-2026-4892) — A local attacker may execute arbitrary code as root via DHCPv6 manipulation.

Solution

dnsmasq has released version 2.92rel2 to fix the above vulnerabilities, and various vendors have published patches to address individual remediations. A full list of affected vendors and vendor patches can be found in the References section below. This note, as well as the CVE listings, will be updated as additional patches become available.

Acknowledgements

Thank you to the reporters for discovering these vulnerabilities:
* Hugo Martinez (hugomray@gmail.com) - CVE-2026-5172, CVE-2026-2291
* Andrew Fasano (NIST) - CVE-2026-2291
* Royce M (royce@xchglabs.com) - CVE-2026-4893, CVE-2026-4892, CVE-2026-4891, CVE-2026-4890, CVE-2026-2291
* Asim Viladi Oglu Manizada - CVE-2026-4892
* Mattia Ricciardi (mindless) - CVE-2026-2291

This document was written by Christopher Cullen and Molly Jaconski. Special thanks to Simon Kelly of dnsmasq and all participating vendors for their prompt engagement and coordination efforts.

Overview

Casdoor contains an arbitrary file write vulnerability in the implementation of its "Local File System" storage provider. Due to insufficient sanitization of user-supplied paths, an authenticated user with file upload permissions can escape the intended storage directory and write files elsewhere on the target filesystem. The vulnerability allows attackers to bypass Casdoor’s storage sandbox and perform unauthorized actions with the privileges of the Casdoor runtime user.

Description

Casdoor is an open-source identity and access management (IAM) platform and Model Context Protocol (MCP) gateway that provides authentication, single sign-on, and multi-protocol identity services for applications. Internally, it uses its Local File System storage provider to save files to a dedicated $CASDOOR/files/ directory.

During a file upload via the /api/upload-resource endpoint, the Casdoor application determines the target storage filepath by concatenating the user-supplied parameters pathPrefix and fullFilePath. However, values provided for pathPrefix are not properly sanitized, so directory traversal sequences such as ../../ are accepted without any integrity or permission checks beyond those of the OS user running the Casdoor process. The application does not verify that the destination filepath remains inside the dedicated storage directory, and it will create or overwrite any file that the Casdoor process has permission to modify.

CVE-2026-6815 An arbitrary file write vulnerability exists in Casdoor's Local File System storage provider. Due to insufficient path sanitization, an authenticated attacker with file upload privileges can perform a path traversal attack to create or overwrite arbitrary files elsewhere on the host filesystem, bypassing the application's intended storage sandbox.

Impact

Successful exploitation enables arbitrary file creation and modification on the host system, which can be used by an attacker to:
* Overwrite any file that is accessible to the Casdoor process.
* Establish persistence by creating scheduled tasks or cron jobs through the filesystem as the Casdoor user.
* Overwrite Casdoor’s backend database file casdoor.db, causing authentication services to fail and locking out all users and dependent applications.

Exploitation of this vulnerability requires the attacker to possess an authenticated session with sufficient permissions to manage storage providers and interact with the resource upload API. Depending on the privileges of the Casdoor service account, this vulnerability may allow escalation from application-level access to full host compromise.

Solution

A pull request has been submitted to the Casdoor repository that implements proper validation of storage paths, available here: https://github.com/casdoor/casdoor/pull/5458 . Otherwise, deployments should limit administrative access and restrict the filesystem permissions of the Casdoor service account. Administrators should avoid using the Local File System provider or disable this service in multi-user or exposed environments.

Acknowledgements

Thanks to Danilo Dell'Orco for researching and reporting this vulnerability. This document was written by Molly Jaconski.

Overview

A privilege escalation vulnerability has been discovered in Linux kernel versions version 4.17 (released 2017) and later. Many popular distributions and Linux-based containers are affected. This vulnerability was publicly disclosed on April 29, 2026, has been assigned CVE ID CVE-2026-31431, and is commonly referred to as "Copy Fail."

Description

The Linux kernel, since version 4.17, includes the algif_aead module, which provides user space access to authenticated encryption with associated data (AEAD) operations via the AF_ALG interface. This module may be available as a loadable kernel module or compiled directly into the kernel, depending on the Linux distribution or the custom built Linux install.

According to the https://copy.fail disclosure statement:

An unprivileged local user can write 4 controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root.

The vulnerability is caused by a logic flaw in the Linux kernel’s algif_aead (AF_ALG) implementation. An unprivileged local user can reliably perform a controlled 4-byte write into the page cache of any readable file without race conditions or timing dependencies.

Critically, the corrupted page is not marked dirty, so the modified contents are never written back to disk. The underlying file remains unchanged, allowing the in-memory corruption to bypass checksum and file integrity verification mechanisms. Because subsequent reads are served from the page cache, an attacker can target a setuid binary and modify its in-memory contents to achieve local privilege escalation to root.

A 732-byte proof-of-concept Python script demonstrates exploitation by modifying a setuid binary to obtain root privileges on many Linux distributions released since 2017. This vulnerability was discovered by Taeyang Lee of Theori, with assistance from their AI-based static application security testing (SAST) tool, Xint Code, during analysis of the Linux kernel cryptographic subsystem.

Impact

This vulnerability allows an unprivileged local user to modify the in-memory contents of a setuid binary and escalate privileges to root. Public proof-of-concept (PoC) exploit code is available, therefore increasing the likelihood of exploitation.

Solution Patch the Kernel

Apply the upstream kernel patch that addresses the issue by reverting AF_ALG AEAD to an out-of-place operation.

Update Linux distribution

Update your distribution’s kernel package as soon as vendor patches become available. Most major Linux distributions are expected to release fixes through their standard update channels.

Workarounds (if patching is not immediately possible):

1. Disable the algif_aead module (if loadable):
   echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
   rmmod algif_aead 2>/dev/null
   This prevents the module from being loaded and removes it if already active.

2. If algif_aead is compiled into the kernel (not a dynamic module), the following parameter can be added to grub or systemd-boot or grubby depending on your boot configuration:
   initcall_blacklist=algif_aead_init
   This prevents the module from initializing at boot time. A system reboot is required for this change to take effect.

Note: These workarounds may impact applications that rely on AF_ALG cryptographic interfaces.

Mitigation for containers

For containerized environments, where this vulnerability may be leveraged for container escape, consider applying one or more of the following mitigations:

• Secure computing (seccomp) filtering: Restrict or deny system calls that create sockets using the AF_ALG address family (protocol 38).
• AppArmor policies: Use AppArmor to block creation of AF_ALG sockets via the network alg rule.
• eBPF-based enforcement: Deploy BPF-based controls to deny socket creation with address family AF_ALG (38).

This is adopted from the guidance provided by bytedance for the vArmor community.

Note on Virtualization

While the internal kernel within a virtual machine (VM) or MicroVM is susceptible to this vulnerability, standard virtualization provides hardware-enforced memory isolation. This bug cannot be directly leveraged to facilitate a virtualization escape from a guest to the host. Virtualization and micro-virtualization technologies effectively contain the impact to the individual VM instance, protecting the host kernel and neighboring tenants from guest-originated attacks.

Acknowledgements

This vulnerability was disclosed by Theori.io research group. This document was written by Bob Kemerer and Vijay Sarvepalli.

Overview

A security flaw exists in the configuration management endpoint of the DRC INSIGHT software, allowing an unauthenticated user with access to the same network as the server to modify the server’s configuration file. This could enable data exfiltration, traffic redirection, or service disruption.

Description

Data Recognition Corporation (DRC) provides software for test proctoring, including the web-based DRC INSIGHT platform. A component of this platform, Central Office Services (COS), is typically deployed on a school or district local area network to host and distribute testing content to student devices.

COS uses a unified API router that serves both public content functions, such as exam delivery, and administrative functions, without meaningful separation between content-serving APIs and management APIs.

The /v0/configuration administrative endpoint is accessible to systems on the same network as the COS server without authentication or origin validation. Any unauthenticated user or compromised device with network access to the server may submit requests that modify the server’s configuration file. The endpoint accepts and persists user-supplied JSON payloads without validating content, checking authorization, or verifying the safety of requested configuration changes. This vulnerability is tracked as CVE-2026-5756.

Impact

Exploitation could allow an attacker to exfiltrate student data by overwriting storage configuration values or credentials so that test artifacts, responses, or audio recordings are sent to attacker-controlled external services instead of intended DRC-managed destinations. An attacker could also intercept or manipulate outbound traffic by inserting a malicious httpsProxy setting, causing HTTPS communications with DRC validation or content services to pass through an attacker-controlled proxy. In addition, malformed JSON, invalid port bindings, or incorrect service endpoints could disrupt operations by preventing the server from starting or interfering with active assessments.

Mitigations

Coordination with the vendor was unsuccessful, and no patch is currently available. Organizations that are unable to update or modify the application should restrict network access to the COS server by placing it on a dedicated, isolated network segment accessible only to trusted administrative systems. Student and guest networks should not be permitted to reach the server.

Host-based or network firewalls should be used to restrict access to the /v0/configuration endpoint, ideally limiting access to localhost or specifically authorized administrative IP addresses. Outbound network traffic should be restricted to approved destinations, such as DRC infrastructure, and monitored for unexpected connections to unknown storage services or proxy endpoints.

Administrators should enable logging and monitoring capable of detecting requests to the /v0/configuration endpoint, unauthorized configuration changes, and unusual outbound traffic patterns. Services should run with least privilege, with write access to configuration files limited wherever possible. Signed backups of configuration files should be maintained and their integrity verified before restoration or redeployment.

Acknowledgments

Thanks to Caen Jones for responsibly disclosing this vulnerability.
Document prepared by Timur Snoke with the assistance of AI.

Overview

Ollama’s model quantization engine contains a vulnerability that allows an attacker with access to the model upload interface to read and potentially exfiltrate heap memory from the server. This issue may lead to unintended behavior, including unauthorized access to sensitive data and, in some cases, broader system compromise.

Description

Ollama is an open-source tool designed to run large language models (LLMs) locally on personal systems, including macOS, Windows, and Linux. Ollama supports model quantization, an optimization technique that reduces the numerical precision used in models to improve performance and efficiency.

An out-of-bounds heap read/write vulnerability has been identified in Ollama’s model processing engine. By uploading a specially crafted GPT-Generated Unified Format (GGUF) file and triggering the quantization process, an attacker can cause the server to read beyond intended memory boundaries and write the leaked data into a new model layer.

CVE-2026-5757: Unauthenticated remote information disclosure vulnerability in Ollama's model quantization engine allows an attacker to read and exfiltrate the server's heap memory, potentially leading to sensitive data exposure, further compromise, and stealthy persistence.

The vulnerability is caused by three combined factors:

• No Bounds Checking: The quantization engine trusts tensor metadata (like element count) from the user-supplied GGUF file header without verifying it against the actual size of the provided data.
• Unsafe Memory Access: Go's unsafe.Slice is used to create a memory slice based on the attacker-controlled element count, which can extend far beyond the legitimate data buffer and into the application's heap.
• Data Exfiltration Path: The out-of-bounds heap data is inadvertently processed and written into a new model layer. Ollama's registry API can then be used to "push" this layer to an attacker-controlled server, effectively exfiltrating the leaked memory.

Impact

An attacker with access to the model upload interface can exploit this vulnerability to read from or write to heap memory. This may result in exposure of sensitive data, data exfiltration, and potentially full system compromise.

Solution

Unfortunately, we were unable to reach the vendor to coordinate this vulnerability, and a patch is not yet available to address this vulnerability. The underlying issue should be addressed by implementing proper bounds checking to ensure that tensor metadata is validated against the actual size of the provided data before any memory operations are performed.

As an interim mitigation, access to the model upload functionality should be restricted or disabled, particularly in environments exposed to untrusted users or networks. Deployments should be limited to local or otherwise trusted network environments where possible. If model uploads are required for operational reasons, only models from trusted and verifiable sources should be accepted, and appropriate validation controls should be applied to reduce risk.

Acknowledgements

Thanks to the reporter Jeremy Brown, who detected the vulnerability through AI-assisted vulnerability research. This document was written by Timur Snoke.

Overview

Radware Alteon has a reflected Cross-Site Scripting (XSS) vulnerability in the parameter ReturnTo of the route /protected/login. This vulnerability allows an attacker to execute JavaScript in the host browser.

Description

CVE-2026-5754: Reflected Cross-Site Scripting (XSS) vulnerability in Radware Alteon 34.5.4.0 vADC load-balancer allows an attacker to inject malicious scripts into the website, potentially leading to unauthorized actions, data theft, or other malicious activities.

A reflected Cross-Site Scripting (XSS) vulnerability exists in the ReturnTo parameter of the /protected/login route in Radware Alteon version 34.5.4.0. The vulnerability arises from the lack of user input sanitization, allowing an attacker to inject malicious scripts. Specifically, when a user requests a resource that redirects to a Microsoft SAML login page, the load-balancer redirects the user to the login page with a ReturnTo parameter that fails to sanitize user input. An attacker can exploit this by injecting a malicious payload in the ReturnTo parameter, which will be executed in the victim's browser.

An example attack flow is below:

1. Attacker creates link with XSS payload in ReturnTo parameter.
2. Victim clicks malicious link, redirecting to login page.
3. Load-balancer reflects malicious ReturnTo parameter, executing XSS payload.
4. Attacker performs JavaScript code execution in the victim's browser.

Impact

The impact of this vulnerability is significant, as it allows an attacker to execute arbitrary JavaScript code in a victim’s browser. Doing so enables a range of harmful activities, including the following: stealing session cookies and sensitive data; performing unauthorized actions on behalf of the victim; tricking users into falling for phishing attacks; and damaging a website’s reputation and user trust.

Solution

Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. The vendor, Radware, has acknowledged the vulnerability in their customer portal and plans to patch it in the next version, 34.5.7.0. This version was expected to be released on March 31st, 2026, based upon the release notes, but it is unclear if this release occurred and included a fix. In the meantime, users are advised to take precautions to prevent exploitation, such as validating and encoding user input.

Acknowledgements

Thanks to the reporter, Loinaz Merino Cerrajeria, for bringing this vulnerability to our attention.This document was written by Timur Snoke.