CISA put the ScreenConnect file-transfer flaw on its Known Exploited Vulnerabilities catalog on Thursday with a Monday deadline and a forensic-triage obligation, and the thing that has to be updated is the client on every endpoint, not the server.
What happened
CVE-2026-84869 was added to the Known Exploited Vulnerabilities catalog on September 11, 2026. Its entry carries a dueDate of 2026-09-14 — Monday — and a forensicTriage value of Yes, the BOD 26-04 obligation under which an agency must not only remediate inside the window but also assess whether the asset has already been compromised. Its knownRansomwareCampaignUse value is Unknown.
CISA’s catalog names it the “ConnectWise ScreenConnect Improper Privilege Management and Missing Authorization Vulnerability” and describes it this way: “ConnectWise ScreenConnect contains both an improper privilege management and missing authorization vulnerability that may allow an attacker to file transfer and execution through an active remote sessions without authorization or host confirmation.”
The underlying record was published to NVD at 8:18 p.m. UTC on September 8, 2026, and is now in Analyzed status. It carries CVSS 3.1 of 9.9 with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, and two weaknesses: CWE-269, improper privilege management, and CWE-862, missing authorization. The record picked up its CISA catalog fields at 2026-09-11T19:57:11.373.
ConnectWise’s own disclosure, dated September 8, 2026 and published in the company’s advisories repository on GitHub, assigns the same 9.9 and the same vector. Its description is narrower than CISA’s: “A condition in the ScreenConnect client may allow files to be transferred and executed through an active remote session without authorization or Host confirmation in certain circumstances. ScreenConnect servers are not impacted.”
That last sentence governs everything about how this gets fixed. The vulnerable component is the client — the Support session client and the Access agent that sit on managed endpoints. ConnectWise’s remediation instructions reflect it. For cloud-hosted deployments: “No action is required. ScreenConnect servers hosted in the ScreenConnect cloud environment have been updated to remediate this issue,” followed immediately by “We recommend updating your host clients and access agents.” For on-premises: upgrade to ScreenConnect 26.6.5 or later, with a note that out-of-maintenance licenses must be renewed before the update can be installed.
Where the update cannot be applied immediately, ConnectWise offers a mitigation that is explicitly not a substitute: in Administration > Security > Roles, edit each role, review every session group with permissions assigned, and deselect the TransferFiles permission. That has to be repeated for each role.
Two things the record and the vendor do not say the same way
ConnectWise names the affected products as “ScreenConnect versions prior to 26.6.5” and the fixed version as “ScreenConnect 26.6.5 and later.” NVD’s configuration for the same CVE names the boundary as versions prior to 26.6.5.9742. Those are not equivalent statements. One is a version, the other is a specific build of that version. An administrator who confirms the console reads 26.6.5 and stops there has satisfied the vendor’s written criterion; whether that satisfies the record depends on which build of 26.6.5 is installed, and the record says the safe boundary is 9742. ConnectWise’s release notes could not be retrieved from here to establish whether 26.6.5 builds below 9742 were ever shipped, so this is reported as a discrepancy rather than as a gap with a known size.
The second is where the advisory lives. NVD tags connectwise.com/company/trust/advisories as a vendor advisory reference for this CVE, and CISA’s catalog notes point to a bulletin at connectwise.com/company/trust/security-bulletins/2026-09-08-screenconnect-bulletin. That bulletin URL returns 403 to automated fetching. The advisories index, fetched successfully, lists two items, both from February 2024, concerning CVE-2024-1709. CVE-2026-84869 does not appear on it. The readable primary source for this flaw, as of Saturday afternoon, is a markdown file in a GitHub repository.
What “exploited” rests on
CISA’s catalog is a catalog of exploited vulnerabilities, and the CISA Coordinator SSVC block attached to the CVE record sets Exploitation to active. It also sets Automatable to no and Technical Impact to total.
The public evidence underneath that is thinner than the listing implies, and it is worth being precise about. The research NVD references is Huntress’s writeup on rogue ScreenConnect installations, last updated September 9, 2026, with earlier updates on September 3 at 5:45 p.m. ET and September 8 at 9 p.m. ET. Huntress describes a consistent pattern across unrelated endpoints in several organizations, anchored to three incidents — two on August 20 and one on August 24 — in which rogue ScreenConnect clients repeatedly spawn the Windows Script Host to execute four VBScript files named 1.vbs through 4.vbs. Huntress gives no host count.
Those incidents predate the September 8 disclosure, and Huntress does not claim they are exploitation of CVE-2026-84869. What it documents is attacker-controlled ScreenConnect clients being used to push and run scripts — the capability this CVE describes, arrived at by a different route. ConnectWise’s disclosure says nothing about exploitation at all.
So the position is: the agency says active, the researcher describes an adjacent abuse pattern without tying it to the CVE, and the vendor is silent. That does not make the listing wrong — CISA acts on evidence it does not always publish — but a defender reading the catalog entry as a report of confirmed in-the-wild exploitation of this specific flaw is reading more than the public record carries.
Why it matters
Remote monitoring and management software is the highest-leverage software in most environments that run it, because one console reaches every endpoint that matters and the tooling is designed to transfer files and execute them. That is the product working correctly. A flaw that removes the authorization step from that path does not create a new capability; it removes the consent gate on one that already reaches everywhere.
The operational problem here is the shape of the fix rather than its difficulty. Most patch programs are built around servers and around inventoried applications. A ScreenConnect server upgrade is a familiar, schedulable, single-target operation. Reinstalling host clients and refreshing access agents across a fleet is a different task with a different owner, a different change window, and a much worse completion-tracking story, and it is the task that actually closes this flaw. Cloud customers are the ones most exposed to getting this wrong, because the first line they read tells them no action is required — which is true of the server they do not operate and false of the agents they do.
For managed service providers the multiplier is the business model. An MSP’s ScreenConnect estate is not one fleet but every client fleet, and the agent update has to reach all of them. The out-of-maintenance license note in ConnectWise’s remediation is worth reading twice in that context: an on-premises deployment whose license lapsed cannot install the fix until the license is renewed, which converts a security deadline into a procurement step.
The forensic-triage flag is the part federal agencies should read first. Remediating does not discharge the obligation. The entry requires determining whether the asset was compromised before the update landed, and the flaw’s own description — files transferred and executed through an active session without host confirmation — describes activity that leaves traces on the endpoint rather than the server. The place to look is the same place that has to be patched.
What to do
On-premises: upgrade ScreenConnect to 26.6.5 or later, and confirm the installed build rather than the version string — NVD’s boundary is 26.6.5.9742. Automate-integrated deployments update through Automate Product Updates. Renew a lapsed license first if one is blocking the install.
Cloud: the servers are already updated, but the clients are not. Reinstall host clients and reinstall or upgrade access agents, and track completion across the fleet rather than assuming it.
If the update cannot land before the deadline, deselect the TransferFiles permission on every role with session-group permissions assigned, per ConnectWise’s instructions, and treat it as temporary.
Federal civilian agencies: the deadline is Monday, September 14, 2026, and the entry carries the forensic-triage obligation. Plan endpoint triage alongside the update, not after it.
Sourcing note
The catalog entry, its dateAdded, dueDate, forensicTriage value, vulnerability name, and short description were read from the full KEV catalog JSON at the cisagov/kev-data GitHub mirror, retrieved on September 12, 2026; cisa.gov returns 403 to automated fetching, so the mirror is the route used, and the file carries CISA’s own catalogVersion of 2026.09.11. The NVD record for CVE-2026-84869, including its timestamps, CVSS metrics, weaknesses, affected configuration, and CISA fields, was read from the NVD API on September 12, 2026. ConnectWise’s description, scores, affected and fixed versions, remediation steps, and mitigation were read from the company’s own disclosure for CVE-2026-84869 in the ConnectWise-Advisories/Disclosures repository. The Huntress findings were read from the company’s published writeup.
Not reached: ConnectWise’s security bulletin of September 8, 2026, which returns 403 to automated fetching, and the ScreenConnect release notes, which failed with a redirect loop. Unresolved: whether builds of 26.6.5 below 26.6.5.9742 exist and are therefore vulnerable while reading as the fixed version, and what evidence CISA acted on in setting Exploitation to active, given that the only public telemetry describes incidents predating the disclosure and does not attribute them to this CVE.
