The Kaseya VSA Ransomware Attack Explained

In early July 2021, the REvil ransomware cartel turned a widely trusted IT management platform into a delivery mechanism for one of the largest supply chain ransomware events on record. By exploiting a chain of previously unknown vulnerabilities in Kaseya VSA — remote monitoring and management (RMM) software used heavily by managed service providers (MSPs) — attackers pushed ransomware through legitimate software update channels to an estimated 800 to 1,500 downstream businesses, all stemming from compromises at roughly 50 to 60 MSPs. The Kaseya VSA attack remains one of the clearest illustrations of why software supply chain risk cannot be treated as a peripheral concern: a single trusted vendor, compromised once, became a blast radius spanning supermarkets, dental offices, schools, and municipal services across multiple continents.

What Happened, in Brief

Kaseya VSA is an on-premises and SaaS-delivered platform that MSPs use to remotely monitor, patch, and manage their clients' IT infrastructure. That "god mode" position — VSA agents run with high privileges on endpoints precisely so MSPs can push updates and scripts at scale — is exactly what made it such an attractive target. REvil affiliates exploited an authentication bypass and follow-on flaws in the VSA server software to push a malicious "Kaseya VSA Agent Hot-fix" to managed endpoints. That fake hot-fix disabled Microsoft Defender protections, then dropped and executed REvil's ransomware payload, encrypting files across every downstream machine the compromised MSP managed.

Because the payload arrived through Kaseya's own legitimate update mechanism and was signed to look like routine agent maintenance, most endpoint defenses treated it as trusted software rather than a threat — a textbook supply chain trust abuse.

Affected Versions and Components

The vulnerable component was the Kaseya VSA on-premises server software (versions prior to 9.5.7a / VSA 9.5.7c after subsequent patching), along with the Kaseya VSA SaaS instances, which Kaseya proactively shut down as a precaution once exploitation was detected. The vulnerability chain, discovered and responsibly disclosed by Wietse Boonstra of the Dutch Institute for Vulnerability Disclosure (DIVD), spans several distinct issues in the VSA web application and agent architecture:

• CVE-2021-30116 — Credential/authentication weaknesses in the VSA server allowing bypass of authentication controls.
• CVE-2021-30117 — SQL injection in the VSA web interface.
• CVE-2021-30118 — Remote code execution via arbitrary file upload, the primary vector used to deploy the ransomware payload.
• CVE-2021-30119 — Cross-site scripting (XSS) in the VSA UI.
• CVE-2021-30120 — Two-factor authentication bypass affecting VSA logins.
• CVE-2021-30121 — Local file inclusion vulnerability in the VSA web application.

Any organization running an unpatched on-premises VSA server prior to the July 2021 patch releases was directly exposed. Because VSA agents are deployed by MSPs onto client endpoints, the actual population "affected" extended far beyond Kaseya's direct customer list — every downstream business serviced by a compromised MSP inherited the risk without ever running Kaseya software themselves or having any visibility into the vendor relationship that put them at risk.

CVSS, EPSS, and KEV Context

Because several of these CVEs were zero-days at the time of exploitation, initial severity scoring lagged the real-world impact. Once formally scored, the authentication bypass and RCE-class issues (CVE-2021-30116 and CVE-2021-30118) were rated in the critical range, consistent with unauthenticated remote code execution against internet-facing management infrastructure — the kind of vulnerability class that reliably scores at or near the top of the CVSS v3 scale (9.0+) due to low attack complexity, no privileges required, and high impact to confidentiality, integrity, and availability.

All six CVEs were added to CISA's Known Exploited Vulnerabilities (KEV) catalog given confirmed in-the-wild exploitation by REvil affiliates, which under Binding Operational Directive 22-01 obligates U.S. federal civilian agencies to remediate on an expedited timeline. EPSS (Exploit Prediction Scoring System) data for these CVEs — introduced after the incident — reflects sustained high exploitation probability typical of vulnerabilities with public proof-of-concept exploitation, active ransomware tooling, and continued scanning activity years after initial disclosure. For any vulnerability in this bucket — internet-facing RMM software, confirmed KEV listing, ransomware affiliate adoption — the practical takeaway for defenders is the same regardless of the exact numeric score: treat it as immediately actionable, not as a backlog item.

Timeline

