ScreenConnect CVE, Why This Remote Access Platform Keeps Turning Into a Priority-One Security Problem

Remote access software occupies a strange place in enterprise security. It is rarely the largest product in an environment, rarely the most glamorous, and often treated as operational plumbing. But when that plumbing is exposed to the internet, tied to administrator workflows, and trusted to bridge technicians into customer systems, a single weakness can become an organization-wide problem. That is why ScreenConnect CVEs keep drawing outsized attention. The issue is not simply that ScreenConnect has had vulnerabilities. The issue is that ScreenConnect often sits in a position where authentication flaws, trust-boundary mistakes, extension handling bugs, or cryptographic secret exposure can cascade into remote control, downstream access, and broad operational compromise. (ConnectWise)

The public record over the last three years shows a clear pattern. In 2024, defenders were forced to respond to a critical authentication bypass and a related path traversal flaw that became one of the fastest-moving remote management incidents of the year. In 2025, attention shifted toward ViewState code injection and the security of ASP.NET machine keys. In late 2025 and early 2026, the focus expanded again to extension trust, configuration exposure, certificate-signing extension behavior, and new hardening around server-level cryptographic material. Taken together, these disclosures tell a larger story about identity, trust, and the unusually high blast radius of internet-exposed remote support infrastructure. (Huntress)

If you only remember one thing from this article, it should be this: a ScreenConnect CVE is rarely just a version-matching problem. It is usually a question about whether a high-value management surface is exposed, whether identity boundaries can be bypassed or replayed, whether secrets have been mishandled, and whether an attacker can turn that position into real administrative control. That is why the right response is not “patch when convenient.” It is “treat this like priority-one infrastructure until proven otherwise.” (Unit 42)

The ScreenConnect CVEs that matter most right now

Public search results and current advisory coverage make one thing obvious: when practitioners look up “screenconnect cve,” they are overwhelmingly being pulled toward a small cluster of incidents. CVE-2024-1709 and CVE-2024-1708 still dominate because they were widely exploited, heavily analyzed, and operationally memorable. CVE-2025-3935 matters because it reframed the conversation around ViewState and machine keys. CVE-2025-14265 and CVE-2025-14823 matter because they widened the threat model to extension trust and configuration exposure. CVE-2026-3564 matters because it shows ConnectWise is still tightening protections around server-side cryptographic material as of March 2026. (NVD)

That cluster maps well to the way real defenders should think about the product. The first wave was about identity bypass. The second wave was about code execution through server-side trust mechanisms. The third wave was about whether configuration and cryptographic material were being protected as if they were effectively root-of-trust assets. Those are not disconnected bug classes. They are different expressions of the same operational truth: a remote management platform becomes dangerous very quickly when its trust anchors are weak. (Huntress)

CVE-2024-1709 and CVE-2024-1708, the incident that changed how teams triage ScreenConnect

The 2024 ScreenConnect crisis started with two vulnerabilities disclosed by ConnectWise in February 2024 and remediated in version 23.9.8 or later for on-prem deployments, while cloud instances were already addressed by the vendor. ConnectWise’s bulletin made clear that all on-prem partners should upgrade immediately and later removed license restrictions to help older customers move forward. (ConnectWise)

The two CVEs were assigned quickly. CVE-2024-1709 was an authentication bypass using an alternate path or channel in ScreenConnect 23.9.7 and earlier, while CVE-2024-1708 was a path traversal issue affecting the same versions. Huntress summarized the pair on February 21, 2024 and described the exploitation path as “trivial and embarrassingly easy,” while Rapid7 updated its own advisory the same week to note exploitation in the wild. (Huntress)

Palo Alto Unit 42’s incident reporting gives useful scale. As of February 21, 2024, Unit 42 observed 18,188 unique IP addresses hosting ScreenConnect globally and warned that CVE-2024-1709 was trivially exploitable, that proof-of-concept exploits were already available, and that even a Metasploit module had been released. Unit 42 also noted that CISA had added CVE-2024-1709 to the Known Exploited Vulnerabilities Catalog with a federal remediation deadline of February 29, 2024. That is the kind of timeline defenders should pay attention to: internet exposure, working tradecraft, and KEV inclusion within days. (Unit 42)

