MSP Threat Briefing: November 4, 2026

Two items today put MSPs directly in the path. Since November 1, an attacker has been using stolen app credentials to sign in to Entra ID, and one compromised MSP app opens every client tenant it manages. Separately, the cPGuard server security tool pushed a backdoor through its own update channel on November 2. CISA has also added the WordPress core upgrade flaw to its exploited list, with a federal deadline of November 6.

1. Search Entra sign-in logs in your own tenant and every client tenant for 199.19.77.84. Review the secrets and permissions on your multi-tenant and GDAP apps.
2. Update every cPGuard server to 5.88.25 or later. If it installed 5.88.12 through 5.88.19, rotate root, database and SSH credentials.
3. Confirm every WordPress site is on 7.1.4 or its branch's security release.
4. Update Synology NAS units to a current DSM build and take DSM management off the internet.

1. Stolen app credentials are reaching client tenants through MSP apps

Todyl reported on November 3 that an attacker is signing in to Entra ID as applications, not as users. The activity began on November 1 at 08:45 UTC. About 45 app registrations at roughly 18 organizations were targeted. More than 33 authenticated successfully.

Through those apps the attacker reached 27 organizations, including MSPs' downstream clients. It searched about 25 tenants, downloaded 81 files and accessed around 2,279 mailbox items. Todyl says no Microsoft vulnerability is involved. It found no sign that a vendor platform was breached. Credentials for security tool integrations were among those abused, including Todyl's own integration apps in two MSP tenants. How the credentials were stolen is unknown.

The pattern is consistent. The attacker signs in with a stolen app secret, an Azure DevOps federated identity or a replayed Azure DevOps session token. It requests Azure Resource Manager and Key Vault tokens, then Graph and Storage. Other apps in the tenant then start authenticating within minutes. It runs wildcard Graph searches and pulls SharePoint files at about one per second, favoring names tied to passwords, keys, VPN profiles and backups. It then uses MSP multi-tenant apps, GDAP apps and Partner Center tokens to reach client tenants. Todyl assesses this as unrelated to the October ConnectWise Cloud Backup compromise. Its figures cover only organizations that send logs to Todyl.

Who is exposed. Every MSP with app registrations that hold client secrets, and especially multi-tenant apps used for automation, reporting or security integrations. Clients with Azure DevOps pipelines and Key Vaults are exposed too. User-focused Conditional Access does not cover app-only sign-ins.

What to do.

• Run this query in each tenant that sends logs to Sentinel or Log Analytics. Todyl published it: union AADServicePrincipalSignInLogs, AADNonInteractiveUserSignInLogs | where IPAddress == "199.19.77.84". Search Azure DevOps audit logs for the same address.
• Count failures, not just successes. AADSTS7000215 (invalid secret) or AADSTS7000222 (expired secret) from an unknown address means someone holds a credential for that app.
• Look for one address signing in as service principals in several unrelated tenants within 24 hours. Look for an ARM token, then Key Vault, then new apps authenticating minutes later.
• Look for app-only SharePoint downloads from non-Microsoft addresses at machine speed, often after a wildcard search.
• If you get a hit, rotate secrets, certificates and federated credentials on the app, and disable the service principal if needed. Revoke sessions, Azure DevOps tokens and SSH keys for affected users. Rotate every secret in Key Vaults the app could read and in documents it downloaded.
• Check Partner Center, GDAP relationships and client tenants. Notify clients as your agreements require.
• Longer term, replace client secrets with managed identities or federation, keep GDAP roles least-privilege and time-bound, and remove apps nobody uses.

Todyl recommends blocking the operator's single address, not the whole hosting network. Indicators published by Todyl:

Todyl lists 20.20.34.96, 20.20.34.160 and 20.231.130.224 as Microsoft service addresses. Do not block them.

2. cPGuard update channel shipped a backdoor to Linux web servers

cPGuard is a malware scanner and firewall for Linux web servers running cPanel, DirectAdmin or Plesk. Its maker, OpsShield, says an attacker used compromised credentials to reach its update distribution system on November 2 at 02:06 UTC. cPGuard versions 5.88.12 through 5.88.19 carried a malicious script. OpsShield says it detected the attack within 12 hours.

The script collected /etc/shadow and /etc/passwd, the root MySQL or MariaDB configuration, root's shell history, and root's SSH authorization and known-hosts files. It left a backdoor shell. OpsShield estimates the attacker retrieved 32 collected files and says this is not the total of affected servers. OpsShield told BleepingComputer that 2,946 servers were affected and that its billing database was also copied.

