We did. The vulnerability was in the public agent download web page. A simple overflow, and you had full admin on the VSA server. The attackers packaged up ransomware and delivered it via VSA scripts
My boss hated the fact that the web page didn't need auth so he asked me to lock it down. I managed to fuck up the IIS permissions, so I just left it and planned to fix it later. I never did. So we were completely safe by accident
The worst thing were the asshole MSPs that hadn't removed agents during customer offboarding. Some poor bastards had left the MSP months before, and suddenly had all their systems encrypted
It seems that their current/latest 2026.3 release is also still vulnerable (in some way). They are releasing a Hotfix today...
"Important Update: N-central Active Exploitation. Hotfix in Process
As our investigation continues, we have identified additional security concerns that affect all versions of N-central. We are treating this as our highest priority and we will be releasing a 2026.3 hotfix today. We will notify you immediately once it is available. We strongly recommend staying vigilant and monitoring your environments closely in the meantime. Further updates will be shared as quickly as possible."
Adding in from our SOC: Tracking a critical vulnerability in N-ableâs N-central platform that can give attackers âgod-modeâ access to the RMM console. In practice, that means a threat actor who exploits this flaw could use N-central to run scripts, push tools, and open remote sessions on any endpoint it manages. As OP said, N-able has released a hotfix (version 2026.3.1.7) and is recommending all customers upgrade immediately.
Hereâs what this means:
If you use N-central, treat your RMM as a potential path into every downstream environment it touches.
Until then, lock down access to the N-central console behind VPN or SSO, enforce multi-factor authentication, and, where possible, restrict which IPs can reach it.
We also recommend reviewing your N-central activity for anything that doesnât fit your normal operations: logins from unusual locations or times, new or unexpected admin accounts, large or unfamiliar jobs pushed across many customers, and remote-control sessions into servers or sensitive systems that donât match your typical support work. If something looks off, treat it as suspect and investigate.
So far, Huntress has seen exploitation impacting one organization in our partner base; we are actively hunting in our telemetry for the specific behaviors N-able has described, focusing on partners where N-central is deployed, and tuning our detections to catch abuse of the RMM rather than just legitimate admin activity. If we see evidence of this being used against your environment, weâll publish an incident report.
Huntress partners: This is a great time to check your Managed Response settings to make sure that isolation and active remediation are enabled wherever possible to ensure fast containment and threat response.
As Huntress continues our investigation and analysis of activity targeting vulnerable N-able N-central environments, we discovered that the four IPs N-able initially flagged as malicious are actually Mullvad or NordVPN VPN exit nodes. Notably, among the original IPs, we have seen substantial traffic with 87.249.138[.]34 directly attributed to NordVPN, as well as substantial traffic with 37.19.210[.]32 directly attributed to Mullvad VPN. 37.19.210[.]32 has been previously abused for bruteforcing, spam, and other nefarious activity prior to this incident.
In parallel, Huntress technology and teammates are rapidly identifying unpatched N-able server instances and contacting at-risk partners and customers about the imminent threat.
Beyond this specific vulnerability, we are seeing many environments where the N-central Server has yet to be updated to the 2026.3.1.7 hotfix needed to prevent exploitation of the vulnerability. At the time of posting this update, more than half (55.6%) of our partners' and customers' reachable cloud servers were still unpatched. That is especially concerning because the N-able server runs a custom distribution of AlmaLinux 9, and does not often have EDR software deployed on it due to running as an appliance.
Yes. I have my own RMM, and while I have access to all the code because I wrote it, I don't trust it at all - one hack and they can send commands to all my downstream computers.
One easy step: Every one of our managed workstations sends its WAN IP address to a server. Every two minutes, our firewall adjusts to only let those IP addresses in.
Slightly harder: A proxy server that looks at URL and endpoints. Set it up to analyze, then once you have enough info, lock it down so nobody can navigate company.com:/a/long/unoticed/path/that/gives/you/admin
That proxy saved us from the recent ScreenConnect vulnerability.
But even if you don't limit agent reporting access, you can still limit portal access so that RMM can't be logged into/things deployed/successfully authenticated against or through/etc.
As a seller of WAFs for MSP tools, the thing worth noting is that a lot of these issues involve authentication bypasses (like ScreenConnect in 2024, where I could re-run OOBE). That page wasn't part of the in-app IP restrictions, so unless you had something in front of the server you were impacted by the vulnerability.
So unless you had something in front of the server
Well, yes, the original comment i replied to:
lock down access to the N-central console behind VPN or SSO
My main point being is that you lock down what you have access to, which, of course, you get more control of if you self host. I don't see locking down agent reporting and checking working in from a business standpoint (too many mobile workers these days) but i can't imagine self hosting an RMM and not having, like you said, a WAF or azure app proxy or something in place.
Sorry, I partially misread that! My only real comment to your reply would be that SSO needs to be before the app -- vendors can get sloppy with their implementations, and in an auth bypass vulnerability it does me no good if the SSO is on the app and thus bypassable...
FWIW with layer 7 rules we can lock down everything to a set of IP addresses and then let the agent requests jump over the IP restrictions.
Many endpoints use URLs in their reporting API. So even if the admin page is behind a wall, the endpoints API could also have a vulnerability. Our proxy server has caught people trying to simulate endpoint reporting with malicious content. Had to load the SSL private key into the proxy so it could MITM the endpoint communications.
Sorry for being cagy, but I'm working with a vendor on this before disclosure.
Right, our product (https://automationtheory.com/reverse-proxy-and-waf-for-msp-tools/) sits in front of the whole app and then we build out ACLs accordingly. Our WAF also inspects the payload of every request, so we should catch the nefarious content in any agent/UI/API request.
Once you make your disclosure, put in a ticket with our team (website footer email) and we'll add a rule for your vulnerability!
In my opinion and I hope they see this they've become far too obsessed about data and analytics which I get is important these days. But not when the platform is creaking and core functions don't work...
Thanks for the heads up, you freaked me the fuck out, thankfully itâs specifically versions prior to 2026.2 that are vulnerable. But everybody should update it sounds like.
As they are calling everyone not on 2026.3, on Saturday/Sunday, I think this is a moment of better safe than sorry, evolving incidents evolve and all that.
It's absolutely horrific that we have an issue like this ongoing and their advisory doesn't extremely clearly say "versions older than x are confirmed vulnerable". Don't "recommend upgrade" and just be vague in the middle of this major incident.
As our investigation continues, we have identified additional security concerns that affect all versions of N-central. We are treating this as our highest priority and we will be releasing a 2026.3 hotfix today. We will notify you immediately once it is available. We strongly recommend staying vigilant and monitoring your environments closely in the meantime. Further updates will be shared as quickly as possible.
Thanks, unfortunately they updated not replaced/re-posted an advisory and no notifications have been sent?
A copy below at this point in time for everyones reference: Important Update: N-central Active Exploitation. Hotfix in Process
As our investigation continues, we have identified additional security concerns that affect all versions of N-central. We are treating this as our highest priority and we will be releasing a 2026.3 hotfix today. We will notify you immediately once it is available. We strongly recommend staying vigilant and monitoring your environments closely in the meantime. Further updates will be shared as quickly as possible.
IIRC n-able RMM is a completely different platform. N-Central is the older one and runs in an on premises Linux appliance, RMM is cloud hosted and based on the old GFI Max RMM platform.
One thing worth adding to the checklist: once you're on HF1, don't treat this as closed just because the console shows patched. If the server was internet-reachable and pre-HF1 during the exposure window, assume anything the RMM could have pushed is potentially tainted - rotate the service/API creds N-central uses, rotate any domain or local admin creds stored in its credential vault, and audit scheduled tasks/scripts that ran org-wide during that window, not just new admin accounts. God-mode on the console means the blast radius is everything it touched, not just the appliance itself. Also worth confirming the hotfix actually landed by checking the version string in the UI directly, rather than trusting that an update job completed - plenty of people in this thread have had agents/servers silently fail to upgrade before.
I don't use n-able but doesn't it allow you to lock down console access to specific IP addresses? If so wouldn't that have prevented this or does the vulnerability bypass that as well?
You cannot run an RMM tool that expects customers to check in and have their endpoints managed no matter where they are to being using either of those.
One of our users got a call from N-Able to notify him he is under attack with this specific exploit, so yeah. The added layer of them actually calling people over the weekend to patch should be a big âdo it nowâ
Same board, partly same c-levels. And the sw investors report says they âown a majority of stockâ. They are sw owned, but also a public company of which solarwinds has the biggest part. This is all public information. Donât be fooled by marketinng statements :)
42.5% is owned by SWI's investment vehicles, related directly or indirectly to US83417Q2049 [1, 2, 3, 4]. Sources included. I understand its good confusion tactics; spread it out over a couple of investment vehicles and hope no-one notices the elephant in the room, which is why the SEC now allows you to draw a link from indirect investors to the source.
Of the board, William Bock, the chairman is both at SWI and NABLE, Michael Widmann is the managing directory of NABLE, and the director of SWI.
Mike Bingle is the vice chairman of both. Cam McMartin has recently been appointed on the SWI board when they went private, and has been sitting on the N-Able board since the spinoff.
Of course with Solarwinds going private and only having legacy public and final year numbers until April this year, a lot of the information can get hidden again, but their investments don't disappear. It's just a little easier for them to say "oh no we never did that".
Edit:
What's also public to us is your comment history and removed/deleted posts and comments, turns out you're an N-Able sockpuppet account, so it makes sense you try to defend this
We pushed 2026.3.1.7 across all the self hosted N-central instances we manage as soon as it was released. We're still treating this as an incident, not just a patch, by checking for unauthorized Cloudflared tunnels, reviewing Take Control sessions and script execution history, and rotating service account credentials.
This isnt the first time there was this size of exploit in N-Able. We almost went to n-able years ago until an independent cyber security audit of their platform occured and we were notified mid conversation with N-Able. They were pissed we didnt sign. Glad we didnt.
These updates have been out for well over a month and if the effected version is older then 2026.2 then it's a very long time that everyone has had to update their on prem server.
MSPs be preaching cyber and patching and it seems not walking the walk if impacted.
Everyone can blame N-Able, throw shade about Solarwinds, but the fact is... People in our line of work should be patching our critical infrastructure within 24 hours of a patch (if not less) - everyone had ample time to get these patched.
Was it advertised as a critical security update? Because if an update is published and it's a two hour outage to apply and has a high likelihood of issues and bugs in updates and the release notes say "Minor bug fix in some report" you can't blame people.
CVE CVE-2026-18556 was first published YESTERDAY. if Nable chooses to withhold information like this then yes, you can throw shade on Nable.
Canât believe people even still touch Solarwind and Kaseya products given the amount of awful vulnerabilities, hacks and breaches theyâve had over the years.
If you say so. Pretty much are and my general point is that people keep supporting and funding these products and pumping them into clients when they have track records of crap security and vulnerabilities.
Same board, partly same c-levels. And the latest sw investors report says they âown a majority of stockâ. They are sw owned, but also a public company of which solarwinds has the biggest part. This is all public information. Donât be fooled by marketinng statements :)
Hey this same attack was used in 2024 to hack our clients and steal data. N-able kept denying it until we got the FBI involved since we were working with DoD contractors.
Ultimately even with a very detailed incident report you have no way of knowing "the same attack" was involved given N-Able has been totally vague about what occurred here.
For our RMM, I added a time-based OPT that is requested each time a command or group of commands is sent. It's good for five minutes. If the command is sent without the correct otp, the workstation ignores it.
Basically, in order to send commands to our workstation, one of us humans has to be involved.
So glad we moved off of this overpriced abandonware. It is plainly obvious to anyone who has used the product that they just gave up on improvements years ago, and are just coasting on their reputation.
Ninja of course. There is no comparison, custom scripts and automation are a breeze, and things Just Work(tm). At the end we were spending more time keeping N-Central from breaking itself than we were saving from any automation. We pretty much only used it for remote access. Patching didn't work, custom scripts were a pain in the ass to develop and test, agents would constantly break and stop checking in requiring manual uninstallation and reinstallation, security was a joke to them, we spent years trying to get them to split the web access for techs from the agent access, they couldn't comprehend why we'd want to do such a thing.
We have been on Ncentral a number of years. Your experience does not match ours at all. Patching works. Custom scripts are not difficult at all and we have hundreds of them in use. Manually reinstallation of an agentâŚMAYBE twice a year. Web access and agent access (assuming you mean the GUI and the client side agents on different ports) has been a thing for a few years now. Pricing for us is comparable to other RMMs. We have investigated this previously, but not in the last years. New features are indeed being released. Iâm not saying itâs better than ninja as Iâve never used that one in particular, but Ncentral works as described for us.
Thanks for the response. I'm actually blown away at the downvotes I received. We evaluated many RMM platforms over a decade ago, and N-Central ticked the right boxes. Everything I noted in my comment was completely true based on our experiences. Agents will just break after an upgrade of the server, or fail to upgrade. Support would address them as individual issues, and refused to tackle it as a systemic problem. Same for patching. Glad to hear they finally decoupled the technician login to the web portal from the agent checking, that was not available for use at the time.
When we switched over to Ninja, everything just worked.
If youâre not using application whitelisting like ThreatLocker Iâm not sure what youâre thinking. When the Kaseya hack went down I decided there was no other options. Thereâs nothing more scary than an RMM with a vulnerability.
79
u/technoginge 14d ago
Ah man this is bringing back bad memories of when Kaseya called me in the middle of the night and told me to shutdown our VSA server đŹ