SimpleHelp is a confirmed DragonForce on-ramp, a trojanized Bitwarden CLI package was live on npm for 93 minutes, and D-Link DIR-823X has no patch
CISA KEV-listed two SimpleHelp vulnerabilities on April 24 with a May 8 federal deadline; both are confirmed DragonForce ransomware precursors and one carries a CVSS of 9.9. A trojanized build of the Bitwarden CLI was live on npm for 93 minutes on April 22, harvesting cloud credentials and exfiltrating them via public GitHub repositories; any CI pipeline that installed @bitwarden/cli during that window should be treated as compromised. D-Link DIR-823X routers have no patch, are under active Mirai exploitation, and CISA's formal guidance is to remove them from service. CVE-2026-3844 in the Breeze Cache WordPress plugin is under active exploitation with nearly 4,000 blocked attempts documented in a single 24-hour window across 400,000 active installations. The Vercel April breach closed with no npm supply chain compromise, but the attack vector, a stolen Google OAuth token from a third-party AI tool, is a class of exposure most organizations have not inventoried.
Patch today
Items with immediate action required.
-
CVE-2024-57726 and CVE-2024-57728 in SimpleHelp, KEV-listed April 24, confirmed DragonForce ransomware precursor, May 8 federal deadline
Update SimpleHelp to 5.5.8 or later before May 8. If your SimpleHelp server answers to the open internet, that is the more urgent problem, and it needs to be addressed today regardless of patch status.
Why it matters: CISA added CVE-2024-57726 and CVE-2024-57728 to the Known Exploited Vulnerabilities catalog on April 24 with a federal remediation deadline of May 8. The former is a missing authorization flaw rated CVSS 9.9: a low-privileged SimpleHelp technician account, the kind you might create for a subcontractor or a client-side contact, can create API keys with permissions that exceed the technician's own role and then use those keys to escalate directly to server administrator. The latter is a zip-slip path traversal that allows an admin-level user to write arbitrary files anywhere on the SimpleHelp host's filesystem, which in practice means remote code execution on the server. Field Effect and Sophos both documented these CVEs as confirmed precursors to DragonForce ransomware deployments in campaigns observed earlier this year, and Microsoft's April 6 Storm-1175 threat actor profile named the same SimpleHelp CVEs as part of that group's active exploit inventory. The reason the CVSS 9.9 rating on CVE-2024-57726 deserves to be taken literally rather than treated as a number: the path from a compromised low-privilege technician account to server administrator access requires no vulnerability chain, no user interaction, and no elevated starting position. A threat actor who purchases or phishes a single technician credential can complete the escalation in minutes. If your SimpleHelp server is reachable from the internet without a VPN or IP allowlist in front of it, assume the attack surface has been scanned.
What to do: Upgrade SimpleHelp to version 5.5.8 or later. The fix is available through the SimpleHelp administration panel under Server > Updates, or via direct download from simple-help.com; the upgrade process requires a service restart but preserves existing configuration and client connections. After upgrading, open the SimpleHelp administration panel and review every technician account: look for accounts you do not recognize, accounts with API keys attached that were not explicitly created by your team, and any accounts whose last-seen timestamp predates a session you can account for. Export the API key list from Server > Security > API Keys and revoke any key that cannot be traced to a specific integration or automation you control. Then address the network exposure: if your SimpleHelp server's web interface (TCP 443 by default) is reachable from IP ranges outside your office, VPN, or explicitly approved client subnets, restrict it at the firewall or load balancer now. The CVE requires a low-privilege account to exploit, but an attacker needs to reach the server first. Closing the network path is the mitigation that works even against CVEs you have not yet patched.
-
CVE-2025-29635 in D-Link DIR-823X series routers, no patch available, active Mirai botnet exploitation, CISA guidance is to remove from service
If any client is running a D-Link DIR-823X, it needs to come off the network. There is no patch, the hardware is end-of-life, and the active exploit delivers a Mirai variant that folds the device into a botnet within minutes of exposure.
Why it matters: CVE-2025-29635 is an unauthenticated remote code execution vulnerability in the D-Link DIR-823X series of small-business routers. Akamai documented active exploitation this week by a Mirai botnet variant they have named tuxnokill, which targets the device's UPnP service and requires no credentials. CISA added the CVE to the KEV catalog on April 24 with a May 8 federal deadline, but the agency's remediation guidance departs from the usual 'apply the vendor patch' instruction: D-Link has confirmed that the DIR-823X line reached end-of-life and will not receive a security update. CISA's formal recommendation is to discontinue use of the appliance. The D-Link DIR-823X was a common choice for small offices and retail locations in the 2021 to 2023 timeframe, and it tends to sit in environments where nobody is actively reviewing the router's support status. A Mirai-compromised device does not announce itself. It continues routing traffic normally while participating in distributed denial-of-service attacks against third-party targets and, in some observed tuxnokill variants, attempting lateral movement into the LAN. The first indication something is wrong is often an upstream ISP complaint or an anomalous traffic volume spike.
What to do: Search your asset inventory or RMM for D-Link DIR-823X devices. If your inventory does not have router model coverage, check your network scanning tool for the device's default hostname (DIR-823X) or its MAC address OUI ranges (D-Link OUI prefixes begin with 00:26:5A, 1C:7E:E5, 28:10:7B, and several others; a full list is in D-Link's public OUI registry). For any DIR-823X found, plan the replacement conversation with the client this week and schedule removal for no later than the May 8 deadline. The interim mitigation while replacement is being arranged is to disable UPnP on the device (the exploited service) through the router's administration panel under Advanced > UPnP, and to confirm that remote management is disabled on the WAN interface. Neither step fully mitigates the risk on an end-of-life device with an unpatched RCE, but both reduce the attack surface while the replacement is sourced. The replacement does not need to be expensive: Ubiquiti UniFi, Firewalla Gold, or a pfSense-based appliance at a similar price point all provide significantly better security posture and ongoing update support for a comparable total cost.
-
Trojanized @bitwarden/cli@2026.4.0 was live on npm for 93 minutes on April 22; any CI pipeline that installed it during that window has exfiltrated credentials
Check your CI logs for @bitwarden/cli installs between 5:57 PM and 7:30 PM ET on April 22. If you find one, rotate every credential the runner could reach and search for unexpected public GitHub repositories created under your accounts.
Why it matters: On April 22, a malicious build of the Bitwarden CLI was published to npm as @bitwarden/cli@2026.4.0 and remained live for approximately 93 minutes before Bitwarden and Socket identified and removed it. The compromise originated in Bitwarden's CI pipeline via a poisoned checkmarx/ast-github-action step, part of a broader Checkmarx supply-chain campaign attributed to the group TeamPCP. The malicious package carries a credential-harvesting worm that searches the runner environment for AWS, Azure, and GCP IAM credentials; GitHub, npm, SSH, and MCP configuration files; shell history; and AI tooling API keys. It then exfiltrates everything by creating public GitHub repositories under the victim's account, meaning anyone who happened to run a GitHub search at the right moment could have read the contents before the repositories were deleted. Bitwarden's production vault infrastructure was not breached; the exposure is confined to CI runners that installed the malicious npm package during the window. The audience risk is specific: MSPs that embed the Bitwarden CLI in RMM scripts, backup automation, or deployment pipelines, and developer shops that use it in CI, are the environments most likely to have hit the window. The install count is estimated at roughly 334, which is a small number in absolute terms and a large number when each install potentially represents a set of cloud IAM keys and a GitHub token.
What to do: Search your CI platform logs (GitHub Actions, Azure Pipelines, GitLab CI, Jenkins, or your RMM script runner) for any job that installed @bitwarden/cli between 17:57 and 19:30 UTC on April 22, 2026. If you find a hit, treat the runner environment as compromised: rotate every cloud IAM key, GitHub personal access token, npm publish token, SSH key, and API credential that was present in environment variables or configuration files on that runner at the time of the job. Check your GitHub organization for any repositories created between April 22 at 17:57 UTC and April 23 that your team did not create; the malware exfiltrates via public repository creation under the victim's account. If you find unexpected repositories, preserve them for forensic review before deleting. For CI pipelines that were not hit, pin your npm dependencies in lockfiles and enable Dependabot or Socket's GitHub app to alert on dependency substitution attacks going forward. The safe replacement package is @bitwarden/cli@2026.4.1, which is functionally identical to 2026.3.0 and carries no malicious payload.
This week
Worth investigating this week but not today.
-
CVE-2026-3844 in Breeze Cache WordPress plugin, unauthenticated remote code execution, 400,000 active installations, nearly 4,000 exploitation attempts blocked in a single 24-hour window
Update Breeze Cache to 2.4.5 on every managed WordPress site today. If you cannot update immediately, disable the Host Files Locally — Gravatars setting; that is the specific code path being exploited.
Why it matters: CVE-2026-3844 is an unauthenticated file upload vulnerability in Breeze Cache, the caching plugin shipped with Cloudways-hosted WordPress sites and available independently on WordPress.org with approximately 400,000 active installations. The flaw is in the fetch_gravatar_from_remote() function, which accepts an attacker-controlled URL, retrieves its contents, and writes the result to the plugin's cache directory without validating the file type. An attacker sends a crafted request pointing at a PHP webshell hosted on infrastructure they control; the plugin fetches it and writes it to a predictable path in the WordPress filesystem, after which the attacker makes a second request directly to the webshell to execute arbitrary commands on the server. No authentication is required at any step. Wordfence reported active exploitation attempts beginning immediately after the CVE was disclosed on April 21, and Security Affairs documented nearly 4,000 blocked exploitation attempts within the first 24 hours. For MSPs managing WordPress sites on behalf of clients, especially on Cloudways-provisioned hosting where Breeze Cache is the default plugin, this requires the same urgency as any other unauthenticated RCE on a public-facing web server.
What to do: Update Breeze Cache to version 2.4.5 across your managed WordPress fleet. If you use ManageWP, MainWP, or InfiniteWP for WordPress management, the update is available in bulk through the plugin update queue now. For any site that cannot be updated immediately, disable the Host Files Locally — Gravatars option through the Breeze Cache settings panel; this disables the vulnerable code path without removing the plugin. After updating, check each site's Breeze cache directory and the WordPress uploads directory for unexpected PHP, PHTML, or PHAR files; a legitimate caching plugin has no reason to write executable files to those locations. Pull web server access logs for each managed site and look for HTTP requests to .php files in the /wp-content/plugins/breeze/ path since April 21; any 200-response hit against a file your team did not place there is a webshell access event and the site should be treated as compromised.
-
Vercel April 2026 breach closes with no npm supply chain compromise confirmed; the attack vector, a third-party AI tool's stolen Google OAuth token, is a class of exposure most organizations have not inventoried
If you use Vercel, rotate non-sensitive environment variables this week and enable the sensitive environment variable feature going forward. Regardless of whether you use Vercel, audit your Google Workspace OAuth app grants for third-party AI tools. The Context.ai vector that opened this incident is not unique to Vercel.
Why it matters: Vercel disclosed a security incident on April 19 involving unauthorized access to internal systems. By April 23, the investigation had produced enough detail to act on. The attack chain: Context.ai, a third-party AI tool used by a Vercel employee, suffered its own AWS breach in March 2026. The attacker exfiltrated OAuth tokens that Context.ai held for its Google Workspace integration. Those tokens were replayed to access the Vercel employee's Google Workspace account, which provided the pivot into Vercel's internal environment. Vercel confirmed in collaboration with GitHub, npm, and Socket that no npm packages published by Vercel were tampered with; the supply chain scenario that made this incident high-profile in the developer community did not materialize. The confirmed scope was access to internal systems and a small number of customer accounts whose non-sensitive environment variables were readable by the attacker. Vercel separately identified a second, smaller group of compromised accounts that appear to predate this incident and originate from a different vector. The reason this item belongs in the dispatch even for organizations that do not use Vercel is the attack vector itself. A third-party AI tool that an employee connected to their Google Workspace account, and that suffered its own breach, became the entry point into a major cloud infrastructure provider. The same class of exposure exists in any organization where employees connect AI tools, productivity integrations, or data enrichment services to Google Workspace or Microsoft 365 via OAuth without those connections being inventoried or monitored. Most organizations have dozens of these grants outstanding and no alerting on anomalous token usage.
What to do: If you use Vercel: rotate all environment variables that were not marked as 'sensitive' in your Vercel projects, treating them as potentially exposed. Enable the sensitive environment variable feature for any variable that provides access to a production system, a payment processor, a database, or an identity provider. Vercel's administration panel now surfaces this setting more prominently following the incident. Review your Vercel team's connected integrations under Settings > Integrations and revoke any Linear, GitHub, or third-party connection you cannot attribute to a current active integration. Regardless of Vercel: open your Google Workspace admin console, navigate to Security > API Controls > Manage Third-Party App Access, and export the list of OAuth apps with access to your domain. Filter for apps that have not been accessed in the past 90 days, apps that were granted access by individual users rather than by an administrator, and apps requesting scopes beyond what their stated purpose requires. The Context.ai OAuth app identifier published by Vercel as an indicator of compromise is 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com; search your audit logs for that value specifically. For any AI tool in the resulting list that is not on an explicitly approved vendor list, revoke access and route the user through your standard vendor review process before reinstating it. This is not an exotic control: Google Workspace Advanced and Enterprise tiers support continuous access evaluation and OAuth app allow-listing by default. If you are on a Business tier, the export-and-review process is manual but the data is there.