Hírolvasó
Új kampányban terjed az NFCShare Android banki trójai
550 000 önkéntes adatait lopták el a JeVeuxAider.gouv.fr oldalról
A Microsoft dolgozik a „RoguePlanet” Defender sérülékenység javításán
Több gigabájtnyi adat szivároghatott ki egy amerikai vízszolgáltatótól
VU#380058: SignalRGB kernel driver contains improper access control and IOCTL vulnerabilities
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.
DescriptionSignalRGB 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.
ImpactThe 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.
SolutionSignalRGB 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.
AcknowledgementsThanks 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.
A SIM kártyáját félti, a pénzét veszti el
Kibertámadás érte az orosz Astral vállalatot
A ShinyHunters állítása szerint meghackelte az Európa Tanácsot
Ez az új támadás egykattintásos adatlopóvá változtatja a Microsoft 365 Copilotot
Francia nyugdíjrendszert célzó MI-vezérelt adathalász kampány
Gmail fiókokat céloz az új Ghostwriter kampány
Felszámolásra került a Sniper Dz adathalász platform
Kritikus sérülékenység a Splunk Enterpriseban
A ShinyHunters támadhatja a PeopleSoft rendszereket
VU#862559: crypton-x509-validation Haskell libraries do not enforce X.509 NameConstraints
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.
DescriptionHaskell 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.
ImpactAn 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.
SolutionThe 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.
AcknowledgementsThanks to the reporter, Ben Smyth.This document was written by Christopher Cullen.
