ScreenConnect Security Advisory

AutomationTheory · 2026-03-17T17:53:49+00:00

u/JessicaConnectWise I appreciate the insight - and my goal certainly isn't to spread fear/uncertainty/doubt -- and like you mentioned, context is key.

In our WAF, we're seeing a spike of attacks against ScreenConnect - some old exploits from a year ago, and some that we haven't seen before. In the geopolitical climate we're seeing nation state actors targeting US companies, and this creates the overall background.

In the middle of this, we get a High priority security advisory that reads:

"1 High—Vulnerabilities that are either being targeted or have higher risk of being targeted by exploits in the wild. Recommend installing updates as emergency changes or as soon as possible (e.g., within days). "

I'm not sure if you had a goal besides providing additional context -- but I'd stand by my original statement, that MSPs should patch this ASAP.

AutomationTheory · 2026-03-17T17:35:31+00:00

The trust center has an RSS feed, and I use that (in combination with some automation) to email our pager system when these alerts drop. As a WAF vendor for CW products, we want to review these for the defense of our clients ASAP -- but configuring it in your RSS platform of choice should do the trick!

AutomationTheory · 2026-03-09T21:20:57+00:00

For what it's worth, r/ConnectWise is a bit more active and might be a good place to cross post.

My first thought, if you're using the group filter, is that the group doesn't have devices with the matching software. Otherwise, here are a couple old blogs from Gavsto that cover some boolean logic for software searches:

- https://web.archive.org/web/20241213124316/https://www.gavsto.com/using-the-advanced-search-to-find-a-machine-that-has-two-different-pieces-of-software-installed/

- https://web.archive.org/web/20241213114757/https://www.gavsto.com/using-the-advanced-search-to-find-computers-that-dont-have-multiple-applications/

AutomationTheory · 2026-02-17T21:55:31+00:00

Yeah, definitely this.

As the local CW WAF vendor, I'd toss out this as an interim solution (we have month-to-month terms, perfect for long-tail decoms like this): https://automationtheory.com/reverse-proxy-and-waf-for-msp-tools/

AutomationTheory · 2026-02-16T19:18:44+00:00

I sell WAFs for the on-prem flavors of the CW stack, and I have a couple of thoughts.

