ConnectWise probes ScreenConnect access via RMM+ and 3 more

What people are saying

Administrators and managed service providers (MSPs) on Reddit are sharing reports of an active campaign abusing ConnectWise ScreenConnect. A thread on r/sysadmin points readers to Huntress's writeup and to longer discussions in the MSP and ScreenConnect subreddits. The point drawing the most argument is a commenter's view that cloud-hosted instances are hit too, not only on-premises servers.

What holds up

ConnectWise's advisory says it is investigating reports of unauthorized access to certain partner ScreenConnect environments. It has found no evidence of a compromise of ConnectWise infrastructure or a vulnerability in ScreenConnect itself. Its initial assessment points to a threat actor's abuse of independent third-party extensions installed in partner environments.

ConnectWise identified about 400 partner environments with at least one extension from the RMM+ family installed, and says their presence alone does not establish compromise. The initial access method and full scope remain under investigation.

Huntress says the activity seems related to the RMM+ extension. In versions 1.0.31 and 1.0.32, if an administrator had never configured the extension's access key, RMM+ would accept a blank one. The extension bypasses ScreenConnect's user accounts, roles and multi-factor authentication (MFA). Huntress saw commands reach endpoints across several ScreenConnect instances within minutes, with no corresponding login activity.

On cloud: Huntress says ConnectWise disabled the extension on all hosted environments. In our reading, that means hosted instances could carry the same exposure. Confirmed compromises on either side have not been counted publicly. The core event holds up; scale and the worm framing do not yet.

Inside the threads

One camp treats this as a ScreenConnect problem, with a commenter calling it a "you get what you pay for situation." Another commenter pushed back, saying ConnectWise calls out on-premises customers only because it cannot disable extensions for them automatically, and that cloud is heavily affected. That cloud claim runs ahead of ConnectWise's wording, which counts environments with the extension installed, not confirmed compromises. Practitioners mostly pointed one another to the Huntress analysis rather than adding new evidence.

Our take

We think the cloud-versus-on-premises argument misses the point: the exposure lives in the extension, wherever it was installed. Huntress found most RMM+ installations were legitimate, usually added for a project and left in place. In our view, that is the real lesson: a forgotten add-on with a shared secret could sidestep every identity control around the tool. We think the worm label oversells novelty; this reads as an unmanaged credential problem with a large blast radius. What we think is underrated is the third-party angle: if your MSP uses ScreenConnect, your exposure depends on their extension hygiene, not yours.

What to do

• Ask each MSP whether any ScreenConnect instance had Labtech Plus, RMM Plus, RMM+ or the Password Link variants installed, and get written confirmation they are disabled.
• If you run ScreenConnect on-premises, disable those extensions yourself; ConnectWise says it cannot do it for you.
• Review ScreenConnect logs for commands linked to RMM+ that lack matching login activity.

What people are saying

A Cybernews report says Russian state-sponsored hackers breached government email servers in Romania and used new malware to intercept messages, including emails to and from North Atlantic Treaty Organization (NATO) and European Union officials. In a Reddit r/cybersecurity thread, commenters argued that the attackers hit a local Exchange server, not Exchange Online.

What holds up

The core event has independent coverage. BankInfoSecurity reports that ESET makes that attribution with high confidence.

ESET first found the toolkit, dubbed Cereal, in November 2025 on a government email server in Kazakhstan. It later found the same toolkit at a Romanian government organization. Cybernews puts the Romanian compromise at December 23, 2025, with the malware configured to pick out emails sent to or received from NATO and the EU.

One component, CerealBox, was embedded directly into an Exchange service that processes email traffic. The attackers also used the victim's own Exchange server as command-and-control infrastructure.

Two points remain open. Researchers could not determine how the attackers first gained access or how much information they obtained. The verdict is partly confirmed: the intrusions are established, but the scale and the entry point are not.

Inside the threads

One Reddit commenter said the initial break-in matters more than the hidden payload. Another said this looked like a local server breach and wrote "idk about the widespread panic this seems to be causing." Several others turned the discussion into criticism of running Windows servers and of Microsoft use in government. In our reading, the on-premises point is a fair inference from the description of code planted inside Exchange services, though ESET's findings as reported do not spell it out. A separate post on X about Russian military hackers breaking into defense contractors in two NATO countries describes a different claim and should not be merged with this one.

Our take

We think the headline framing overstates the reach. The victims were national government organizations whose mail traffic involved NATO and the EU, not NATO or EU systems. The underrated part is the tradecraft. Turla has targeted Exchange servers since at least 2014, and running control traffic through the victim's own mail server takes away the external indicators most teams rely on. Until the entry point is known, we would treat every on-premises Exchange server as a possible target for this kind of persistence, whatever its patch status. Teams in government, diplomatic or defense supply chains should give this the most weight.

What to do

• Hunt on Exchange hosts for the patterns ESET described: encrypted payloads on disk, nested.NET assemblies, legitimate Windows processes loading suspicious DLLs, and Exchange services running code that does not belong there.
• Review inbound web requests to Exchange as a possible control channel, not only outbound traffic.
• Confirm your Exchange version and support status. Microsoft says Exchange 2016 and 2019 security updates go only to customers enrolled in the Period 2 Extended Security Update program.

What people are saying

Danbooru posted a forum notice saying someone found a way to upload a malicious Flash post on November 4th, and that the site was down for a week while it responded. Aftermath reported that the site is back up, crediting its maintainers and LLMs. The notice also drew discussion on Lobsters.

What holds up

The core claim is confirmed by Danbooru itself. According to the notice, the main thing the worm did was grab the IPs of anyone who viewed the posts, and the site was shut down within about 6 minutes.

About 300 people ran the worm: 200 logged out and 100 logged in. The 100 logged-in users had their usernames and IPs harvested, and their accounts were temporarily hijacked to spread the worm. The notice says 7 people had backdoor API keys created, and those keys were never used and have been deleted. An attempt to harvest user email addresses through moderator accounts failed because the site was shut down first.

The entry point was a pull request submitted on 2026-10-28 to fix a thumbnail bug. Danbooru says the submitter was the attacker, and that the request itself contained no malicious code. The fix removed the only thing still blocking Flash uploads.

Danbooru says the servers were not hacked, and that there is no reason to believe anyone's accounts have been hacked. Its view that the attacker used LLMs to find the exploit is the site's own assessment.

Inside the threads

Commenters on Lobsters focused on the inverted pattern: "In this case attacker actually fixed a bug to enable the attack." One commenter asked whether the worm used Ruffle, a Flash emulator, to make same-site requests. Another pointed to the notice's admission that the player was not sandboxed. A third did not understand how getting a username and IP could lead to a backdoor API key. A reply cleared this up: the cross-site scripting (XSS) flaw let JavaScript take any action the visitor's browser could, and IP logging was not what granted access.

Our take

We think the corporate credential-reuse worry is overblown in this case, because nothing in the notice points to password theft. In our reading, the lesson is in the contribution pipeline. The pull request was harmless code that removed an accidental safeguard, so a code-only review would not have caught it.

That gap exists in most mature codebases. The fast shutdown and detailed public accounting are, in our view, a good model for small incident response. We would treat the claim about attackers using LLMs as the site's judgment, not established fact. The defensive point stands either way. See our secure-by-design guide.

What to do

• Ask teams that accept outside contributions to judge each change by what it newly allows, not only by whether the code looks malicious.
• Add regression tests that confirm disabled features and blocked file types stay off.
• Sandbox any embedded player or emulator that renders content users upload.
• Make sure API key creation and other sensitive account actions require a fresh login.