The MSP Security Gap
The meeting invite had the right logo.
The scenario:
The calendar invite arrived the way hundreds of others had that quarter. It had the company logo, familiar video-call branding, and a meeting title referencing a real project the recipient was already working on.
A finance manager at a regional healthcare group clicked join five minutes before the scheduled time, the way anyone joins a meeting they are already expecting.
How it unfolds:
The invite had not come from the video platform at all. It came from a domain one character off from the real one, sent from a compromised vendor contact.
The attacker had been quietly reading that mailbox for two weeks, learning exactly which meetings were real and which project names would pass without suspicion.
The "join" link led to a convincing login page that harvested credentials. The platform's login also served as single sign-on for several other internal tools, so that one page handed the attacker a working set of keys within minutes.
The warning signs:
The meeting link's domain was subtly different from the platform's real domain, one letter swapped or added
The invite referenced a real project but arrived from a sender who was not normally involved in scheduling for it
The login page asked for credentials again, even though the recipient believed they were already signed in on that device
Stop it:
Require multi-factor authentication on every login tied to single sign-on, not only the primary email account, so a harvested password alone is not enough
Train staff to check the actual sending domain on any calendar invite before joining, not only the display name, especially for anything referencing an active project
Monitor for new login attempts from unfamiliar locations immediately after any credential harvesting page is reported, since the window between theft and use is often minutes
-
P.S. Single sign-on is convenient because one login unlocks everything. That is also why a single stolen login is worth more than ever. Detection that watches identity and login behavior across every connected system, not only the inbox where the phishing link arrived, catches this kind of chain before it reaches the second or third tool.
Patch first this week:
Four vulnerabilities went from "patch eventually" to "patch today." Two of them sit inside the tools MSPs use to run their clients. Here is what to check across your client base.
1. N-able N-central: pre-authentication remote code execution in the RMM itself
Product: N-able N-central, the on-premises remote monitoring and management platform.
Who runs it: you might. Any MSP hosting its own N-central server, and any client with an N-central instance inherited from a previous provider.
The action: upgrade to N-central 2026.3.1.14 or later now. Until you do, take the management interface off the open internet and restrict it to trusted management networks.
The urgency: this is a CVSS 10.0 flaw that needs no credentials, no user interaction, and no special access. An attacker who gets in owns the RMM, and through it every endpoint the RMM manages. N-able published the advisory on September 5. CISA added it to the Known Exploited Vulnerabilities catalog on September 8 with a federal deadline of September 11, which has already passed by the time you read this. If your N-central is still on an older build, treat it as a potential compromise, not a pending patch.
2. SonicWall SMA1000: two flaws that chain to unauthenticated remote code execution
Product: SonicWall SMA1000 series secure remote access appliances, models 6210, 7210, and the 8200v virtual appliance.
Who runs it: mid-size clients using SonicWall for remote access, especially those with hybrid workforces, and anyone who bought a SonicWall remote access appliance before 2024 and never revisited it.
The action: apply platform hotfix 12.4.3-03526 or 12.5.0-02952 or later from mysonicwall.com. Then ask SonicWall support to check the appliance for indicators of compromise. If anything is found, re-image or redeploy the appliance, reset every user and admin password, and reset TOTP tokens.
The urgency: the first flaw (CVE-2026-83548) is a pre-authentication server-side request forgery rated CVSS 10.0. The second (CVE-2026-83549) is an OS command injection in the management console. Chained together they give an unauthenticated attacker full control of the appliance. SonicWall confirmed active exploitation in its September 1 advisory. CISA added both to the KEV catalog on September 2 with a federal deadline of September 5. That deadline is already gone. Note that SSL-VPN on SonicWall firewalls and the SMA 100 series are not affected.
3. Microsoft Windows: two zero-days in the September Patch Tuesday
Product: Windows 10, Windows 11, and Windows Server 2012 through Server 2025.
Who runs it: every client.
The action: deploy the September 2026 cumulative updates across all Windows endpoints and servers. Confirm the RMM reports the update installed, not just approved.
The urgency: Microsoft shipped fixes for two elevation of privilege flaws on September 8 that were already being exploited. CVE-2026-85880 is a heap overflow in Windows ALPC and affects Windows 10 and Server 2012 through 2022. CVE-2026-81963 is a link-following bug in the Windows Update stack and affects Windows 11 and Server 2025. Both are rated CVSS 7.8. Neither gets an attacker in on its own, but each turns a foothold from a phishing email or a compromised app into SYSTEM. CISA added both to the KEV catalog on September 8 with a federal deadline of September 22, eight days after this email lands.
4. Google Chrome: V8 type confusion exploited in the wild
Product: Google Chrome, and any Chromium-based browser that ships the same V8 engine (Edge, Brave, and others).
Who runs it: every client, on every desktop.
The action: push Chrome 152.0.7977.82 or later and force a browser restart. Check that Chromium-based browsers have picked up their matching update.
The urgency: CVE-2026-85046 lets a crafted web page run code inside the browser sandbox. Google shipped the fix in the September 1 stable channel update. CISA added it to the KEV catalog on September 4 with a federal deadline of September 18, four days after this email lands. Browser updates that wait for a user to relaunch are the ones still unpatched a month later.