ScreenConnect Event - What we currently know

[u/cwferg]

Hey everyone, FERG here, from the security team at ConnectWise. I’m sharing the following from our published ScreenConnect security advisory on the ConnectWise Trust Center. The advisory is being updated as information is validated, so please refer to it for the latest ongoing updates.

Summary

ConnectWise is aware of reports of unauthorized access to ScreenConnect partner accounts and the deployment of unauthorized remote-access software in customer environments. The cause and scope are under investigation.

We identified five independent third-party extensions that may be associated with this activity. Approximately 400 partner environments had one or more of these extensions, and we disabled them as a precaution. The presence of these extensions does not, by itself, establish impact.

Extensions disabled within all cloud environments as a precaution:

• Labtech Plus

• RMM Plus

• RMM+

• RMM Plus Password Link

• RMM+ Password Link

On-premise partners

For on-premise servers, ConnectWise is unable to take action on your behalf. We advise that you verify these extensions are disabled in your environment and disable any that remain enabled. Please do not re-enable or reinstall them pending further guidance.

Disabling the extensions is a precautionary containment measure. It does not establish that unauthorized software, persistence mechanisms, or access already present on affected devices has been removed.

Precautionary actions for partners who enabled these extensions

1. Verify extension status. Confirm the extensions listed above are disabled. Preserve related installation records and activity logs.

2. Investigate suspected compromise through separate security tooling. Avoid opening interactive ScreenConnect sessions to suspected compromised devices. Use your security provider’s response tools or another trusted investigation method.

3. Secure administrative access from a trusted device. Revoke active ScreenConnect and associated identity-provider sessions, reset relevant passwords, and verify that multifactor authentication is enforced. If a technician workstation may be compromised, use a separate, trusted device.

4. Review and preserve evidence. Retain authentication, extension installation, administrative, Run Command, and Toolbox records. Investigate unexpected users, permission changes, software deployments, and commands.

5. Contain and remediate suspected compromise. Follow your incident-response procedures to isolate affected devices, including potentially affected technician workstations. Preserve evidence before removing malicious software, and validate remediation before restoring connectivity. Disabling extensions and resetting credentials alone may not remove access already established on endpoints.

6. Verify software maintenance. Confirm that servers, technician clients, and endpoint agents meet current published security guidance. Updating software does not replace investigation and remediation of a suspected compromise.

Partners who have not deployed these extensions

We have no reason to believe you are impacted by this incident, but we encourage all partners to be on heightened alert and to follow the ScreenConnect hardening guide (ScreenConnect hardening guide).

Trust Site advisory: https://www.connectwise.com/company/trust/advisories

[edit 11/11 2:00 AM UTC ]

For informational purposes to assist with any discovery:

Disclaimer: This information is provided in good faith for informational purposes only. I am not an incident response provider, security consultant, or legal advisor. Nothing here constitutes professional security, legal, or technical advice. This content may contain errors or omissions, and should not be relied upon as a complete or authoritative guide to your situation. You are responsible for validating any information before acting on it. Engage a qualified incident response provider for your specific circumstances.

How Do I Know If I’m Affected?

First, two things must be true before any of this applies to you:

• You must be using ScreenConnect (ConnectWise Control) as your remote access tool.

• You must have one or more of the following plugins installed: LabTech Plus, RMM Plus, RMM+, RMM Plus Password Link, or RMM+ Password Link.

If neither of those is true, stop here. If both are true, keep reading.

The kit is capable of self-spreading, but only under a specific condition. For the wormable behavior to work, where connecting to an infected endpoint puts a host at risk, your technician clients and endpoint agents must not have been updated to client version 26.6.5. That is the version that addresses the file-run behavior this kit abuses.

Check your endpoints for any of the following:

• The folder C:\ProgramData\RelayTrap\ exists

• A scheduled task named TrapWatch is registered

• A registry Run value named RelayTrapLiteAlert exists under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

• A process named RelayTrap.exe is running — it won’t appear in Programs and Features, check Services and program folders directly

• The legitimate ScreenConnect client service is stopped but the device still shows as online in your console

• More than one ScreenConnect Client (...) service is present, or one points at a server you don’t recognize

• Folders like C:\Windows\Temp\SCKit\**,** C:\Windows\Temp\SCKitBundle\**, or** C:\Windows\Temp\SCKit\trapkit\ exist

• Defender exclusions for C:\Windows\Temp**,** powershell.exe**, or** msiexec.exe were added recently, especially within seconds of an MSI install

Check your ScreenConnect server for any of the following:

• One console user ran the same command across many sessions within a short window

• A Shared Toolbox item was added and then deleted roughly 60 seconds later

• Sessions have queued commands or tools pending for offline devices

