The MSP Security Gap
The app your client approved
The scenario:
An email lands: a shared proposal, view it in the browser. The link opens a genuine Microsoft sign-in page, real domain, real padlock. Then a consent screen: “PDF Viewer Pro would like to read your mail and files.”
Your client’s project manager clicks accept, the way they have accepted a hundred cookie banners. The document never opens.
How it unfolds:
Nothing was hacked. The attacker registered an innocent-looking app and asked for permission, and the victim granted it: read mail, read files, send as user.
No password was stolen, so no password reset helps. MFA was satisfied, so MFA reports nothing. The app quietly syncs the mailbox from the cloud, month after month. Invoice fraud, data theft, and the next attack on someone in the address book all start from this one polite consent.
Most tenants never look at their enterprise app list. The access outlives password changes, device replacements, even the employee leaving, until someone audits consents.
That is the quiet part. Consent-grant attacks survive every step a password-focused playbook contains. The account was never broken into. It invited a tenant application in, and tenant applications appear on no leaver checklist and no password rotation schedule.
The warning signs:
A document link ending in a permission screen rather than a document.
App names imitating utilities: viewer, scanner, sync, backup.
Consent requests wanting mail and file access to display one document.
Unfamiliar apps in the tenant’s enterprise applications list with broad grants.
Stop it:
Turn off user consent in the tenant. Apps get approved by an admin or not at all. This single setting kills the attack.
Audit existing consents now: list every app with mail or file permissions and remove what nobody recognizes.
Teach the tell: a document that demands account-wide permissions is not a document. \
-
P.S. A password reset feels like the fix and does nothing here, because the attacker holds a grant, not a credential. The signal is the consent event and the app inventory. Tenants get breached politely now. Someone needs to be reading the consent log.
Patch first this week:
This week’s KEV additions, ranked by what MSPs run across client fleets. Verified against NVD, CISA, and vendor advisories.
• N-able N-central CVE-2026-18577 (8.1) and CVE-2026-18556 (8.2).
Unauthenticated authentication bypass leading to full administrative takeover of the N-central server. Read this one first, because it is your platform, not a client’s. N-able’s Adlumin MDR detected a threat actor exploiting it as a zero-day on July 31. N-able fixed the first path in 2026.2, then found an alternative route the fix did not block, and issued CVE-2026-18577 covering every build before 2026.3.1.7.
Who runs it: you, if N-central is your RMM. On-premises and hosted installs are both affected. After gaining admin, the attacker used the built-in Take Control feature to connect to systems inside the managed environment and registered a new service for a Cloudflare tunnel, keeping access after the N-central server was locked down.
Fix: 2026.3.1.7, released August 2. KEV August 3 and August 4. Federal deadlines August 6 and August 7, both passed. The upgrade is not the end of the job. Hunt for the 10 attacker IP addresses in N-able’s advisory: 173.249.252.176, 173.249.252.200, 185.156.46.150, 23.234.94.43, 37.153.90.88, 37.19.210.32, 68.235.46.214, 68.235.46.235, 87.249.138.34, 92.118.112.181. Review admin accounts and Take Control session history, and look for unexplained Cloudflare tunnel services on managed endpoints. N-able published a detection service template for N-central. A clean result is not proof you were missed.
• Apache Tomcat CVE-2026-34486 (7.5).
A regression in the fix for CVE-2026-29146 allows the EncryptInterceptor to be bypassed, so a clustered Tomcat keeps processing replication messages after decryption fails. Where a Java deserialization gadget sits on the classpath, reaching the Tribes port turns junk traffic into remote code execution. Public proof-of-concept code is available.
Who runs it: clients with clustered Java line-of-business applications, common in finance, healthcare, and logistics, and often inherited rather than built.
Affected: 9.0.0.M1 through 9.0.116, 10.1.0-M1 through 10.1.53, and 11.0.0-M1 through 11.0.20.
Fix: 9.0.117, 10.1.54, or 11.0.21. KEV August 4. Federal deadline August 7, passed. Where patching slips past this week, restrict TCP 4000, the default Tribes receiver port, so only cluster members reach it.
• IBM Langflow CVE-2026-9198 (9.8).
Two unauthenticated endpoints chained together. The auto-login endpoint hands a superuser token to any caller on the network, and the code validation endpoint runs attacker-supplied Python. The result is remote code execution on a default install with no credentials.
Who runs it: skip this one unless a client or your own team stood up Langflow to build AI workflows. Shadow AI tooling is where it hides, so search for it before you rule it out.
Affected: 1.0.0 through 1.10.0. Fix: 1.10.1. KEV August 4. Federal deadline August 7, passed.
• Arista VeloCloud Orchestrator On-Prem CVE-2026-16812 (10.0).
Carried forward from last week and still open on most fleets. OS command injection reaching privileged internal functions and the orchestrator host. Arista confirms active exploitation.
Who runs it: any client with SD-WAN managed from an on-premises VeloCloud Orchestrator. Hosted and Dedicated VCO were patched before disclosure.
Affected: 5.2.0 to 5.2.3.13, 6.1.0 to 6.1.3.3, 6.4.0 to 6.4.2.3, and 7.0.0.
Fix: 5.2.3.14, 6.1.3.4, 6.4.2.4, or 7.0.0.1. KEV July 27. A 10.0 with confirmed exploitation does not age out of the list. If it is still open, it goes to the top of today.