Who is exposed. Clients and MSPs that run their own cPanel, DirectAdmin or Plesk servers with cPGuard, including VPS and dedicated servers where a host bundled it. Root password hashes, database credentials and SSH trust reach well beyond one box.

What to do.

• Run cpgcli update --start on every cPGuard server, then cpgcli --version. Confirm 5.88.25 or later, which removes the known backdoor and staged files.
• Check whether an affected build was installed: grep 'Successfully updated' /opt/cpguard/logs/install_log. Any entry from 5.88.12 through 5.88.19 counts.
• If so, treat the server as compromised. Reset root and other local passwords from a trusted recovery environment. Change those passwords anywhere they were reused.
• Rotate database passwords, cloud keys and tokens, and any secret that appears in root's shell history.
• Replace SSH keys under /root/.ssh and remove the old public keys from every system that trusts them.
• OpsShield is shipping an update that removes its own support-access keys from cPGuard servers.

Indicators published by OpsShield. OpsShield notes that their absence after cleanup does not prove the script never ran:

3. Update: CISA lists the WordPress core upgrade flaw as exploited

The November 1 briefing covered the race condition fixed in WordPress 7.1.4. It now has an ID, CVE-2026-119977. CISA added it to its exploited catalog on November 3, citing evidence of active exploitation. Federal agencies must fix it by November 6. Wordfence scores it 8.1.

During a full-package core update, WordPress staged files in a predictable, web-reachable folder. An unauthenticated attacker who reached the staged installer in that window could run code. Wordfence recorded more than 18,500 requests to staged setup-config.php paths in the first 21 hours, as reported by The Hacker News. It blocked 12,632 attempts in the 24 hours before that report. Neither CISA nor Wordfence has published details of a successful compromise.

What to do.

• Confirm every site is on 7.1.4 or its branch's security release. The November 1 briefing lists the backports.
• Find sites where auto-updates are off or versions are pinned. Those are the ones still exposed.
• Search web server logs for requests to PHP files under /wp-content/upgrade/. Check for admin accounts, plugins or PHP files nobody created.

4. Ransomware is hitting Synology NAS units on old DSM builds

Synology warned on October 29 that attackers are exploiting a flaw patched in December 2024 on outdated DSM versions. The goal is to encrypt data and demand a ransom. Synology did not name the flaw. A spokesperson pointed BleepingComputer to advisory Synology-SA-24:20. Its most severe flaw is CVE-2024-10441, a 9.8 remote code execution bug.

Victims report encrypted files with a .L0CK3D extension and a ransom note named read-me3.txt, per BleepingComputer. The ransomware is known as C3RB3R or Cerber. Shadowserver tracks more than 380,000 internet-exposed Synology NAS devices.

Who is exposed. Small offices that use a Synology NAS as a file server or backup target, especially units someone set up years ago with the DSM web interface open to the internet. A NAS that holds backups is a double loss when encrypted.

What to do.

• Update DSM. SA-24:20 lists fixed builds: 7.2.2-72806-1, 7.2.1-69057-6, 7.2-64570-4, 7.1.1-42962-7 and 6.2.4-25556-8, or later.
• Turn on automatic DSM updates, as Synology recommends.
• Block the DSM management interface from the internet. Use a VPN for remote administration.
• Keep at least one backup copy off the NAS, offline or immutable.

Quick hits

Barracuda appliances. Barracuda published fixes on November 2 for two flaws. CVE-2026-116606, rated 9.3, is an authorization bypass in the Email Security Gateway. CVE-2026-111560, rated 8.6, is a command injection that runs as root on ESG, Load Balancer ADC, Message Archiver, WAF, WAF Control Center and Web Security Gateway. Barracuda says both need administrative interface access, and it does not say they are exploited. Confirm the patches applied, since some appliances have automatic patching turned off. Restrict admin interfaces to trusted internal networks.

Sources

• Todyl: stolen app credentials, real access
• OpsShield: cPGuard update channel compromise
• BleepingComputer: hackers hijack cPGuard autoupdate to deploy backdoor
• CISA: CISA adds one known exploited vulnerability to catalog, November 3, 2026
• The Hacker News: CISA confirms hackers exploiting WordPress core flaw
• Synology: update DSM following ransomware attacks
• Synology-SA-24:20
• BleepingComputer: Synology warns of C3RB3R ransomware attacks
• Barracuda: pre-authentication authorization bypass and command injection