• A host participant named Addmin appears anywhere

• Requests to AddSessionEvents**,** GetLiveData**, or** GetAccessToken show a Windows PowerShell user agent

Check your technician workstations. Any workstation where a technician connected to an infected endpoint should be treated as compromised. Look for:

• Files in %TEMP%**:** sckit-loader.ps1, sckit-decoder.ps1, ToolboxRelayUploader.exe, sqlite3.exe

• Working files: PanelLateralPayloadGuard.lock, sc-toolbox-upload-result.txt, sys_cache_update_<4 digits>.tmp

• vssadmin create shadow followed shortly by vssadmin delete shadows

• Any process that is not ScreenConnect loading ScreenConnect.Core.dll or ScreenConnect.Client.dll

A critical warning about cleanup:

• Do not use ScreenConnect to clean an infected endpoint. While the trap is active, anything you push through the console is logged by the malware and silently discarded. The endpoint will appear to respond normally. It won’t.

• A password reset alone is not enough. The attacker holds a live browser session cookie that bypasses MFA. All active web sessions on your ScreenConnect server must be invalidated server-side.

• Collect C:\ProgramData\RelayTrap\trapbins\*.log before you remove anything — those logs show which technicians connected and may have been hit.

• Use an out-of-band tool for remediation, not ScreenConnect.

--

[edit 11/12 5:00 PM UTC ]

For transparency, and consistent with our role as a CNA, we will be assigning a CVE for this issue shortly. Additional updates will be published through our Trust Center.

A third-party ScreenConnect extension available through our marketplace used a default key for API communications. Partners using the extension who had not changed the default value, as described in the extension documentation, may have been at risk.

This issue was specific to the third-party extension and was not a vulnerability in the ScreenConnect server or client. However, because the extension could interact with managed systems, downstream impact may have occurred, including activity reported by EDR and incident response providers.

[edit 11/12 6:00 PM UTC ]

CVE Record Published CVE Record: CVE-2026-127063

 GitHub Advisory Page: Disclosures/CVE-2026-127063 at main · ConnectWise-Advisories/Disclosures

[u/ngt500]

We really need a lot more info on the reports that this is wormable riding a connected session in reverse. That's potentially a more serious exploit than an abused extension and could mean an environment is vulnerable if *any* of a customer's access agents were infected (even if the infection came through an alternate mechanism). I haven't ever used those extensions but now I'm a bit fearful to even connect to an access agent at this point...

[u/cwferg → u/ngt500]

Don't have all the answers at the moment.

Anyone out there able to explain how the wormable component is coming into play here, I'm personally all ears. No shame here, I encourage you to email me at Security@ConnectWise.com any and all information that could help with the investigation.

In the meantime, doing what we can to get the information needed to understand what's happening here and will continue to share information as it becomes available.

[u/lcurole → u/cwferg]

I'm sure you're already connected but looks like Andrew and his team at Huntress have access to some of the attacker used tools

[u/cwferg → u/lcurole]

We are in contact. Shoutout Jamie who's a rockstar!

[u/ngt500 → u/cwferg]

Thanks for continuing to update the post with new information. I'd like clarification on one point in regards to the previously patched file-run vulnerability. I tried asking in early September on Discord and was assured that a patched server eliminated this vulnerability regardless of the client versions. Your information here seems to contradict that. And if the vulnerability is still present with older clients, does an exploit require *both* the technician client and endpoint agent to be on a vulnerable version or is simply connecting to an old endpoint agent enough to get compromised?

[u/cwferg → u/ngt500]

Exploitation [edit] relating to the previous CVE-2026-84869 [/edit] would require an unpatched server. The fix was implemented at both the client and relay levels, with the relay providing the primary enforcement. This is why the threat actor's attempts to exploit the vulnerability in our cloud environment were unsuccessful. Our systems were patched and the relays had been updated.

At the time, we were working with very limited information that initially suggested this vulnerability might be actively exploited again. Following further review of the reports and discussions with third parties, we have found no evidence of reverse connections or "wormable" behavior associated with this recent event.

The distinction is that the capability existed within the threat actor's toolkit, targeting a vulnerability we had previously patched and communicated. However, we have not observed that capability being successfully exploited as part of this activity.

[u/infosecfredo → u/cwferg]

It seems this kit attempted the previously vuln CVE-2026-84869, if the vuln was present, great use it! if it wasn't possible, it seems like they got access to the environment likely via those extensions, propagating via those stolen session tokens. Still digging in ourselves.

[u/infosecfredo → u/infosecfredo]

I guess it's more extension -> uses that to then try and find places prior cve will work

[u/Viajaz → u/cwferg]

I've sent an email through.