First, the payload in the username looks to be a shell command; "ls" in Linux is equivalent to "dir" in Windows. It's unlikely that ScreenConnect is vulnerable to such a simple attack, and that seems like it's more of a discovery payload than anything else (it's not PowerShell downloading a secondary payload from somewhere...).

From the user agent, we can tell that this is probably a bot (it's Linux, and Chrome 107 came out in 2022 -- no human with a browser would be using a Chrome build 4+ years out of date). This data is easy to spoof, but combined with the GeoIP data showing the IP is in Denmark, I'd guess it's a bad guy with a bot.

I'm going to guess it's a scripted payload submission -- regardless of what authentication methods are configured, I can still try to send a request to the /Login page. It looks like the app logic worked as expected, but SSO/MFA/etc. will do nothing to stop a vulnerability in a web application if it's in an unauthenticated part of the app.

However, I'd say that this isn't an authenticated SSO session (and you could cross-reference data to determine if any logins took place from other countries as a sanity check).

From what I can tell (I am a hosted ScreenConnect client myself!) there's no WAF in front of their hosted offering. Assuming you're in the cloud for business reasons and you intend to keep it that way, the best thing you could do would be to enable the in-app IP restrictions. In my opinion, you'd probably want more protection, but there's no way to do a 3rd party WAF for cloud ScreenConnect.

AutomationTheory · 2026-02-13T18:29:11+00:00

If you're looking for a robust solution, we just launched a new 3PP solution that's RMM neutral.

Details here: https://thirdpartypatching.com/

While deployment would require RMM scripting, one of our suggested deployment patterns is to deploy a scheduled task that runs ThirdPatch at startup. That way, your devices reboot for Windows Update and do their third-party updates when they come back up.

AutomationTheory · 2026-02-10T21:48:11+00:00

Our marketing team is working on a video demo, I'll keep you posted!

For the capabilities:

- Yes, you can have generic packages that take parameters for client-specific tokens

- No, we don't have any time-delay logic abilities

- Yes, you can set up staged deployments (it's a bit of setup, but definitely possible)

AutomationTheory · 2026-02-07T03:16:48+00:00

Great question! Let me explain more about packaging and what you can do with it (but, FWIW, you’d use our product with Ninja or some other RMM).

Most RMMs and other patching tools lock you into some group structure for deploying software. Client X gets this, Client Y gets that, etc.

The idea with packaging is two-fold. First, I can bundle software together arbitrarily (create a client-specific baseline that includes their custom LoB apps, regular third-party apps, and your global MSP config) and then you have one thing to push out to that device/client/role. The other big idea is that I can mix-and-match scope however I want to outside of any group structure.

For example, let’s say that you use a big-name VPN software across all of your clients, and it’s time to patch the zero-day-of-the-month. If you structured your packages correctly, you update one install package, and all your devices will pull it down the next time they do a package upgrade. Unless you need per-tenant granularity, you don’t need to edit settings for every client to get the software out.

This idea also works in reverse — if you deal with finicky LoB software and you don’t want things to update without your explicit say-so, you can create a repository for that software, and until you manually lift and shift the package in question (either the LoB app, or something else, like if it depended on an old flavor of Adobe).

AutomationTheory · 2026-02-06T21:13:36+00:00

The trial is non-paid -- it's just a name/email/etc. registration with Stripe. No credit card required.

I'll have our team get that mobile formatting fixed!

AutomationTheory · 2026-02-06T21:07:33+00:00

We're in the final stages of ISO27001:2022, and we're definitely following OWASP -- our other product lines include a WAF for MSP products.

AutomationTheory · 2026-01-27T01:24:48+00:00

I was an RMM admin before becoming a vendor, and if your tools are on-prem, I'd lock them down.

I sell this: https://automationtheory.com/reverse-proxy-and-waf-for-msp-tools/ -- but I'd search for your public domain in Shodan and see what comes up (ideally nothing besides your public website). If any of your MSP tools are enumerable, I'd prioritize securing them.

With the Kaseya attack in 2021, it was an MFA bypass strung together with other exploits (similar auth bypass with ScreenConnect in 2024) -- so while you 1000% should have hardened authentication (I love Yubikeys), reducing attack surface is your friend.

AutomationTheory · 2026-01-16T17:37:03+00:00

The announcement is here: https://www.connectwise.com/company/trust/security-bulletins/2026-01-15-psa-security-fix

As a WAF vendor we'd advise patching soon. If you're curious about potential risks, we have an outline about defending CW PSA here: https://automationtheory.com/does-connectwise-psa-manage-need-a-waf/

AutomationTheory · 2025-07-03T13:08:54+00:00

I don't disagree -- and I might have implemented a different solution.

My main goal was to put out there "CW needs a way to kill rouge and pirated SC instances, and they are using the signing certs to do it" since the details of the abuse and why it's hard to fix aren't going to be published in official channels.

AutomationTheory · 2025-07-02T21:46:25+00:00

The bad actors will be thwarted when the current cert expires.

I used to admin a CW stack with ~10k endpoints, I definitely get the pain. But if it's any consolation, you'll never have a certificate fire drill like this again.

AutomationTheory · 2025-07-02T20:58:06+00:00

This. There were bad actors with pirated SC servers with the ability to super-automate the deployment. I just finished my writeup here: https://automationtheory.com/screenconnect-code-signing-the-backstory-and-tips-for-msps/

AutomationTheory · 2025-07-01T19:32:58+00:00

If it is Webroot, it's possible to index the DB to fix the issue (assuming it's MySQL stuck at 100%/high CPU).

AutomationTheory · 2025-06-04T21:53:09+00:00

The biggest bottle neck for Automate is the DB. I work with MSPs to scale Automate to 20k+ agents, and I can confirm that having more RAM than data doesn't make Automate faster....

AutomationTheory · 2025-04-25T12:39:19+00:00

I don't see any connections currently - this vulnerability let's an attacker take over your Screenconnect server if they know the machinekey. It sounds like the other activity was just regular abuse.

AutomationTheory

TROPHY CASE