Currently browsing: Security

Overview
Adalo’s no‑code application platform exposes complete user records through its database API for all applications built on both V1 and V2. Due to a platform-level flaw, authenticated users can retrieve full user data belonging to any Adalo application, regardless of configuration. This issue affects more than one million applications and placing developers and their end users at risk of data exposure that they cannot prevent or remediate.
Description
Adalo is a Software-as-a-Service (SaaS) provider for building no-code applications. In theory, each application or tenant (customer) is logically isolated with separate databases, users, and configurations.
CVE-2026-10706 Unrestricted Disclosure of Full User Records
The Adalo database API contains a flaw which allows the backend to return complete user records for every list component request, regardless of which fields the component is configured to display. The database does not enforce ownership‑aware, server‑side authorization checks, allowing authenticated users of any Adalo application to query database and table identifiers belonging to other applications and retrieve full records, including fields not requested. This issue is amplified by the permissive CORS policy, plaintext storage of all text files and evidence suggests that deleted records may remain accessible.
CVE-2026-10708 Exposure and Reuse of Long-Lived JWT Tokens
The JWT tokens are visible in client‑side requests and remain valid for approximately twenty days. Once copied, they can be reused from any external website or script to query the database API directly. Because the platform allows requests from any origin, attackers can repeatedly query the API and extract large volumes of user data without interacting with the application itself. The combination of exposed tokens, permissive CORS behavior, and large response limits enables persistent, automated harvesting of entire user databases using only a single token obtained from any visitor session.
Impact
These vulnerabilities affect all Adalo applications across both V1 and V2. Because they occur at the platform level, the entire population of Adalo‑built applications is impacted.
Exposure of Sensitive Information to an Unauthorized attacker (CVE-2026-10706) Attackers may extract full user records and correlate user behavior across multiple applications via dbId enumeration. The platform does not implement data minimization, privacy by design, or implement appropriate technical safeguards, allowing sensitive information to be exposed to unauthorized parties.
Insufficiently Protected Credentials (CVE-2026-10708) This vulnerability enables large‑scale data harvesting without requiring app‑specific secrets. A single request to a minimal leaderboard component may return user records containing emails, UUIDs, and custom fields. The combination of wildcard CORS behavior, long‑lived twenty‑day JWTs, and the absence of token revocation allows attackers to gather sensitive personal information from any Adalo application.
Solution
Adalo contains an access control weakness that may allow unauthorized users to bypass application boundaries under certain conditions. Adalo has acknowledged the issue, however, no patch is currently available. Customers and tenants should assume data in Adalo collections may be exposed, and avoid storing sensitive information there until a patch is deployed. Users should remain aware of increased phishing and identity theft risks and monitor their accounts for suspicious activity.
Acknowledgements
Thanks to the reporter Saud Darwish. This document was written by Laurie Tyzenhaus.

Overview
Several versions of Tenda firmware contain an undocumented authentication backdoor that grants administrative access to the devices’ web management interfaces. An attacker can expoit this vulnerability, tracked as CVE-2026-11405, to bypass the password verification process and obtain full administrative control without valid credentials.
Affected Versions:
* US_FH1201V1.0BR_V1.2.0.14(408)_EN_TD
* US_W15EV1.0br_V15.11.0.5(1068_1567_841)_EN_TDE
* US_AC10V1.0re_V15.03.06.46_multi_TDE01
* US_AC5V1.0RTL_V15.03.06.48_multi_TDE01
* US_AC6V2.0RTL_V15.03.06.51_multi_T
Description
Tenda is a supplier of home and business network devices such as routers, switches, wireless access points, and video surveillance equipment. Most of these devices include web-based interfaces that allow users to perform configuration and management operations, which are protected by username/password authentication to prevent unauthorized modifications.
The web server binary /bin/httpd contains an undocumented backdoor authentication mechanism in the login() function. Initially, the function follows a normal authentication path using MD5-based password verification. However, if authentication fails, the function invokes GetValue(“sys.rzadmin.password”) to retrieve an alternate password value from the device configuration. It then performs a direct strcmp() comparison in plaintext between the user-supplied password and the configuration-stored value. A successful match grants role=2 admin-level access and creates a valid session.
The associated username is not validated, so any provided username will succeed when paired with the backdoor password. This backdoor authentication mechanism is not documented or visible through any administrative interface.
Impact
Successful exploitation grants full administrative access to the device’s web interface, regardless of the configured administrator account credentials. With administrative control, an attacker can reconfigure the device, alter network settings, and disable security features, enabling broader compromise of the local network.
Solution
Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Since a patch is unavailable, we can only offer mitigation strategies. The following workarounds can help mitigate this vulnerability’s impact until a fixed version is released:
Disable remote management on your device
If your device supports remote web management, disable it. Disabling this feature prevents attackers on external networks from accessing your device’s administrative dashboard over the internet.
Restrict local network exposure
Changing the default LAN IP address may reduce opportunistic discovery by automated scanners that target known default IP ranges. Note that this measure does not prevent deliberate or targeted network scanning.
Acknowledgements
Thanks to the reporter who wishes to remain anonymous. This document was written by Bob Kemerer.

