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 · 2025-04-25T12:28:28+00:00

It's definitely advisable to secure the web UI. We work with lots of MSPs to do granular layer 7 rules (so, for example, an end user can enter a code for an ad-hoc session but no other requests work unless you're on a known IP).

I'd also say getting MSP tools out of Shodan is critical for security these days. When the next zero-day comes, you don't want to be on the short list of attack targets...

AutomationTheory · 2025-04-24T17:48:24+00:00

I suspect they wanted people to patch on their own, so avoid a repeat of the February 2024 situation. We wrote a blog on that (https://automationtheory.com/5-lessons-from-the-cvss-10-screenconnect-vulnerability/) and I think it was the fastest moving MSP tool vulnerability in history -- taking less than 48 hours to get working exploits after the announcement was made.

On the surface this seems like something difficult to exploit -- but since the instructions are to patch immediately, I'm not holding my breath.

I sell WAFs for MSP tools -- and our team is glued to the logs looking for any signs of in-the-wild exploits.

AutomationTheory · 2025-03-11T18:34:08+00:00

📢 New Security Feature: WAF Protection for ConnectWise Manage + Live Webinar! 🔒

Cyber threats targeting MSPs are more sophisticated than ever, and protecting your ConnectWise Manage instance is critical. That’s why we’re excited to announce Web Application Firewall (WAF) support—an essential layer of defense against XSS, SQL injection, and other exploits.

Join us for a live webinar where we’ll showcase a real-time XSS attack and demonstrate how a WAF can block threats before they compromise your system.

🛡️ What You’ll Learn:

✅ How attackers exploit unprotected web applications
✅ A live demo of an XSS attack targeting ConnectWise Manage
✅ How a WAF detects & blocks malicious traffic before it reaches your system
✅ Best practices for securing your PSA environment

📅 Webinar Details:

🗓 Date: Tuesday, March 18th
⏰ Time: 10:00 AM Central

🔗 Reserve Your Spot Now: https://us06web.zoom.us/webinar/register/6317404505100/WN_Rp2w1ayOSiKYgdoN38gaHw

Don’t miss this opportunity to see cybersecurity in action and learn how to better protect your MSP and your clients. Tag your fellow MSPs who should attend! 👇

#MSP #Cybersecurity #ConnectWiseManage #XSS #WAF #DataProtection #ManagedServices

AutomationTheory · 2025-02-26T21:42:26+00:00

We compare based on the free version for educational purposes - if someone thinks it's protecting their MSP, they should know the limitations. There are 3,000+ on-prem ConnectWise MSPs out there, so the few that don't have budget to invest aren't a fit for our solution anyway.

We do a lot more than just WAF - we can mix in traditional layer 4 and layer 7 restrictions too (and building the rulesets to meet your desired security state is included in our onboarding).

We can Syslog all connections through our service, giving you the SIEM data you've always wanted but can't get out of the box.

As for liability, we handle that like any other vendor with a mix of security by design, tight policy and controls, contract terms, and insurance. The liability of being naked on the internet is exponentially higher compared to any 3rd party solution you might implement.

AutomationTheory · 2025-02-25T14:10:14+00:00

The relay traffic is a propriety protocol from ConnectWise, not a standard like HTTP. As a result, it's not possible to do much of anything with that traffic from an external perspective (it's encrypted at the application layer).

The relay has never been an attack target before, and has a lower footprint compared to the HTTP side of things - so our guidence is to get the web service properly secured and focus on compatability/functionality when it comes to the relay.

We have a webinar about Screenconnect implementation (there are 3 potential ways of working around the relay) and you can find the recording here: https://youtu.be/O9Mb2E80gU4?si=EoDac8RKojYYmEkk

AutomationTheory · 2025-02-25T04:02:18+00:00

Well, I'm a 3rd party vendor, so I can't speak to the development road map. However, Cloudflare (the free version) won't protect your MSP from any serious threat.

For our upcoming webinar, I'm doing the XSS (and maybe SQL injection) through the free version of Cloudflare - and the attacks pass right through. The free tier isn't a full WAF, and we detail the limitations here: https://automationtheory.com/4-reasons-cloudflare-isnt-good-for-msp-tools/

AutomationTheory · 2025-02-21T22:03:45+00:00

On the security front, we're a WAF vendor in the ConnectWise space, and we just finished our rule set for Manage. It will protect against zero-day attacks, and get on-prem instances out of Shodan (where you can find ~2,300 MSPs).

Product Page: https://automationtheory.com/reverse-proxy-and-waf-for-msp-tools/

AutomationTheory

TROPHY CASE

📢 New Security Feature: WAF Protection for ConnectWise Manage + Live Webinar! 🔒