In light of the critical vulnerabilities (CVE-2026-18556 and CVE-2026-18577) affecting N-central, we wanted to quickly post information about security options for protecting it. In this post, we’ll review the benefits and common issues associated with using a WAF for N-central.
Note: If your N-Central isn’t patched to version 2026.3.1.10 or above, stop everything and patch immediately.
Background: Protecting MSP tools in a zero-day world
We’re currently watching a classic example of an RMM zero-day. A bad actor discovered a vulnerability, and the vendor learned about it after exploitation had begun. They rushed to get a patch into production (bravo, N-able), but the initial patch was later found to be only a partial fix, and multiple additional patches have been released for full resolution. We call this phenomenon (and the related chaos) the “zero-day world” here at Automation Theory.
It’s becoming increasingly clear that leaving MSP tools behind a regular firewall connected to the Internet is a bad practice. That allows IoT scanners like Shodan to enumerate the application’s details – and reconnaissance is the first step in an attack. A good defense requires more than preventing enumeration – but as the old quote goes:
The wise warrior avoids the battle.
― Sun Tzu, The Art of War
The other thing to note is that the attacks target the applications themselves. It doesn’t matter how good your authentication is or how stringent your conditional access policies are if you’re trying to defend against an authentication bypass. Your other security layers need to be able to compensate for a failure in one layer – and for years, the guidance for MSPs has just been to harden authentication. You need more in the zero-day world.
An aside: the problems with CloudFlare “WAF” for N-central
N-central MSPs popularized using Cloudflare to protect RMMs. It’s better than nothing, but the free version isn’t a real WAF (our team spent months tuning our offering for N-central — so anything that doesn’t require such configuration is likely not in the same category). We benchmarked it, and the results were disappointing:
We wrote a blog about the details, but the free WAF is only looking for a handful of things that are “high severity” threats — and no MSP tool zero-day appears on that list.
WAFs for the win: a reverse proxy and WAF strategy for N-central
A reverse proxy sits between clients and web servers, facilitating many functions, from logging to load balancing. However, they can provide several security functions, including custom access controls, GeoIP restrictions, communication hardening, and deep inspection with a WAF.
At the reverse proxy layer, we can implement access controls that:
- Create GeoIP restrictions
- IP restrict specific URLs (customizable)
- Block scanning by IP, preventing IoT enumeration
- Require additional authentication methods (like URL parameters or certificates)
- Enforce company security policies, such as requiring specific browsers or clients
- Allow granular access to APIs based on identification headers
Those controls will prevent enumeration, reduce the attack surface, and counter many common attack tactics, techniques, and procedures (TTPs). This security strategy draws on the MITRE ATT&CK® framework and is far more robust than the current industry “MFA, patch, and pray” approach.
A WAF adds deep payload inspection to these controls. It looks for things like code injection, XSS, file inclusion attacks, and malformed or known-bad requests. This includes:
- Inspecting requests for embedded code
- Validating protocols and request types
- Blocking known bots, scanners, and attack frameworks
While the feature list doesn’t seem flashy, there are only so many valid syntaxes for various attacks and only so many ways to try and obfuscate them. A WAF scanning for the commonly known bad TTPs makes using the mass-produced hacking tools hard, and it’s unlikely that you would be faced with an attacker who would custom-develop an attack module for the small number of instances that don’t work with the existing ones.
This means that (for a typical MSP) if a targeted attacker were targeting your MSP, they would need to:
- Create infrastructure to launch an attack from inside the country
- Determine the FQDN of your application (since IP-based access is blocked)
- Maneuver around your custom access controls
- Which might include IP lists, browser requirements, or client certificates
- Launch an attack via tools that the WAF is unaware of
- Encode a malicious payload in a way the WAF can’t detect
While not impossible, that is a very tall order.
Implementing a WAF for N-central
N-central uses an agent communication technology that is based on instant messaging protocols. As a result, the WAF configuration must be adjusted for this traffic pattern. However, this configuration doesn’t impact the overall architecture. The network architecture should look something like this:
If this is of interest to your MSP, you can find product information and trial registration details here.