Another SonicWall vulnerability, cPanel WHM had a root-level authentication bypass since February, ScreenConnect is now a confirmed Kimsuky target, and AI tool connections are a documented attack surface
CVE-2026-41940 in cPanel and WHM was exploited as a zero-day since at least February 23; Shadowserver is tracking 44,000 active scanning IPs against 650,000 exposed instances and the CISA deadline has passed. ConnectWise ScreenConnect CVE-2024-1708 was KEV-listed April 28 with Storm-1175 and North Korean group Kimsuky both confirmed exploiting the same flaw. SonicWall's entire Gen6 through Gen8 firewall lineup needs firmware updates after a three-CVE advisory dropped April 29 with an unauthenticated management access flaw leading the set. Quest KACE SMA CVE-2025-32975 exploitation chains through the appliance to backup infrastructure and domain controllers; the KACE KEV deadline was May 4. And two incidents this month, the Bitwarden CLI supply chain worm and the Vercel breach, independently document AI tool OAuth grants and MCP server configurations as active targets worth auditing this quarter.
Patch today
Items with immediate action required.
-
CVE-2026-41940 in cPanel and WHM, CVSS 9.8, exploited as a zero-day since February, KEV deadline already passed, 44,000 IPs actively scanning 650,000 exposed instances
Update cPanel and WHM to 11.136.0.5 or WP Squared to 136.1.7 immediately. If you manage client hosting on self-hosted cPanel servers or resell hosting through cPanel-based providers, verify patch status with the provider today. The federal deadline was May 3. The exploit is trivially executable and the proof-of-concept has been public since April 29.
Why it matters: CVE-2026-41940 is a CRLF injection vulnerability in the cPanel service daemon (cpsrvd) that allows an unauthenticated attacker to bypass authentication entirely and obtain a fully authenticated root session in WHM. The mechanic is unglamorous and effective: before authentication completes, cpsrvd writes a new session file to disk. An attacker sends a malformed Basic Authorization header containing raw carriage-return and line-feed bytes, which the daemon writes into the session file without sanitization. The resulting file contains injected properties including user=root, hasroot=1, and tfa_verified=1. When cpsrvd loads the session, those properties are trusted, and the attacker holds a root-level WHM session without ever supplying a valid password or passing a two-factor authentication prompt. watchTowr published a full technical analysis and working proof-of-concept on April 29; the exploit chain is a small number of HTTP requests and requires no special tooling. cPanel disclosed the vulnerability on April 28 and patched the same day, but KnownHost confirmed in-the-wild exploitation had been ongoing since at least February 23, making this a zero-day with a roughly two-month exploitation window before the patch arrived. CISA KEV-listed CVE-2026-41940 with a federal remediation deadline of May 3, which has passed. Shadowserver is tracking approximately 44,000 unique IPs actively scanning or running exploitation attempts against honeypots, against a target population of roughly 650,000 internet-exposed cPanel and WHM instances. The SMB and MSP relevance is direct: cPanel controls the majority of the shared hosting control panel market, and the WHM administrative interface is how hosting providers manage the server-level configuration, user accounts, DNS zones, and SSL certificates for every site on the host. Compromise of WHM on a shared hosting server is effectively a compromise of every site that server hosts.
What to do: If you run self-hosted cPanel and WHM servers, apply the emergency update immediately. Run /scripts/upcp --force at the command line to force the update and verify the resulting build version is 11.136.0.5 or later. Restart cpsrvd after the update. For WP Squared deployments, the fixed version is 136.1.7. If you cannot patch immediately, block inbound traffic on cPanel and WHM management ports (TCP 2082, 2083, 2086, 2087, 2095, and 2096) at the perimeter firewall to all source IPs except explicitly approved administrative ranges; this closes the attack surface for the duration of the patching window. After patching, treat any server that had management ports exposed to the internet between February 23 and April 28 as potentially compromised. The forensic check is specific: inspect /var/cpanel/sessions/raw/ for session files whose pass= value contains embedded CR or LF bytes, or where pass= is immediately followed by another key=value pair on the next line. Check the WHM user account list for any accounts created since February 23 that your team cannot account for, and audit /etc/authorized_keys and root's crontab for unauthorized entries. cPanel published a vendor-supplied detection script; run it on every affected server before declaring the host clean. If you resell hosting or manage client sites on cPanel-based hosting infrastructure, contact your hosting provider today and confirm the patch has been applied to the underlying server. Do not assume the provider has already acted.
-
CVE-2024-1708 in ConnectWise ScreenConnect KEV-listed April 28, May 12 deadline; Storm-1175 and Kimsuky both confirmed actively exploiting the flaw
Confirm every self-hosted ScreenConnect instance is on version 23.9.8 or later. This was already in the dispatch-002 Storm-1175 action block, but the threat actor picture has expanded materially since then and the KEV listing makes the May 12 deadline binding for federal contexts.
Why it matters: CVE-2024-1708 is a path traversal vulnerability in ConnectWise ScreenConnect (versions 23.9.7 and earlier) that in practice chains with the authentication bypass CVE-2024-1709 to produce remote code execution on the ScreenConnect host. ConnectWise patched both vulnerabilities in February 2024 and CISA added CVE-2024-1709 to the KEV catalog at that time. The April 28 addition of CVE-2024-1708 to the KEV catalog, with a federal deadline of May 12, reflects new exploitation reporting that raises the urgency considerably: Microsoft has confirmed that Storm-1175, the China-based Medusa ransomware affiliate profiled in dispatch-002, is actively chaining CVE-2024-1708 and CVE-2024-1709 in its current campaign targeting MSP infrastructure. CISA separately confirmed that Kimsuky, a North Korean state-sponsored threat group primarily known for long-term espionage and credential harvesting operations against government, defense, and research organizations, is also actively exploiting CVE-2024-1708. Two nation-state threat actors from different countries with different operational objectives are using the same vulnerability on the same platform. The practical concern for the MSP audience is that ScreenConnect on version 23.9.7 or earlier is accessible from the internet by design, making it trivially discoverable. The 2024 patch has been available for over a year. Any instance still on a vulnerable version at this point has had extended exposure, and the Kimsuky exploitation reporting suggests the targeting has expanded beyond the ransomware-focused Storm-1175 campaign.
What to do: Pull your ScreenConnect instance version from the administration panel under Administration > About. If any self-hosted instance is on 23.9.7 or earlier, apply the update to 23.9.8 immediately; the update is available through ConnectWise's standard update mechanism and does not require a service rebuild. Cloud-hosted instances on screenconnect.com were patched by ConnectWise in 2024 and require no action. After confirming the version, pull the ScreenConnect access logs and review for anomalous activity since January 1: look for unexpected administrative account creation, new technician accounts added outside your normal provisioning process, sessions originating from IP ranges inconsistent with your client base, and any commands or file operations executed through the ScreenConnect remote-access interface that your team did not initiate. The forensic question for Kimsuky-style intrusions is different from ransomware precursor activity: look for low-and-slow credential enumeration, unusual data access patterns, and persistent access artifacts like new SSH authorized keys or scheduled tasks on endpoints that received remote sessions. If you run Microsoft Sentinel or Defender XDR, search for the Storm-1175 and Kimsuky indicator sets Microsoft published in the April 6 and April 28 advisories respectively.
This week
Worth investigating this week but not today.
-
SNWLID-2026-0004: SonicWall Gen6, Gen7, and Gen8 firewalls affected by unauthenticated management access, path traversal, and a denial-of-service crash; patches available, no confirmed exploitation yet
Apply the SonicOS firmware update to every SonicWall appliance in your environment this week. If you cannot patch immediately, disable HTTP/HTTPS management on all interfaces and restrict management to SSH. Do not attempt to downgrade a Gen6 appliance from 6.5.5.2-28n; read the advisory note first.
Why it matters: SonicWall published SNWLID-2026-0004 on April 29, disclosing three vulnerabilities in SonicOS affecting every current hardware generation: Gen6 (SOHO, TZ series, NSA series), Gen7 (TZ270 through TZ670, NSa 2700 through 6700, NSsp series), Gen8, and NSv virtual appliances on ESX, KVM, Hyper-V, AWS, and Azure. The three CVEs cover distinct attack surfaces. CVE-2026-0204 (CVSS 8.0) is the one that warrants this-week prioritization: an improper access control flaw in SonicOS's authentication mechanism that allows an attacker on an adjacent network segment to reach management interface functions without credentials under specific conditions. CVE-2026-0205 (CVSS 6.8) is a post-authentication path traversal that allows an authenticated attacker to interact with restricted internal services and configuration files. CVE-2026-0206 (CVSS 4.9) is a post-authentication stack buffer overflow in the SSL-VPN component that causes a full firewall crash when triggered. No public exploits are confirmed and no KEV listing exists as of publication, which is the reason this item sits in this-week rather than patch-today. SonicWall firewalls are the most common SMB perimeter device in the installed base the dispatch serves. An unauthenticated management access flaw with CVSS 8.0 and no exploitation confirmation today does not mean no exploitation next week, particularly after CrowdStrike's public disclosure of the vulnerability details on April 29.
What to do: Identify every SonicWall appliance in your environment and its current SonicOS firmware version. For Gen6 hardware, the fixed version is 6.5.5.2-28n or later. For Gen7 hardware, verify against the specific platform list in SNWLID-2026-0004; the advisory lists version 7.0.1-5169 and 7.3.1-7013 as the affected baselines, with corresponding fixed releases available through MySonicWall. The firmware update process for most SonicWall hardware is a managed reboot and should be scheduled during a maintenance window with a tested configuration backup in hand before you begin. One specific operational note that SonicWall calls out explicitly in the advisory: downgrading a Gen6 appliance from 6.5.5.2-28n to any prior firmware version is not supported. Attempting it will delete all LDAP user accounts and reset all MFA configurations. If you take that firmware and discover a reason to roll back, you will be rebuilding your authentication configuration from scratch. Take the backup first. If you cannot apply the firmware update this week, SonicWall's interim mitigation is explicit: disable HTTP and HTTPS management access on all interfaces in System > Administration, and restrict management to SSH only. This closes the network attack path for CVE-2026-0204. Verify the change is applied on each interface under Network > Interfaces, confirming that HTTPS management is unchecked on any interface that is not exclusively management-VLAN-restricted. After patching, audit the SonicWall administrative user list and confirm no accounts were added outside your change management process.
-
CVE-2025-32975 in Quest KACE Systems Management Appliance, CVSS 10.0, authentication bypass KEV-listed April 20; confirmed exploitation pivots to backup infrastructure and domain controllers
Patch KACE SMA to version 12.1 or later and remove it from any internet-facing network segment. The post-exploitation trail, specifically the pivot to Veeam and Veritas backup servers and domain controllers, is the part that should get your attention.
Why it matters: CVE-2025-32975 is an authentication bypass in the single sign-on mechanism of Quest KACE Systems Management Appliance that allows an unauthenticated attacker to impersonate any user on the platform, including administrators, without valid credentials. KACE SMA is an on-premises endpoint management platform used for asset inventory, software deployment, patch management, and scripted automation across managed endpoints. That description understates what it means in practice: KACE SMA holds trusted administrative credentials for the systems it manages, runs scripts with elevated privileges on those systems, and has network-level access to most of the infrastructure it was deployed to control. Arctic Wolf confirmed exploitation beginning the week of March 9, 2026, against unpatched SMA instances exposed to the internet. The observed attack chain is specific and worth reading in full: initial access via CVE-2025-32975, exploitation of the KPluginRunProcess functionality to execute remote commands, download of Base64-encoded payloads from external infrastructure, creation of new administrative accounts via the runkbot.exe KACE process, credential harvesting using Mimikatz, and then RDP pivots directly to backup infrastructure including Veeam and Veritas servers and domain controllers. The end goal in the observed cases remains unconfirmed, but an attacker who has reached backup infrastructure and a domain controller via a trusted management platform has effectively completed the prerequisites for a ransomware deployment. CISA KEV-listed CVE-2025-32975 on April 20 with a May 4 deadline. The patch has been available since May 2025; any KACE SMA instance that remains on a vulnerable version has had a year of exposure.
What to do: Identify every KACE SMA instance in your environment and confirm the current version. The fixed versions are 13.0.385, 13.1.81, 13.2.183, 14.0.341 (Cumulative Update 6), and 14.1.101 (Cumulative Update 5). Apply the appropriate update through the KACE SMA admin console under Settings > Appliance Updates; if the automatic update does not appear, download the patch manually from the Quest support portal. Note that upgrading from 14.0.341 directly to 14.1.95 is not supported; go to 14.1.101. If your environment runs version 13.x, contact Quest support for the hotfix path rather than attempting a direct upgrade. After patching, address the network exposure: KACE SMA should not have its administrative interface reachable from the open internet under any circumstances. Place it behind a VPN or restrict source IPs at the perimeter firewall to your management VLAN only. Then pull the KACE audit logs and review for the specific indicators Arctic Wolf published: KPluginRunProcess executions you cannot attribute to a scheduled task or administrator action, runkbot.exe process invocations outside of normal deployment windows, new administrative accounts created in the KACE console since March 1, and outbound curl or PowerShell connections to IP addresses outside your approved ranges. If any of those indicators are present, treat the SMA host as compromised and extend your investigation to backup servers and domain controllers that the SMA had network access to.
Monthly or quarterly review
Add to longer-term planning cycles.
-
AI tool connections are now a documented attack surface: the Bitwarden supply chain worm specifically harvested MCP and AI tooling configurations, and the Context.ai OAuth token was the Vercel breach vector
Conduct a one-time audit of AI tool OAuth grants in your Google Workspace and Microsoft 365 tenants this month, and inventory any MCP server connections in your development and MSP tooling environments. Then establish a lightweight approval gate so future AI tool connections go through a deliberate decision rather than an individual employee click.
Why it matters: Two incidents in the past three weeks have made the same point from different angles. The Bitwarden CLI supply chain attack, covered in dispatch-003, was designed to harvest credentials broadly, but the Shai-Hulud worm specifically targeted MCP configuration files alongside AWS, Azure, and GCP IAM keys, GitHub tokens, and SSH keys. MCP (Model Context Protocol) is the standard by which AI coding agents and productivity tools connect to external services: databases, code repositories, communication platforms, and internal APIs. A worm that prioritizes MCP configuration files is not a coincidence; it reflects the attacker's understanding that MCP credentials often carry broad, persistent access to production systems. The Vercel breach, also covered in dispatch-003, traced back to a Context.ai OAuth token: a third-party AI tool connected to a Vercel employee's Google Workspace account suffered its own compromise, and the attacker replayed the OAuth token to pivot into Vercel's internal environment. Neither attack required the victim to do anything wrong in the moment. Both exploited the residual access that AI tools accumulate through OAuth grants and API key configurations that were legitimate at connection time and then went unmonitored. The pattern is now documented across two separate incidents involving two separate attack vectors within a single month. Most organizations that have been experimenting with AI tooling since 2024 have accumulated a significant inventory of these connections without a corresponding inventory of what access each one holds.
What to do: This month, run two audits and establish one process. The first audit is Google Workspace and Microsoft 365 OAuth grants: in Google Workspace, navigate to Security > API Controls > Manage Third-Party App Access and export every connected application. In Microsoft 365, navigate to Azure Active Directory > Enterprise Applications and filter by user-consented applications. For each entry, note the scopes granted, the date of first consent, and whether the app is on an approved vendor list. Flag any AI tool or productivity integration that was consented by an individual user rather than an administrator, any app that has not been accessed in 90 days, and any app requesting Mail.Read, Files.ReadWrite, or equivalent broad-access scopes that its stated function does not require. Revoke access for anything that cannot be justified. The second audit is MCP server configurations: search your development tooling environments, MSP automation platforms, and any AI coding assistant deployments for .mcp.json or mcp.config files, or equivalent MCP configuration surfaces in tools like Claude Code, Cursor, or Windsurf. Inventory what services each MCP server connects to, what credentials it holds, and whether those credentials are scoped to the minimum access the integration requires. Rotate any MCP credential that has been in place since before April 22, 2026 as a precaution given the Bitwarden CLI window. The process to establish is straightforward: require that any new AI tool connection to a Google Workspace or Microsoft 365 tenant, or any new MCP server configuration in a production-adjacent environment, goes through an administrator approval step before it is activated. This does not require a governance committee or a new policy framework; it requires one person with admin rights to make the decision consciously rather than having it happen by default.