The underlying mechanics are worth understanding at a high level because they explain why the incident escalated so fast. IBM’s analysis captured the operational heart of the problem: CVE-2024-1709 allowed requests to a SetupWizard path variant to reach initialization logic even on already configured instances, effectively reopening a boundary that defenders assumed had already been closed. CVE-2024-1708, meanwhile, enabled file-placement behavior tied to extension handling. Alone, that was already serious. Combined with the authentication bypass, it gave attackers a credible path from unauthenticated access to administrative control and code execution outcomes. (IBM)

This is why the 2024 ScreenConnect story remained so sticky in the security community. It was not just another “patch now” web advisory. It was a vivid example of how remote support software can fail at the exact layers that matter most: setup state, authentication gates, and privileged extension behavior. In practice, that means the technical bug class almost understates the risk. What really matters is the product’s role. A vulnerable public web app is bad. A vulnerable remote management surface with administrative reach into customer environments is worse. (Unit 42)

Why ScreenConnect became such an attractive target

Threat actors did not need much persuasion. CISA’s joint Black Basta advisory said that starting in February 2024, Black Basta affiliates exploited CVE-2024-1709 to obtain initial access. CISA’s Medusa ransomware advisory in March 2025 again referenced ScreenConnect CVE-2024-1709 among the vulnerabilities being exploited by that ecosystem. IBM also noted that by late February 2024, ransomware groups such as Black Basta and Bl00dy were exploiting the ScreenConnect flaws, and later reporting tied further activity to Chinese state-linked and initial-access-broker tradecraft. (CISA)

That threat interest is rational. Remote monitoring and management products are trust concentrators. They are used to authenticate technicians, reach endpoints, run support actions, and often bridge from vendor or MSP operations into customer estates. Compromise one public-facing ScreenConnect instance, and the attacker is no longer dealing with a single application boundary. They are dealing with a gateway into admin workflows. That is why the 2024 incident quickly drew attention from ransomware operators, not just opportunistic scanners. (IBM)

The global exposure data from Unit 42 made the target set plain. More than 18,000 unique IPs were visible in February 2024, with the United States accounting for the highest share. In an ecosystem where speed matters, a widely deployed, remotely accessible, management-grade platform with a trivial auth bypass is exactly the kind of opportunity attackers prioritize. (Unit 42)

CVE-2025-3935, when the story shifted from auth bypass to machine keys

If 2024 was the year defenders learned to fear ScreenConnect’s exposed setup and extension paths, 2025 was the year they had to think much harder about ASP.NET machine keys. ConnectWise’s April 24, 2025 ScreenConnect 25.2.4 bulletin described CVE-2025-3935 as a ViewState code injection issue affecting version 25.2.3 and earlier. The vendor explained the crucial condition plainly: if machine keys are compromised, attackers could craft a malicious ViewState and potentially achieve remote code execution on the server. Cloud environments were patched by the vendor, but on-premises users needed to update. (ConnectWise)

This vulnerability landed into a broader industry context that made it more important, not less. In February 2025, Microsoft Threat Intelligence reported observing malicious activity in December 2024 where an attacker used a publicly available static ASP.NET machine key to perform ViewState code injection and deliver the Godzilla post-exploitation framework. Microsoft said it had identified more than 3,000 publicly disclosed machine keys that could enable these attacks and recommended organizations stop using public keys, rotate them, and investigate for persistence if compromise was suspected. (Microsoft)

That Microsoft research matters because it explains why CVE-2025-3935 was never just a vendor-specific edge case. It sits at the intersection of insecure key management, ASP.NET trust material, and real-world adversary tradecraft. When machine keys are exposed, reused, disclosed, or stolen, ViewState can become a route to code execution. In other words, what looks like “just another web framework detail” is actually a cryptographic trust problem with infrastructure consequences. (Microsoft)

