SonicWall and MSP Remote-Management Tools Are Under Active Attack: A Patch-Now Checklist for Your IT Provider

Two actively exploited vulnerabilities — one in SonicWall firewalls, one in a platform MSPs use to remotely manage client systems — mean small businesses can be breached through their own hardware or through their IT provider's console, so here's exactly what to ask and confirm.

If your business runs a SonicWall firewall, or if you outsource IT to a managed service provider (MSP) who logs in remotely to keep your systems patched and backed up, you have two separate reasons to make a phone call this week. Both involve vulnerabilities that attackers are exploiting right now, not theoretical risks in a vendor bulletin nobody reads. Neither requires you to become a security expert. It requires you to ask specific questions and expect specific answers — dates, version numbers, confirmations — not reassurance.

Here is what's happening with each, and a checklist you can copy, paste, and send to whoever manages your network.

Problem 1: Your SonicWall firewall (CVE-2026-15409 and CVE-2026-15410)

SonicWall disclosed and patched two vulnerabilities on July 14, 2026 — but by the company's own timeline, attackers had already been exploiting them for roughly three weeks before the public disclosure. That means "patched now" and "safe now" are not automatically the same thing for a box that was sitting exposed to the internet during that window.

The threat actor most consistently named in connection with this vulnerability chain is INC, a ransomware-as-a-service operation that researchers at Rapid7 describe as one of the most active groups of its kind globally right now (though not every attack using these flaws has been definitively tied to INC specifically — other opportunistic attackers are almost certainly involved too). Separately, the security firm Huntress reported a fast-moving spree in which 30 SonicWall customers were compromised in under two days. This is not a slow-burn risk.

There's also relevant history here: SonicWall previously disclosed an incident in which a state-sponsored group stole firewall configuration files from every SonicWall customer using its cloud backup feature. A stolen configuration file can contain local account credentials and VPN settings. If your firewall's configuration was ever backed up to SonicWall's cloud service before that incident was contained, patching the current flaws doesn't undo whatever was already exposed — credentials from that config may still need rotating.

Checklist to send your IT provider or MSP:

"What SonicWall model and firmware version are we currently running, and does that version remediate CVE-2026-15409 and CVE-2026-15410?" (Ask them to confirm against SonicWall's own advisory — don't accept "we're on the latest version" without a version number.)
"What date did we apply the patch?" If it was after July 14, 2026, ask them to check logs covering the prior few weeks for signs of unauthorized access — unexpected admin logins, new local accounts, or SSLVPN sessions from unfamiliar IP addresses.
"Was our SSLVPN or remote-access portal exposed to the internet during that window?" If yes, ask for a forced password reset for every account that authenticates through it, not just a patch.
"Was our firewall configuration ever backed up to SonicWall's cloud service, and if so, have the credentials in that config file been rotated since?"
"Do you have multi-factor authentication enabled on all remote-access accounts through the firewall?" If not, ask them to turn it on this week.

Problem 2: Your MSP's remote-management tool (CVE-2026-18577 in N-able N-central)

This one is different because it isn't your equipment — it's a tool your IT provider might use to manage dozens or hundreds of client businesses, including possibly yours, from one central console. N-able N-central is one such platform, and CISA (the U.S. Cybersecurity and Infrastructure Security Agency) added a vulnerability in it — CVE-2026-18577, rated 8.2 out of 10 in severity — to its Known Exploited Vulnerabilities catalog after confirming active exploitation since July 31, 2026. The flaw reportedly allows an attacker to gain full administrative access to the N-central console itself.

That matters because of what an attacker can do from there. Huntress reported that successful attacks pivoted from the compromised console into the endpoints being managed through it — meaning a breach of the MSP's tool can become a breach of your systems without an attacker ever targeting you directly. Huntress also found attackers creating Cloudflare tunnels on compromised systems, a technique that gives them a persistent, encrypted way back in that can look like ordinary web traffic to a firewall.

You don't need to know if your specific provider uses N-central. You need to ask, and ask more broadly than just that one product name.

Checklist to send your IT provider or MSP:

"Do you use N-able N-central, or any other N-able product, to manage our systems?" If yes: "Is it patched against CVE-2026-18577, and as of what date?"
"Have you audited admin account activity and access logs on your management console since July 31, 2026, for anything you can't explain?"
"Have you checked our systems specifically for unexpected outbound connections — particularly Cloudflare tunnel processes (sometimes shown as 'cloudflared') or tunnel domains you didn't set up?"
"Have any new local admin accounts, scheduled tasks, or remote-management policies been pushed to our systems that you can't attribute to your own team?"
"If you don't use N-central, what remote-management tool do you use instead, and has it had any vulnerabilities added to CISA's Known Exploited Vulnerabilities catalog recently?"

What to do with the answers

A good IT provider will answer these with dates and specifics, often within a day, because they should already know this information or be able to pull it from logs quickly. A vague answer — "we're on top of it," "our systems are secure," no dates offered — is itself useful information: it tells you this conversation needs to happen again, in writing, with a deadline attached.

If you manage your own SonicWall without an MSP, the checklist above still applies to you directly — log into the management console yourself, check the firmware version, and check SonicWall's advisory page for the version that remediates both CVEs.

Neither of these flaws requires you to rip out a vendor or fire a provider. They require confirmation that the specific gap has been closed and that nothing walked through it while it was open. Ask the questions, get the dates, and put a reminder on your calendar to ask again the next time a vendor discloses something "actively exploited." It will happen again.