• April 2021 — Wietse Boonstra (DIVD) discovers multiple vulnerabilities in Kaseya VSA and privately discloses them to Kaseya under a coordinated disclosure process. Kaseya begins developing patches, with DIVD assisting throughout.
• Spring–Early Summer 2021 — Kaseya works through a patch cycle complicated by the need to update both SaaS and a large, fragmented base of on-premises deployments. Some fixes are staged for a rolling release.
• July 2, 2021 (early afternoon, US Eastern time) — REvil affiliates exploit the unpatched authentication bypass and file-upload RCE chain against internet-facing VSA servers, timed deliberately ahead of the U.S. Independence Day holiday weekend to minimize defender response capacity.
• July 2, 2021 (later that day) — Kaseya proactively shuts down its SaaS servers and urges all on-premises VSA customers to immediately power down their VSA servers, containing further spread even as encryption was already underway at compromised MSPs.
• July 3–4, 2021 — Reports confirm roughly 50-60 MSPs directly compromised, with downstream ransomware encryption cascading to an estimated 800 to 1,500 businesses. Kaseya engages FireEye/Mandiant and coordinates with the FBI and CISA.
• July 5, 2021 — REvil publicly demands $70 million in Bitcoin for a "universal decryptor" capable of unlocking every affected victim.
• July 11, 2021 — Kaseya releases the VSA 9.5.7a patch addressing the disclosed vulnerabilities and provides a phased, verified restart process for on-premises customers before allowing VSA servers back online.
• July 21, 2021 — Kaseya obtains a universal decryptor key and begins distributing it to victims, without confirming payment of ransom. It later emerged that the FBI had obtained the key earlier via covert access to REvil infrastructure but withheld it briefly while planning a broader operation against the group — a decision that drew significant scrutiny.
• Late 2021 — REvil's infrastructure is disrupted in a multi-agency law enforcement operation; a Ukrainian national is later arrested and, in 2022–2023, U.S. authorities charge and sentence individuals connected to the Kaseya attack specifically.

Remediation Steps

Whether you were a direct Kaseya customer in 2021 or you are assessing similar RMM/supply-chain exposure today, the concrete defensive actions are the same:

1. Patch immediately and verify version. Confirm on-premises VSA servers run 9.5.7a or later (or the current supported release), and apply the vendor's documented safe-restart checklist rather than simply flipping the server back on.
2. Restrict internet exposure of management servers. RMM platforms should never be directly internet-facing without compensating controls — place them behind VPN or zero-trust access, and enforce IP allow-listing for administrative interfaces.
3. Enforce MFA and review authentication logs. Given the 2FA-bypass component of this chain, treat any RMM authentication weakness as a priority finding; audit login and session logs for anomalous access during the disclosed exploitation window.
4. Hunt for indicators of compromise. Search for the known REvil-linked file artifacts (e.g., agent.crt, mpsvc.dll, and the malicious hot-fix package naming conventions published by CISA/FireEye), and review EDR/AV exclusion changes pushed through RMM channels, since attackers used the platform's own trust to disable Defender.
5. Segment and limit RMM agent privilege. Apply least-privilege principles to what RMM agents can execute, and segment MSP-managed networks so a single compromised management plane cannot reach every downstream endpoint uniformly.
6. Build an SBOM-driven vendor inventory. Maintain a live inventory of every third-party and MSP-supplied software component with remote execution capability in your environment, so that when the next KEV advisory drops, you know within minutes — not days — whether you're exposed.
7. Have an out-of-band incident response plan. Because Kaseya's own management channel was the attack vector, victims needed alternate, non-VSA-dependent means to communicate remediation guidance to affected endpoints — a lesson applicable to any centralized management tool.

How Safeguard Helps

The Kaseya incident is a case study in why "is this CVE present" is the wrong first question — "is this vulnerable component reachable and exploitable in my environment" is the right one, and it's exactly what Safeguard is built to answer. Our reachability analysis engine traces whether a vulnerable function in an RMM agent, library, or third-party dependency is actually invoked in your deployed code paths, cutting through alert noise so teams aren't stuck triaging thousands of theoretical findings during a live incident. Griffin AI continuously correlates new KEV listings, EPSS shifts, and exploit intelligence against your live SBOM inventory, surfacing exposures like the VSA authentication-bypass chain the moment they become relevant to your stack rather than weeks later in a vendor advisory email. Safeguard's SBOM generation and ingestion pipeline gives security teams the vendor and component visibility that Kaseya customers lacked in 2021 — a real-time answer to "which of our tools, and which of our MSPs' tools, touch our environment." And when a fix is available, Safeguard's auto-fix PRs push the patched dependency or configuration change directly into your codebase or infrastructure-as-code, shrinking the gap between "patch released" and "patch deployed" that ransomware operators depend on to win the race.