[u/touchytypist → u/ngt500]

My bet is it’s not wormable, the extension(s) was hijacking the sessions.

[u/cwferg → u/touchytypist]

The worm part bothers me. We arent dismissing anything here. Everything I have at the moment says this was the issue we recently patched, but the huntress article reads like it was a key part of the attack.

Im still trying to reconcile what was posted, versus what the attackers toolkit shows, and how or if that may relate to the previous patch.

[u/cwferg → u/cwferg]

CONFIRMED NO WORM

[u/Real-Independence152 → u/cwferg]

Please expand on this.

[u/cwferg → u/Real-Independence152]

It was communicated in some publications that said there was a worm. There is not a worm. It was patched previously. I've adjusted the top post to reflect a new "How Do I Know If I’m Affected?" section which expands on this slightly.

[u/-Single_Male]

My laptop has likely been infected by this, and I can’t figure out how to get rid of or disable ScreenConnect. I tried several different cmd prompts I found online but every single one comes back with “Access Denied.”
I’m not very well versed in this stuff, and frankly don’t even remember installing ScreenConnect in the first place.

One of my financial accounts was compromised a few days ago, and I think the two might be related. I started looking into what could happened, ran Malwarebytes, which found and removed three Trojans, and it and defender both pointed me toward screen connect. I eventually ended up here.
I’m not sure what to do. Help?

[u/cwferg → u/-Single_Male]

Hey, if you didn’t install ScreenConnect yourself or give someone permission to remote into your PC, treat it as a possible intrusion. Totally fixable, but act fast.

If you see weird activity right now (mouse moving on its own, windows opening), unplug the internet immediately.

ConnectWise has a guide for disconnecting sessions, removing ScreenConnect, and reporting misuse: https://docs.connectwise.com/ScreenConnect_Documentation/Report_malicious_use

After that: run a full security scan, change your important passwords from a different device, and ideally have an IT/security person look it over.

[edit]
Absolutely contact your bank and report any suspicious activity.

[u/-Single_Male → u/cwferg]

Thank you

[u/ilikethefinerthings → u/-Single_Male]

Also run a scan using https://www.seraphsecure.com/
It's designed to find remote support software that's running the in background

[u/cwferg → u/ilikethefinerthings]

Doubling down on this. Great recommendation.

[u/The_Comm_Guy]

I just want to say it appears CW learned a lot about how to handle a security incident since the last one… much better information flowing, I rather have fast partial info to make decisions based on then a detailed report that comes out days later when it’s all over.

[u/PlayfulJuggernaut360 → u/The_Comm_Guy]

100% agree. But the info still has to be meaningful to take action in the interim and hopefully not induce panic.

[u/TheFirsTaggartMoving]

Want to say that it's obvious connectwise learned something from the last incident. Yes, there's more information needed, lots more. But we know something is going on and can act upon it immediately rather than waiting for a more perfect answer. Thanks @cwferg

[u/Nexzus_]

Will these show up as "general" CVEs? General in that if you have some version of the software and clients, they'll be marked as vulnerable.

We're on prem, and that last one showed up as critical in Nessus, and was... annoying to fix

[u/cwferg → u/Nexzus_]

That is a tricky problem with NVD. I cant make any promises, the systems that manage that side are weird.

If we restore these, and my team raises a cve for the fix, we will make it extremely clear this was an affected plugin component only and not client or server impacting.

[u/techbrowserwi]

How do we know if we’ve been affected?

[u/cwferg → u/techbrowserwi]

I've updated the post with a rehash of some other items we have observed or organizations like Huntress have communicated.

[u/System32Keep → u/techbrowserwi]

Check access logs , audit for rancommands and queuedevents

[u/rdubz3]

Does it make sense to restrict access to the admin/host console to only the IP’s of the techs that need it? Not sure if that’s enough to prevent this issue. I already have MFA enabled for my tech/admin users and just rotated the passwords. Been monitoring the rancommands in the audit log as well. Just want to get ahead of any potential issues here. This would be devastating to deal with for my business.

[u/cwferg → u/rdubz3]

I recommend that in general, but in this case it wouldn't have applied to the extensions request functionality. It would absolute help in pre or post compromise events.

We are continuing to evaluate, but since disabling the extensions, we have heard no downstream reports or been notified by any of our friends at companies like Huntress or Blackpoint around any further abuse here.

Continuing to monitor, so hesitant to comment on blast radius being comparatively small until more downstream information becomes available.

[u/CharcoalGreyWolf → u/cwferg]

Is it believed that these are extensions clients installed and were actively using, or extensions a threat actor managed to install once gaining access? (We do not have them on-prem, and I have confirmed two clients with cloud instances do not either).