The situation became more urgent in June 2025. CISA added CVE-2025-3935 to the Known Exploited Vulnerabilities Catalog, and Qualys summarized the agency’s warning by noting that users were urged to patch by June 23, 2025. Public reporting that followed connected the bug to a broader ConnectWise security event. ConnectWise’s own May 28, 2025 advisory said the company had learned of suspicious activity tied to a sophisticated nation-state actor affecting a very small number of ScreenConnect customers, had engaged Mandiant, and had implemented enhanced monitoring and hardening. (CISA)

The exact relationship between the 2025 advisory, cloud-side activity, and CVE-2025-3935 was not perfectly transparent in every public statement, and that ambiguity itself became part of the story. However, multiple public reports summarized the situation as activity isolated to ScreenConnect with patching on April 24 and later KEV inclusion for CVE-2025-3935. BleepingComputer’s reporting noted that ConnectWise had patched the issue on its hosted platforms before public disclosure and that public discussion centered heavily on machine keys and cloud-hosted instances. The Hacker News later reported that ConnectWise confirmed malicious activity was linked to exploitation of CVE-2025-3935. Because some timeline details remained murky in public, the most careful framing is that CVE-2025-3935 was treated by CISA as known exploited and was publicly associated with a meaningful security event affecting a small number of customers. (BleepingComputer)

That matters for defenders because it changes how they should prioritize work. If your security program still treats machine keys as mere configuration trivia, the 2025 ScreenConnect story is your warning. They are trust anchors. They deserve the same seriousness you would give to signing keys, SSO secrets, or privileged service credentials. (Microsoft)

CVE-2025-14265 and CVE-2025-14823, the less flashy issues that still matter

The easiest mistake in vulnerability triage is to focus only on the cleanest pre-auth headline and ignore the issues that require some level of privilege, access, or product familiarity. ScreenConnect’s 2025 disclosures show why that is dangerous.

ConnectWise’s December 2025 bulletin for ScreenConnect 25.8 addressed CVE-2025-14265. According to both ConnectWise and NVD, versions prior to 25.8 had extension subsystem weaknesses that could allow the installation and execution of untrusted or arbitrary extensions by authorized or administrative users, potentially leading to custom code execution on the server or unauthorized access to configuration data. The vendor stated there was no evidence of exploitation at the time and emphasized that host and guest clients were not impacted. (ConnectWise)

On paper, some teams will downgrade that immediately because it is not an unauthenticated internet bug. In practice, it is still important. Administrative abuse in a management product is not a minor issue. In a real environment, “authorized or administrative user” can mean a compromised MSP account, a delegated technician identity, a stolen admin session, or a persistence foothold after some earlier intrusion. Once you understand the product’s position in the environment, extension trust becomes an operationally serious attack surface. (ConnectWise)

CVE-2025-14823 told a related story through a different mechanism. NVD recorded that in deployments using the ScreenConnect Certificate Signing Extension, encrypted configuration values, including an Azure Key Vault-related key, could be returned to unauthenticated users through a client-facing endpoint under certain conditions. ConnectWise’s update moved configuration handling fully server-side in version 1.0.12 or later to prevent encrypted values from being transmitted to clients. (NVD)

This is exactly the kind of issue defenders sometimes wave away because the exposed values remain encrypted. That is not a safe reflex. Sensitive cryptographic or configuration artifacts should not be appearing in unauthenticated responses at all. Even when confidentiality impact appears limited, this kind of leakage can give attackers material for chaining, fingerprinting, replay attempts, architectural insight, or future secret-handling abuse. The lesson is broader than the CVE itself: in remote management infrastructure, configuration exposure is rarely as harmless as it first looks. (NVD)

CVE-2026-3564 and ScreenConnect 26.1, hardening the real root of trust

The newest major ScreenConnect security development came in March 2026. NVD describes CVE-2026-3564 as a condition that may allow an actor with access to server-level cryptographic material used for authentication to obtain unauthorized access, including elevated privileges, in certain scenarios. ConnectWise’s 26.1 bulletin says the release introduces enhanced protections for machine key handling, including encrypted storage and management, specifically to reduce the risk of unauthorized access when server integrity may be compromised. (NVD)

