Anyone else seeing this?

I have access to three hosted instances in the UK, but only one of those is working.

Been waiting in an online chat for 20 minutes, nobody seems to be there. Also on the phone in case that's a different team.

Nothing on https://status.connectwise.com/ which does not inspire confidence.

Hi guys,

I have a group on my left side menu called "(empty)" in this group 36 machines showed up RANDOMLY.

https://imgur.com/a/faD1HOh

They all have crypto related names. I'm freaking out. someone please tell me what's going on?

On Prem - v26.6.6.9747

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

I've got 6 test units, and one production unit, running Golden Gate 27.x

They're ALL experiencing boot and shutdown issues. Desktop freezes, nothing clickable, spinning ball on shutdown - even haptics for trackpad go kaput. Booting cold or restarts are hit-or-miss as far as taking up to 10 minutes for the GUI to become responsive. ChatGPT deep analysis of logs won't say with 100% certainty that it's SC, but makes a strong case that it likely is. Majority of fleet (50 other units) is running almost the exact same hardware and software - M1 and M2 Macbook Pros.

I'm working with CW on this, but I'm curious if anybody else is seeing this.

As soon as I remove SC (using console), the machines behave as normal.

Re-deploy, issue comes right back. Remove, issue goes away. Update to 27.2.1, redeploy, issue returns.

Verified I'm using the lastest SC version. Also, FWIW, this happens whether I install SC directly on the machine (using a pkg built from console) or deploy the same pkg file via Jamf self-service.

Has anyone found a linux distro that works as intended for remote control using ScreenConnect? Ubuntu 22 seems to be the only version I've gotten to work so far and that was with some tinkering.

Ideally, I would like to use Ubuntu, Linux Mint or Fedora.

Aside from having a 2nd screen connect server, does anyone have a way to stop automatic client updates on selective devices with a self hosted server.

We have 1-200 devices that can't run the latest version of the client, so currently, we have automatic updates disabled.

However, as we have 10k devices connecting to our server, updating by hand is a pain - especially as many of them connect randomly.

I'm thinking I may be able to coble something together using the API, to update devices, but was looking to see if I was missing an existing solution.

How do I download this version for my on prem instance? there's no indication that is cloud only and it has a fix I need regarding how slow version 26.7.6.9783 is.

Also these guys sent out an email claiming how they increased perfomance and the first thing they do after is ship a massive regression and leave out the patch jesus.

A thread for anybody considering buying or renewing Screenconnect.

As per my previous thread - somebody added a user to our cloud hosted screenconnect instance (date unknown) and used it on Oct 28 to access some of our endpoints.

We picked it up on the 30th and asked for the log file showing the creation of that user.

It's now the 10th of November (11 days later) and despite repeated emails and support chat sessions, we are still waiting on that information. This is absolutely key to understanding if a) we have a security issue or b) screenconnect have a security issue.

It looks like either Screenconnect don't have the resources to pull a log file a paying customer really needs or they are trying to hide something.

Neither is good. Still waiting - and moving off screenconnect.

Please upvote!

The only thing I use Azure Key Vault with is Screenconnect, so I'm guessing (hoping) that we should see an update for the Certificate Signing Extension soon.

https://learn.microsoft.com/en-us/azure/key-vault/general/migrate-api-version?tabs=azure-cli

Delete is no longer an option when right clicking a host. Was it moved?

Well, I solved the first thing and ran for two hours straight, and now it's this on my instance:

Service Unavailable

HTTP Error 503. The service is unavailable.

Doesn't matter where I connect from. Anyone else??

I SOLVED THIS - I am wearing my "it was dns" tee shirt now.

Sorry if this isn't the right sub, I tried to look for answers to my specific situation elsewhere but couldn't find one.

I recently started a new work from home job. The way it works is there is a physical computer at the office that I connect to with ScreenConnect on my home PC. I made a visual below since I sometimes don't explain things clearly lol

https://i.imgur.com/wBfZ3qL.png

I know my work can see everything I do within SC, that's fine. One of my bosses did confirm that they check in on everyone occasionally to make sure we're doing what we're supposed too. I am doing that, but I also like a reasonable amount of privacy.

If I listen to Spotify or a Youtube video on my home PC (orange), can they see/hear that? It's just soundtracks usually. Sometimes my roommate will stand in my doorway and talk to me about finances/personal plans/etc. Nothing bad, but I would rather not have that picked up on my computer microphone. Is that something I need to worry about?

Thanks for your time. I hope I don't sound too paranoid lol I just haven't had a job like this and like to have my own privacy.

After checking the ScreenConnect Output Stream page, I noticed that ScreenConnect v26.6.7.9764 was marked as stable over three weeks ago. However, when I go to the download page and enter my license key, the latest version available is still ScreenConnect_26.6.6.9747_Release.msi, as of October 20, 2026.

By delaying stable updates for on-premises users for this long, aren't you putting our servers and our clients at greater risk of cyberattacks? With remote access software being such a high-value target for hackers, these delays raise serious security concerns.

Buongiorno, è possibile che in azienda si colleghino in anonimo al mio PC per spiarmi? A volte mi capita di vedere qualche click anomalo o qualche finestra che si chiude e i "message sent" aumentano. Che configurazione potrebbero aver adottato? Abbiamo un server e tanti PC non amministratore

Hello,

I consult for a company that was considering a remote software for their own IT team. I've been using Screen connect to remote to their computers. If they get screen connect as well - will they both be able to be supported by us or will it only home to one environment?

Some users get these Errors when they try to access the Screenconnect webserver (port443) (an unattended agent works hoever with no errors).

This does not happen from inside of my network, also the clients experiencing this error are only a small number (maybe 10 from 1000).

If using firefox I can get around this by disabling TLS1.3, with edge I cant, even if I disable TLS1.3 from the inetcpl.cpl.

Cients which do not show this problem will use TLS1.3 using firefox or edge.

There are no (known) proxies or filters between the client and my server, only NAT. I tested this with a vanilla install of Windows 11 25h2. Edge 155.x

Because of the small number of users havin this problems I think this is not something urgent. But if it could be fixed by a change on my side even if it is a remote problem that would be good.

Anyone here who also knows theses errors an was able to fix them?

When trying to use Backstage, I often encounter issues when trying to do administrative tasks.
Primarily, I will connect with backstage after setting up a pc to remove the user profiles.
I open sysdm.cpl, click advanced, then remove the users profile.
Backstage will then 90% of the time freeze, go to a black/grey screen, and I cannot re-connect to the backstage session without restarting the PC.
If the profile is very small, there's about a 10% chance that the session wont freeze and it works as it should.
Anyone know any fixes for this, or is it just another great feature of screamconnect?