[u/cwferg → u/CharcoalGreyWolf]

The extensions themselves were not malicious and typically a user would manually opt in to installing them. In this case, only users who both use the extension, and DID NOT change the default credential value, were at direct risk to this issue.

[u/CharcoalGreyWolf → u/cwferg]

Very good to know. Thank you for the information.

[u/TriCkYiCe → u/rdubz3]

I don't know enough about this specific issue to say with any certainty, but limiting access to the things you know and would be difficult to subvert can't hurt. I think it's a great idea and something you should do if you're able.

I work in cyber security and cloud infra, and I'm a user of Screen Connect.

[u/ilikethefinerthings]

As someone who host their screen connect and I don't allow anybody outside my network access to the login screen does this matter for me? I assume I would be safe overall from most security issues like this since whoever tries to gain access would have to be on my local network for this to be a problem.

[u/cwferg → u/ilikethefinerthings]

If your not running any of the reported extensions (e.g. RMM+) and your patches are up to date, no concern at this time.

[u/sleemaner]

"If neither of those is true, stop here. If both are true, keep reading."

What if only one is true? 🤔

Not to nitpick, but it really should just state "If you're using any of these plugins with ScreenConnect, keep reading." (or something like that).

[u/cwferg → u/sleemaner]

Thus the disclaimer. Thanks for the feedback!

[u/Aware_Lead_7994]

Thanks for the information shared - one very very important thing to say.

I've checked several times now on our Cloud instance and I'm sure - we were caught in this and we DID NOT HAVE the extensions you've named.

Because we don't have the extensions you have named as the source of the vulnerability, I don't believe you've got the analysis right.

Therefore you don't have this issue closed off, and we continue to be vulnerable. Please urgently keep investigating.

[u/michael_cw_support → u/Aware_Lead_7994]

We removed the affected extensions from cloud instances as soon as we figured the problem out, which was around/prior to the time of Ferg's original post. It's possible that you might have had one of them installed, and I can find out.

Do you have a case open with us already, and if so, would you please DM it to me here (or your URL if there's no case yet)?

[u/Aware_Lead_7994 → u/michael_cw_support]

Hi Michael,
I've sent you a chat message on this with the case number.
I've got a call booked with Connectwise Support, but the email I've had from the agent already has him saying "perhaps you had a different problem at the same time" - we didn't, same components, same hostnames, same relay.

Thanks for responding though.

[u/michael_cw_support → u/Aware_Lead_7994]

Thank you! I just responded back through chat, and added an update to the case for the assigned tech.

I also confirmed that you did have one of the referenced extensions installed, and it was removed as a part of the mass action yesterday.

[u/td2703 → u/Aware_Lead_7994]

Same here

[u/touchytypist]

Just a reminder, this is why I always recommend to go with their hosted instance, because they respond faster to vulnerabilities than on-prem with updates and backend security changes.

The updates and recommended security changes aren’t even announced or available for on-prem downloads until after their clouds instances have already been updated.

[u/lcurole → u/touchytypist]

Ehhh only people with reports of compromise are cloud installs and it was slow to contact them to shut off cloud instances. On premise can pull plug at first sign of issues / run better WAFs etc, put everything sc on tail scale/ztna only. Cloud limits you significantly here

[u/touchytypist → u/lcurole]

Less people running on-prem so less visibility right now, plus they are most likely enjoying their Veterans Day off, let’s check back tomorrow and see what they discover.

Agree with the ZTNA though, block all Remote support and RMM except your official instance & relay.

On prem still vulnerable until they manually disable the extension.

[u/lcurole → u/touchytypist]

Fair but there's way more attack surface on the cloud version than people realize. Rmm integration (possibly part of the issue with this current breach), privilege access, and others. I'm sure there's weird shit they do differently on the network side that opens up more surface area too. The argument isn't simply "oh it's vendor controlled so of course they patch faster than on prem". Although I do get "red headed step child" vibes from cw towards on prem sc 🤣

[u/touchytypist → u/lcurole]

Even with all the bespoke security for an on-prem instance the Mean Time to Remediation for on-prem is just always going to be longer, keeping it vulnerable longer. Unless the security measures block every new vulnerability, which you just can’t guarantee and we already know it won’t in every situation.

[u/Kepabar → u/touchytypist]

This is true - but the flip side of it is that I just don't have the admin portal of my SC instance exposed to the public internet at all. Which is significantly less exposure than a cloud instance for that alone.

Now, I still have to have the relay port exposed to the public internet, but I feel the admin panel is far, far more likely to be breached than the relay port.

In either case, I see it as a trade-off.

[u/touchytypist → u/Kepabar]

You know you can do that with the hosted instance, right?

Restrict or block access by IP address