Skip to main content

Deskflow CVE-2026-44296

| EUVDEUVD-2026-29847 HIGH
Uncontrolled Resource Consumption (CWE-400)
2026-05-12 GitHub_M
7.5
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
7.5 HIGH

Remote, unauthenticated, low-complexity trigger against default TLS config with no user interaction; impact is availability-only (input stall), so C:N/I:N/A:H.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

4
Source Code Evidence Fetched
Jul 23, 2026 - 19:21 vuln.today
Analysis Generated
Jul 23, 2026 - 19:21 vuln.today
Patch available
May 12, 2026 - 22:03 EUVD
CVE Published
May 12, 2026 - 20:52 nvd
HIGH 7.5

DescriptionGitHub Advisory

Deskflow is a keyboard and mouse sharing app. Prior to 1.26.0.167, a remote, unauthenticated denial of service (DoS) vulnerability affects Deskflow servers running with TLS enabled (the default). When any TCP peer connects to the listening port and its first bytes do not parse as a valid TLS ClientHello, SecureSocket::secureAccept enters its fatal-error branch and calls Arch::sleep(1) (a blocking 1-second sleep) on the multiplexer worker thread. That thread services every socket on the server, including established TLS clients delivering mouse motion, keyboard events, and clipboard updates. A single failed handshake therefore stalls input delivery to all connected screens for ~1 second, and a sustained drip of malformed connections (≥ 1/s) makes the server effectively unusable while the attack persists. This vulnerability is fixed in 1.26.0.167.

AnalysisAI

Remote denial of service in Deskflow servers (versions prior to 1.26.0.167) running with TLS enabled - the default - lets any unauthenticated TCP peer stall input delivery to all connected screens. Because SecureSocket::secureAccept calls a blocking Arch::sleep(1) on the single multiplexer worker thread whenever a connection's first bytes fail to parse as a valid TLS ClientHello, one malformed handshake freezes mouse, keyboard, and clipboard traffic for ~1 second, and a sustained drip of ≥1 bad connection per second renders the server unusable. EPSS is low (0.04%, 12th percentile) and there is no public exploit identified at time of analysis, though the fix commit is public and the trigger is trivial.

Technical ContextAI

Deskflow is an open-source keyboard/mouse sharing application (the upstream project behind Synergy/Barrier) that lets one server share input devices across multiple client screens over the network. The server uses a single multiplexer worker thread to service every connected socket via an event loop. TLS handshakes are terminated in SecureSocket::secureAccept (src/lib/net/SecureSocket.cpp). The root cause is CWE-400 (Uncontrolled Resource Consumption): the fatal-error branch of secureAccept executed a blocking Arch::sleep(1) directly on the shared multiplexer thread - a comment in the original code ('sleep so the socket isn't hammered') intended to throttle a misbehaving peer, but instead throttled the entire server because that one thread is responsible for all I/O. The affected component is deskflow's TLS acceptance path (cpe:2.3:a:deskflow:deskflow), active by default since TLS is enabled out of the box.

RemediationAI

Vendor-released patch: upgrade to Deskflow 1.26.0.167 or later, which removes the blocking Arch::sleep(1) from SecureSocket::secureAccept so a failed handshake no longer stalls the multiplexer thread (fix commit https://github.com/deskflow/deskflow/commit/329783490bd16774ba903b84212467d20d76bfba; advisory https://github.com/deskflow/deskflow/security/advisories/GHSA-3mxm-cgh2-6448). If you cannot upgrade immediately, restrict network access to the Deskflow server's listening port using a host or network firewall so that only trusted client screens can reach it - this is the most effective compensating control since the flaw requires a TCP peer to reach the port, but it does not help if all your legitimate screens share a network with untrusted hosts. Binding Deskflow to a VPN/loopback-tunneled interface rather than a public interface achieves the same isolation with the trade-off of added connection setup for legitimate clients. Disabling TLS is NOT recommended: it would sidestep this specific code path but expose input traffic (keystrokes, clipboard) in cleartext, a far worse outcome.

Vendor StatusVendor

SUSE

Severity: High

Share

CVE-2026-44296 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy