Currently browsing: Technology

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.

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/falseninstall esp6 /bin/falseninstall rxrpc /bin/falsen’ > /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.