Overview
HP Printers in the Deskjet 2800 Series running firmware version <=TBP1CN2612AR contain a missing authorization vulnerability tracked as CVE-2026-13753. This vulnerability allows unauthenticated access to the printer’s webserver API endpoints, exposing Wi-Fi credentials, management configuration details, and sensitive security data normally restricted to administrative users.
Description
Modern HP printers provide a web-based management interface for configuring content such as Wi-Fi Direct settings, SNMP management access, and device security options. When accessed normally through the browser interface, these pages explicitly require administrator credentials before sensitive information is displayed. This information is protected because, for example, Wi-Fi Direct controls the printer’s direct wireless connectivity, and SNMP configuration settings can reveal detailed information about the device’s monitoring and management controls.
In affected firmware versions, the authorization requirement can be bypassed by sending direct, unauthenticated GET requests to multiple backend API endpoints. The affected endpoints return administrative configuration data without validating session state or authentication, including the Wi-Fi Direct SSID and plaintext passphrase, unique printer serial numbers and service IDs, and details about the device’s administrative password state. This information is freely disclosed even though the corresponding web interface pages correctly enforce authentication, indicating an authorization flaw in the API layer.
Impact
A remote attacker with network access to the printer can bypass the web interface’s authentication requirements and retrieve sensitive configuration data directly from backend APIs. Exposed information includes Wi-Fi Direct credentials, SNMP configuration details, device identity information, cloud service registration metadata, and other information involving the device’s administrative security state. An attacker could use this information to gain unauthorized wireless access, perform reconnaissance on network or cloud integrations, impersonate the device, or facilitate further compromise of the printing environment.
Solution
Unfortunately, we were unable to reach HP to coordinate this vulnerability, so a firmware patch is not yet available. To limit the risk of this vulnerability, users should restrict network access to the printer’s web interface by placing the device on a trusted or isolated network segment, disable Wi‑Fi Direct if it is not required, and limit SNMP access to trusted systems or disable it entirely. Firewall or access-control list (ACL) rules should be used to prevent untrusted hosts from reaching the printer’s management ports, and discovery or cloud service features that are not needed should be disabled.
Acknowledgements
Thanks to Nguyễn Tiến Dũng for researching and reporting this vulnerability. This document was written by Molly Jaconski.

