EUVD-2026-37803
GHSA-c9xw-w9jw-mq5m
Severity by source
AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Local-only attack vector (AV:L), low privilege required (PR:L) for standard user account; limited C/I/A impact reflects IOCTL abuse without confirmed full kernel compromise.
Primary rating from Vendor (certcc).
CVSS VectorVendor: certcc
Lifecycle Timeline
4DescriptionCVE.org
In SignalRGB versions prior to 1.3.7.0, 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.
AnalysisAI
Overly permissive access control on the SignalRGB kernel driver's device object exposes privileged IOCTL operations to any authenticated local user on Windows systems running versions prior to 1.3.7.0. The root cause is that the \\.\SignalIo device object is created without an explicit SDDL security descriptor and without the FILE_DEVICE_SECURE_OPEN flag, causing Windows to apply insecure default access controls. No public exploit or active exploitation has been identified at time of analysis; the EPSS score of 0.13% at the 3rd percentile reflects very low observed exploitation probability.
Technical ContextAI
SignalRGB ships a Windows kernel-mode driver that exposes a named device object at \\.\SignalIo for user-space communication via IOCTLs. On Windows, kernel drivers must explicitly define access control for their device objects using an SDDL (Security Descriptor Definition Language) string at device creation time. Omitting the SDDL causes Windows to apply a default descriptor that is far more permissive than intended - typically granting Everyone read/write access. Additionally, the absence of the FILE_DEVICE_SECURE_OPEN flag means Windows does not enforce security checks when the device is opened via relative paths (e.g., through a subdirectory handle), providing a secondary bypass path. The result is that any low-privileged local user can obtain a valid handle to the device and dispatch IOCTLs that were intended to be restricted to privileged callers. The affected component is identified by CPE cpe:2.3:a:signalrgb:signalrgb_kernel_driver:*:*:*:*:*:*:*:*, affecting all versions of the kernel driver below 1.3.7.0. No CWE was formally assigned by the reporter, but this maps conceptually to improper access control on a kernel resource.
RemediationAI
Upgrade SignalRGB to version 1.3.7.0 or later, which is the vendor-confirmed patched release as reported by CERT/CC (https://kb.cert.org/vuls/id/380058). The fix is expected to involve assigning a restrictive SDDL security descriptor to the \\.\SignalIo device object at creation time and setting the FILE_DEVICE_SECURE_OPEN flag to enforce security checks on all open paths. If immediate upgrade is not possible, the most targeted compensating control is to restrict local interactive login rights to trusted administrators only on affected hosts, reducing the pool of users who can reach the device object - note this does not eliminate the vulnerability but raises the required privilege level for exploitation. Disabling or uninstalling the SignalRGB service entirely eliminates the attack surface at the cost of losing RGB lighting functionality. Network-layer controls are not applicable given the strictly local attack vector.
More in Signalrgb Kernel Driver
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today