This is important because it shows where the vendor itself believes the security boundary really lives now. By 2026, the product direction is clearly acknowledging that machine key material is central enough to deserve dedicated hardening. BleepingComputer’s March 2026 reporting summarized the issue as one that could allow hijacking of sessions or unauthorized actions if machine key material were disclosed, and noted that ConnectWise recommended tighter access controls around configuration files, log review for unusual authentication activity, backup protection, and extension hygiene in addition to upgrading. (BleepingComputer)

At the same time, public reporting was careful to distinguish between tangible risk and confirmed exploitation. ConnectWise reportedly said it had seen attempts to abuse disclosed ASP.NET machine key material in the wild but had no evidence that CVE-2026-3564 specifically had been exploited in hosted ScreenConnect as of publication. That is a useful reminder that defenders should avoid two opposite mistakes: assuming every new ScreenConnect bug is already burning your environment, or assuming a hardening bulletin is harmless because it lacks a dramatic exploitation headline. The right read is subtler. When a vendor changes how authentication-related cryptographic material is protected, it usually means the design surface is important enough to deserve immediate attention. (BleepingComputer)

Older context still matters, including the disputed code-signing story

There is one older ScreenConnect-adjacent CVE that still deserves mention because it reinforces the same theme of trust anchors and signed execution. NVD’s entry for CVE-2023-25718 describes a disputed but serious issue in ConnectWise Control, formerly ScreenConnect, involving cryptographically flawed code-signing controls that could allow tampering with trusted signed executables. The record notes debate around scope and overlap, but the broader takeaway remains useful: when remote support tooling weakens trust in signed components, the downstream risk is not theoretical. It is about whether users and systems can be tricked into accepting malicious content as trusted software. (NVD)

I would not make CVE-2023-25718 the centerpiece of a current ScreenConnect article. The 2024 through 2026 issues are more operationally relevant right now. But it belongs in the background because it fits the pattern: the product’s risk is amplified whenever authentication, extensions, signing, or cryptographic trust boundaries are mismanaged. (NVD)

The pattern across ScreenConnect CVEs

By this point, the common thread should be visible. These incidents are not random. They cluster around a handful of design realities.

First, ScreenConnect is often internet-facing. Unit 42’s 18,188-host observation in February 2024 demonstrated how broad the exposed attack surface can be. (Unit 42)

Second, ScreenConnect commonly operates at high privilege. Whether it is used by internal IT, external service providers, or MSPs, it often sits close to administrator identity and endpoint control. That raises the reward for attackers and the cost of defender delay. (IBM)

Third, several of the important ScreenConnect issues are really about trust material, not just parser bugs. Setup state, extension integrity, machine keys, configuration secrecy, and certificate-signing behavior all determine whether the platform believes a request, artifact, or action should be trusted. When those trust decisions fail, attackers can convert a narrow weakness into administrative reach. (Huntress)

Fourth, exploitation does not need to look identical across cases to justify priority. Some vulnerabilities are near-trivial and internet-reachable, like CVE-2024-1709. Some require compromised keys or privileged access, like CVE-2025-3935 or CVE-2025-14265. In a management product, both categories are meaningful. One threatens initial access. The other threatens post-compromise amplification, persistence, and deeper administrative abuse. (Unit 42)

What defenders should actually do

The first job is asset truth. You need to know which ScreenConnect instances exist, whether they are cloud-hosted or on-premises, which versions they run, and whether they are still reachable from the public internet. That sounds basic, but the 2024 incident showed how many organizations either did not know or did not move fast enough when they found out. Unit 42’s exposure measurements and Censys’s later inventory work around CVE-2025-3935 both underline the same point: these systems are discoverable, enumerable, and often visible enough to become priority targets. (Unit 42)

The second job is patching by security boundary, not by calendar convenience. For the 2024 vulnerabilities, ConnectWise said on-prem users needed at least 23.9.8, while cloud instances required no customer action. For CVE-2025-3935, the patch target was 25.2.4 or later. For CVE-2025-14265, it was 25.8. For CVE-2026-3564, it is 26.1. These are not cosmetic update numbers. They are boundary changes tied to authentication, key handling, or trust validation. (ConnectWise)

