ScreenConnect 26.1 fixes CVE-2026-3564, a machine-key flaw enabling session hijack
ConnectWise ScreenConnect before 26.1 stored ASP.NET machine keys in config files, letting attackers forge sessions (CVE-2026-3564, CVSS 9.0). How to patch.
On 17 March 2026 ConnectWise released ScreenConnect 26.1 to fix CVE-2026-3564, which it scores CVSS 9.0. Earlier versions stored each instance's ASP.NET machine keys in server configuration files. Anyone who obtains those keys can forge authentication data the server will trust. Because ScreenConnect is a remote access tool, a hijacked session can mean hands-on-keyboard access to every endpoint it manages.
What happened
ConnectWise's bulletin classifies the bug as CWE-347 (improper verification of cryptographic signature) and gives it a CVSS 3.1 vector of AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H. ConnectWise rates its severity "Important" and its patch priority 1 (High), meaning it should be installed as an emergency change or within days. According to the advisory, versions before 26.1 kept a unique machine key per instance in server config files, and under certain conditions an unauthorised party could extract those keys and use them to authenticate sessions. Version 26.1 adds encrypted storage and management of machine keys and makes it easy to regenerate them.
ConnectWise says researchers have seen attempts to abuse disclosed ASP.NET machine key material, but it told Help Net Security it has no evidence of exploitation against its hosted instances and no confirmed IOCs. This is not the first time ScreenConnect has had machine-key trouble: in April 2025 ConnectWise fixed CVE-2025-3935, a ViewState code-injection flaw that could be exploited once machine keys were compromised.
Who is affected
- On-premises ScreenConnect, all versions before 26.1. Upgrading requires an on-prem licence that is under maintenance.
- ConnectWise Automate partners with on-prem ScreenConnect integration, who get 26.1 from the Automate Product Updates page.
- Cloud-hosted ScreenConnect: already updated by ConnectWise, so no action is needed.
- MSPs and internal IT teams, and through them every client endpoint reachable from a ScreenConnect instance.
What it means for developers and engineering teams
ASP.NET uses the <machineKey> validation and decryption keys to sign and encrypt data that travels through the client: ViewState, forms-authentication tickets and other protected payloads. The server trusts anything that verifies against those keys. So the keys are effectively a master credential. If they leak through a readable web.config, a backup archive, a support bundle or a snapshot, an attacker can create payloads the server accepts as genuine, including authenticated sessions or, in the worst case, serialized objects that lead to code execution.
Remote monitoring and management (RMM) tools like ScreenConnect are valuable targets because one server reaches hundreds or thousands of endpoints, often across several MSP clients at once. ScreenConnect has been hit before: CVE-2024-1709, an authentication bypass disclosed in February 2024, was widely exploited within days. Any RMM console should be treated as tier-zero infrastructure, monitored and patched with the same urgency as a domain controller.
The lesson applies to any web stack, not just .NET. Session-signing secrets (SECRET_KEY in Django, secret_key_base in Rails, JWT signing keys, cookie secrets in Express) carry the same risk. They often sit in plaintext config, end up in images and backups, and are almost never rotated. Treat them like production database passwords: keep them in a secret store, scope who can read them, and design so you can rotate them without downtime.
What to do now
- Upgrade on-prem instances to ScreenConnect 26.1 now. Renew maintenance first if needed.
- Regenerate machine keys after upgrading. If old keys ever leaked, upgrading alone doesn't make them worthless.
- Restrict access to configuration files, backups, exported config archives and old VM snapshots to the smallest possible set of admins and systems.
- Review authentication logs and admin actions for unexpected sessions, new users or changed extensions since well before the patch date.
- Keep the console off the open internet where you can: put it behind a VPN, SSO-aware proxy or IP allowlist.
- Remove untrusted or unused extensions and keep the rest up to date.
- Check your own apps: find where signing secrets live (
grep -R "machineKey\|SECRET_KEY\|secret_key_base" .), move them into a secret manager, and document how to rotate them.