Overview
The GamersFirst Anti-Cheat (GFAC) driver GFAC.sys contains multiple local privilege escalations and denial-of-service vulnerabilities stemming from insecure handling of user-controlled input through a minifilter communication port. A local attacker can abuse these flaws to perform arbitrary kernel memory writes, obtain privilege escalation to SYSTEM, or trigger a system crash.
Description
GFAC is a proprietary anti-cheat software developed by video game publisher Little Orbit. GFAC includes a kernel-mode driver, GFAC_Sys_x64.sys, that exposes privileged functionality to user-mode applications through a minifilter communication port. Although these low-level interfaces are necessary for the software’s operation, vulnerabilities can arise if user-mode access is not properly restricted and validated.
CVE-2026-12166 GFAC_Sys_x64.sys contains a NULL pointer dereference condition in its initialization and request handling logic. A local attacker can trigger the vulnerable code path, causing the driver to read or write to a memory address assigned as NULL. Successful exploitation results in a system crash (“blue screen of death”).
CVE-2026-12167 The minifilter communication port that GFAC_Sys_x64.sys exposes does not enforce sufficiently restrictive security descriptors. As a result, low-privileged users can establish connections to the driver and access functions intended only for trusted processes. [RM1.1][MB1.2][RM1.3]User access to privileged functions could help an attacker take advantage of other weaknesses in the driver.
CVE-2026-12168 GFAC_Sys_x64.sys processes messages received through a minifilter communication port without properly validating user-supplied memory addresses before performing write operations. An attacker can provide a crafted request containing a desired destination address and data value, causing the driver to write arbitrary data to kernel memory. This write-what-where condition can be leveraged to modify sensitive operating system structures, such as process security tokens, resulting in privilege escalation to SYSTEM.
Impact
Multiple vulnerabilities in the driver may allow local attackers to crash the system, escalate privileges to SYSTEM, or execute unauthorized code. Due to insufficient access controls, privileged driver functionality is exposed to untrusted users, increasing the likelihood and impact of exploitation.
Solution
Unfortunately, we were unable to reach the vendor to coordinate this vulnerability. Users should restrict local access to trusted users and monitor systems for unauthorized interactions with GFAC. Where available, games that utilize GFAC should be disabled or removed until an update is available to address the identified vulnerabilities.
Acknowledgements
Thanks to Lucian Alexandru Necula for identifying and disclosing these vulnerabilities. This document was written by Michael Bragg.

Overview
Two vulnerabilities have been identified in FastStone Image Viewer 8.3 that may allow remote code execution or control-flow corruption when processing specially crafted image files. The affected components include the JPEG 2000 (JP2) parser and the PSD file parser. An attacker can exploit these vulnerabilities by causing the application to automatically or interactively process malicious image files.
Description
FastStone Image Viewer is a software tool for browsing, editing, and managing images, offering features like full‑screen viewing, batch processing, red‑eye removal, and a wide range of editing effects. It supports virtually all major image and RAW formats and includes conveniences like slideshows, comparison tools, scanner support, and screen capture.
CVE-2026-30040 A critical heap-based buffer overflow vulnerability exists in FastStone Image Viewer, versions 8.3 and earlier. The issue is triggered during the parsing of JPEG 2000 (JP2) files due to a malformed QCD (quantization default, 0xFF5C) marker in the FSViewer.exe process. By exploiting this flaw, a remote attacker can overwrite the EIP (instruction pointer) and execute arbitrary code in the context of the current process via a crafted JP2 file.
Notably, this issue does not require the victim to directly open the crafted JP2 file. When the application enumerates directories during automatic thumbnail generation, files within two directory levels are parsed by the JP2 decoder. If the malicious JP2 file is present within this enumeration range (for example in the user’s Downloads folder), the vulnerability is triggered automatically.
CVE-2026-30041 An integer overflow vulnerability exists in the PSD parser of FastStone Image Viewer, versions 8.3 and earlier. The vulnerability is caused by a lack of proper validation for the height value in PSD files, leading to a subsequent heap-based buffer overflow. Successful exploitation could allow a remote attacker to execute arbitrary code or cause a persistent denial-of-service (crash) via a crafted PSD file.
Impact
Successful exploitation of CVE-2026-30040 could allow arbitrary code execution in the context of the user running FastStone Image Viewer. Additionally, an attacker could exploit CVE-2026-30041 to overwrite the instruction pointer and control the program’s execution flow, crashing the application or potentially enabling arbitrary code execution. The impact severity depends on the privileges of the user running the application. Code executed under elevated permissions would result in significantly higher risk.
Solution
Unfortunately, we were unable to reach the vendor for coordination, and a patch is not yet available. To limit the risk of this vulnerability, run the software using a restricted local account and enforce policies that prevent users from downloading or saving JP2 or PSD files from untrusted sources.
Acknowledgements
This vulnerability was disclosed by Sunghun Oh. This document was written by Bob Kemerer.

Overview
Microsoft Windows Recovery Environment (WinRE) provides a mechanism for recovering and repairing Windows systems using an alternate boot environment. Under certain platform implementations, access to WinRE may allow an attacker to bypass firmware security controls, including administrator-configured UEFI/BIOS passwords. An attacker with physical or administrative access to a device may be able to leverage WinRE-related boot mechanisms to circumvent firmware protections and gain unauthorized access to system resources.
Description
Microsoft Windows versions 10 and 11 include the WinRE capability, a recovery platform that supports features such as the F11 recovery menu and the Reset this PC functionalities. WinRE is commonly used for system recovery, troubleshooting, and remote support scenarios.
When WinRE is invoked, the system reboots into a recovery environment that may use an alternate boot path from the standard operating system startup sequence. Depending on the platform and firmware implementation, the alternate boot path may not consistently enforce the same UEFI/BIOS security controls that are applied during a normal boot process.
A security concern has been identified in certain WinRE implementations where administrative UEFI/BIOS passwords may not be enforced during specific recovery operations. This inconsistency in the boot execution path may allow an attacker with physical access to a device to bypass firmware-level protections. Such scenarios are commonly associated with “Evil Maid” attacks, in which an attacker gains temporary physical access to an unattended system and modifies its boot configuration or security settings.
In UEFI-based systems, the UEFI boot manager supports the BootNext variable, which specifies a one-time boot target stored in non-volatile memory (NVRAM). The UEFI trust model assumes that only privileged software or the platform owner can modify NVRAM variables; however, the BootNext variable itself is not authenticated and takes precedence over the normal BootOrder configuration during the next boot cycle. When Secure Boot is enabled, firmware validates the integrity and signature of the boot application specified by BootNext before execution. The UEFI specification does not explicitly mandate a full platform reset when the BootNext variable is configured, leaving reset-handling and user authentication flows to the specific implementation. Consequently, the effectiveness of pre-boot security controls (such as UEFI/BIOS password protections and BitLocker full-disk encryption) can be bypassed via recovery environments like WinRE, provided a user has the privileges required to initiate such recovery.
Organizations with high security requirements for their devices should not rely solely on UEFI/BIOS passwords to protect systems where WinRE or such recovery environments are accessible to untrusted users. Additional controls should be implemented to protect against both physical-access and privileged-user attacks.
Impact
An attacker with access to the Windows Recovery Environment may be able to bypass administrator-configured UEFI/BIOS password protections on affected systems. Depending on the device configuration and firmware implementation, an attacker may also be able to perform actions that weaken or circumvent BitLocker full-disk encryption protections, potentially resulting in unauthorized access to sensitive data.
Solution
Microsoft has published an advisory related to recovery-environment hardening and secure boot configurations, including mitigations for vulnerabilities affecting WinRE mechanisms. Organizations should review applicable vendor guidance and evaluate whether their systems are susceptible to WinRE-based firmware security bypasses.
In addition to standard recommendations (e.g., enabling Secure Boot), the following mitigations are advised for highly sensitive systems:

Disable or restrict WinRE on systems where recovery functionality is not operationally required.
Require administrative authorization with ephemeral one-time access before enabling or invoking recovery environments.
Enable BitLocker with TPM + PIN or TPM + Startup Key to ensure additional authentication is required during recovery and pre-boot scenarios.
Enable restrictions of pluggable media with EFI System Partitions (ESP) and any modifications to sensitive items in UEFI NVRAM such as BootNext and BootOrder.
Deploy endpoint detection and response (EDR) solutions or end-point restrictions that support pre-boot security along with remote attestation and measured boot technologies to detect or block unauthorized boot modifications.
Implement physical security controls, including device locks, secure storage, tamper-evident protections, and chain-of-custody procedures for high-value systems.

These recommendations should be evaluated in accordance with organizational recovery requirements and operational constraints. Some of the recommendations were adapted from Eclypsium research blog
Acknowledgements
Thanks to Beatriz Fresno Naumova for reporting this vulnerability. This document was written by Vijay Sarvepalli.

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

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

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

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

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

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

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

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