The third job is key hygiene. The Microsoft guidance on ASP.NET machine keys is directly relevant beyond ScreenConnect itself. Public keys should never be copied from documentation or repositories. Fixed keys should be reviewed and rotated. If you discover disclosed or compromised keys in your environment, rotation alone may not be enough because persistence may already exist. Microsoft explicitly recommends deeper investigation and, in some cases, rebuild considerations for web-facing servers. That is a much more serious response model than teams usually apply to “config cleanup,” and it is the correct one. (Microsoft)

The fourth job is monitoring for signs that ScreenConnect’s trust boundary is being touched. That means watching access to web.config and machine.config, reviewing IIS worker behavior for suspicious assembly loading, monitoring unusual authentication events, and watching for administrative account creation or extension changes in the product itself. Rapid7’s February 2024 coverage noted new detection content for attacker techniques around adding a new user, while Microsoft’s guidance for ViewState key abuse included concrete monitoring for configuration-file access and IIS worker process anomalies. (Rapid7)

The fifth job is to treat backups, snapshots, and old exports as sensitive sources of cryptographic material. ConnectWise’s March 2026 guidance emphasized protecting backups and old data snapshots. That is easy to overlook, but if secrets persist in older backups, attackers do not need your live production host to win. They need one restorable or readable copy of the right material. (BleepingComputer)

A practical patch matrix

The version and remediation data above come directly from ConnectWise and NVD records. The risk interpretation is the practical security reading of those advisories in the context of real-world exploitation and management-platform exposure. (ConnectWise)

Detection and validation examples you can use safely

Below are defensive examples, not exploit material. They are designed to help teams inventory, monitor, and investigate.

PowerShell, identify fixed machine keys in IIS application configs

This follows Microsoft’s recommendation to review environments for fixed machine keys instead of relying blindly on inherited or copied values. Adapt the search scope to your web roots and configuration management model. (Microsoft)

Get-ChildItem -Path "C:\inetpub","D:\WebApps" -Recurse -Filter "web.config" -ErrorAction SilentlyContinue |
  Select-String -Pattern "<machineKey" |
  Select-Object Path, LineNumber, Line

A hit here is not proof of compromise. It is a signal that the application may be using explicit machine keys and should be reviewed for whether those keys are unique, rotated, and properly protected. Microsoft’s guidance is clear that if disclosed keys have been used, key rotation alone may not be sufficient and deeper host investigation may be required. (Microsoft)

KQL, look for suspicious access to web.config and machine.config

Microsoft specifically recommends auditing these files and reviewing Windows Security Event ID 4663 for unusual access. The following query is adapted from the Microsoft guidance and is a good starting point for broader IIS and ASP.NET investigation. (Microsoft)

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4663
| where ObjectName contains "web.config" or ObjectName contains "machine.config"
| summarize StartTime=min(TimeGenerated), EndTime=max(TimeGenerated), Count=count()
  by Computer, SubjectUserName, ProcessName, ObjectName, AccessMask
| order by Count desc

Look for access by unexpected accounts, unusual maintenance windows, or processes other than the expected IIS and deployment tooling paths. Microsoft notes that unexpected users or processes touching these files can indicate tampering or attempts to compromise machine keys. (Microsoft)

IIS log triage, find suspicious SetupWizard requests

For environments still doing retrospective hunting around the 2024 incident class, unusual requests involving the setup wizard path deserve review. This is not an exploit recipe. It is just a simple scoping method to find potentially relevant traffic in historical web logs. Huntress and IBM both emphasized the unusual role of SetupWizard.aspx in the 2024 attack chain. (Huntress)

Get-ChildItem "C:\inetpub\logs\LogFiles" -Recurse -Filter *.log |
  Select-String -Pattern "SetupWizard.aspx" |
  Select-Object Path, LineNumber, Line

