CVE-2025-3935

What it actually does

ScreenConnect 25.2.3 and earlier can be abused through ASP.NET Web Forms ViewState deserialization/code injection if an attacker has obtained the application’s ASP.NET machine keys. With valid machine keys, an attacker can craft a signed/encrypted malicious ViewState value that the server accepts as trusted state data, leading to server-side code execution. This is a server-side risk affecting the ScreenConnect web application, not the ScreenConnect client, and the vendor addressed it in ScreenConnect 2025.4 by disabling ViewState and removing dependency on it.

Why it matters to the business

Successful exploitation can give an attacker control of a ScreenConnect server, which is especially high impact because ScreenConnect is commonly used for remote administration and support. Compromise can lead to unauthorized remote access operations, credential theft, persistence, lateral movement, service disruption, and loss of trust in remote support infrastructure. This issue is listed in CISA KEV, has active in-the-wild exploitation, and the remediation deadline of 2025-06-23 has passed, so unpatched exposed systems should be treated as urgent even though exploitation requires prior compromise or theft of machine keys. No ransomware use is indicated in the provided KEV context.

How an attack unfolds

An attacker first needs access to the ASP.NET machine keys used by the ScreenConnect server, typically through prior privileged compromise of the host, theft of configuration files or backups, exposure of deployment secrets, or compromise of systems that store the keys. Once the keys are known, the attacker creates a malicious ASP.NET ViewState object that is cryptographically valid for the target application. The attacker then sends the malicious ViewState to a vulnerable ScreenConnect web endpoint that accepts ViewState. Because the server can verify the ViewState using the compromised keys, it deserializes/processes the supplied state and executes attacker-controlled code in the server context. After execution, the attacker may run commands, deploy web shells or tools, access ScreenConnect data, create or abuse administrative accounts, stage remote access, and use the server as a foothold for broader intrusion activity. CISA KEV status indicates this behavior has been observed in active exploitation, so investigations should not assume the weakness is theoretical.

How to fix it

Upgrade ScreenConnect servers to ScreenConnect 2025.4 or later, which disables ViewState and removes dependency on it. Treat any ScreenConnect 25.2.3 or earlier server as vulnerable if its ASP.NET machine keys may have been exposed. Because exploitation depends on compromised machine keys, also rotate ASP.NET machine keys and any related application secrets, remove exposed keys from backups or repositories, and ensure configuration files containing secrets are not accessible to unprivileged users. If compromise is suspected, perform incident response before returning the server to production: preserve evidence, isolate the host if needed, review administrative users and sessions, rotate local/domain/service credentials that could have been accessed, remove unauthorized extensions/tools, and validate that no persistence remains. Restrict administrative access to the ScreenConnect server, limit inbound exposure where possible, require MFA for administrative access, and monitor for abnormal child processes from the ScreenConnect/IIS web process.

How to confirm the fix worked

Confirm the installed ScreenConnect version is 2025.4 or later and that no vulnerable 25.2.3-or-earlier server remains reachable. Validate that ViewState is no longer used by the ScreenConnect web application after upgrade by reviewing application behavior and HTTP responses for absence of ViewState dependency. Inspect web.config and related ASP.NET configuration to confirm machine keys have been rotated if there is any possibility of exposure. From an external perspective, inventory all ScreenConnect web interfaces and verify their reported build/version, patch status, and exposure controls. Confirm that old server snapshots, backups, deployment packages, and configuration archives containing previous machine keys are protected or destroyed. Review server logs around the period before patching for suspicious POST requests carrying large __VIEWSTATE values and for unexpected process execution from ScreenConnect/IIS services.

Typical attack path

1. Identify an internet-facing or otherwise reachable ScreenConnect server running version 25.2.3 or earlier.
2. Obtain the target server’s ASP.NET machine keys through prior privileged host access, stolen configuration, exposed backups, leaked secrets, or another compromise path.
3. Generate a malicious ViewState payload that is valid for the stolen machine keys.
4. Send an HTTP request containing the malicious __VIEWSTATE data to a vulnerable ScreenConnect web endpoint.
5. Trigger server-side code execution under the ScreenConnect web/server process context.
6. Run reconnaissance commands, retrieve configuration or credentials, and establish persistence.
7. Use ScreenConnect’s administrative position to support lateral movement, remote access abuse, or further compromise.

How to detect it

Investigate both prerequisite compromise and ViewState exploitation. Review ScreenConnect application logs, web access logs, Windows Event Logs, IIS/ASP.NET logs if present, EDR telemetry, process creation logs, PowerShell logs, and file integrity data. Look for large or unusual HTTP POST requests containing __VIEWSTATE, __VIEWSTATEGENERATOR, or __EVENTVALIDATION parameters, especially to ScreenConnect web paths and especially from unfamiliar IP addresses. Search for ASP.NET ViewState validation or deserialization errors, which may indicate probing or failed payload attempts. Correlate suspicious web requests with process creation events where the ScreenConnect server process or IIS worker process launches command interpreters, scripting engines, download utilities, archive tools, or remote administration tools. Review access to web.config, configuration backups, deployment artifacts, and locations containing machineKey values to determine whether keys were stolen. Examine ScreenConnect audit logs for unexpected administrator creation, role changes, session activity, extension installation, command execution, or remote support actions. Because active exploitation is confirmed through KEV, perform retrospective hunting back to at least the publication window and any period when the server ran 25.2.3 or earlier.

• __VIEWSTATE
• __VIEWSTATEGENERATOR
• __EVENTVALIDATION
• machineKey
• System.Web.UI.ViewStateException
• Validation of viewstate MAC failed
• LosFormatter
• ObjectStateFormatter
• ScreenConnect.Service.exe
• ScreenConnect.WebServer.exe
• w3wp.exe spawned cmd.exe
• w3wp.exe spawned powershell.exe
• ScreenConnect.Service.exe spawned cmd.exe
• ScreenConnect.Service.exe spawned powershell.exe
• ScreenConnect.WebServer.exe spawned cmd.exe
• ScreenConnect.WebServer.exe spawned powershell.exe
• /web.config
• C:\Program Files (x86)\ScreenConnect\
• C:\Program Files\ScreenConnect\

What your security team should do

• Immediately identify all ScreenConnect servers and prioritize any internet-facing instance running 25.2.3 or earlier.
• Upgrade to ScreenConnect 2025.4 or later; because the KEV remediation date has passed, treat unpatched systems as overdue and high priority.
• Assume exposed machine keys are sensitive credentials: rotate ASP.NET machine keys and remove historical keys from insecure storage, backups, repositories, and deployment artifacts.
• Hunt for exploitation before and after patching, focusing on suspicious ViewState-bearing requests and unexpected child processes spawned by ScreenConnect or IIS worker processes.
• Review ScreenConnect administrative users, roles, sessions, audit logs, extensions, scripts, and remote access activity for unauthorized changes.
• Rotate credentials that may have been accessible from the ScreenConnect server, including local admin, service, domain, API, and integration credentials where applicable.
• Restrict ScreenConnect management access with network allowlisting, VPN or zero-trust access controls, MFA, and least-privilege administration.
• If suspicious activity is found, isolate the server, preserve forensic evidence, and perform full incident response rather than only applying the patch.