From there, correlate by source IP, status code, user agent, and time window. If the period overlaps your vulnerable versions, do not stop at the web log. Check for account creation, extension changes, new binaries, unusual child processes, and suspicious activity on any endpoints reachable from the affected ScreenConnect instance. (Rapid7)

Exposure hunting, a simple external query pattern

Censys published platform queries to identify exposed ScreenConnect instances while cautioning that exposure does not itself prove vulnerability. That is the right mindset. Use external search to scope assets, then combine that with version truth and internal ownership data before taking action. (Censys)

host.services.software: (vendor: "ConnectWise" and product: "ScreenConnect")
or web.software: (vendor: "ConnectWise" and product: "ScreenConnect")

What a mature response looks like

A mature ScreenConnect response is not “scan and patch.” It is closer to a mini-incident workflow.

First, inventory every instance and classify cloud versus on-prem. Second, upgrade to the right fixed version for the relevant advisory. Third, review whether any static or exposed machine keys exist and whether they have ever been stored in repositories, deployment packages, exports, or backups. Fourth, preserve and analyze logs before rolling too aggressively if compromise is suspected. Fifth, review the product for new users, privilege changes, extension modifications, and abnormal authentication events. Sixth, assume that if a web-facing ScreenConnect server was truly exploited, persistence and downstream movement are more important than the initial request path that got the attacker in. (ConnectWise)

This is one of the most important judgment calls security teams can make. Remote management products are not ordinary software in the kill chain. They are control-plane software. That means compromise analysis should extend beyond the server itself into every trust path the server owns: operator accounts, technician identities, managed endpoints, extension packages, integration secrets, and related administrative tooling. (IBM)

The hardest part of a ScreenConnect incident is often not reading the CVE. It is proving whether the vulnerable condition is actually present in your environment, whether the exposed path is reachable, whether the trust material has been mishandled, and whether your remediation really closed the loop. That is where an AI-assisted validation workflow is more useful than a scanner-only workflow. The operational challenge is not “tell me the CVE exists.” The operational challenge is “show me whether my exposure is real, what evidence supports that conclusion, and whether the fix changed reality.” That is a natural place for a platform like Penligent to fit into the process. Instead of stopping at version-matching, it can sit in the verification layer: exposed management surface review, safe validation of reachable conditions, evidence collection, and re-test after patching. Penligent’s own public materials consistently emphasize verified findings and reproducible reporting rather than generic alert volume, which is exactly the posture teams need for remote management risk. (Penligent)

There is also a broader workflow benefit. ScreenConnect cases often force defenders to correlate multiple dimensions at once: internet exposure, privilege context, key handling, trust boundary changes, and post-patch verification. Penligent’s surrounding public content leans into that “proof over noise” model, which is useful here because ScreenConnect is a category where false confidence is expensive. If your team already knows the CVE IDs but still cannot tell whether your own instance was truly exposed or whether the patch actually neutralized the dangerous path, then the next problem is not more CVE text. It is validation. (Penligent)

Further reading

• ConnectWise ScreenConnect 23.9.8 security fix
• ConnectWise ScreenConnect 25.2.4 security patch
• ConnectWise ScreenConnect 25.8 security patch
• ConnectWise ScreenConnect 26.1 security hardening bulletin
• NVD entry for CVE-2024-1709
• NVD entry for CVE-2024-1708
• NVD entry for CVE-2025-3935
• NVD entry for CVE-2025-14265
• NVD entry for CVE-2025-14823
• NVD entry for CVE-2026-3564
• Huntress analysis of CVE-2024-1709 and CVE-2024-1708
• Rapid7 analysis of the 2024 ScreenConnect flaws
• Palo Alto Unit 42 threat brief on CVE-2024-1708 and CVE-2024-1709
• Microsoft guidance on publicly disclosed ASP.NET machine keys and ViewState code injection
• CISA KEV catalog
• AI Pentest Tool, What Real Automated Offense Looks Like in 2026
• CVE category on Penligent Hacking Labs
• Shannon AI Pentesting Tool vs Penligent, What Security Engineers Should Actually Compare in 2026
• Rethinking Automated Vulnerability Discovery with LLM-Powered Static Analysis