Is CVE-2024-28986 (SolarWinds Web Help Desk Deserialization of Untrusted Data) being exploited in the wild?

Yes. CISA added CVE-2024-28986 to its Known Exploited Vulnerabilities catalogue on 15 August 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. SolarWinds Web Help Desk contains a deserialization of untrusted data vulnerability that could allow for remote code execution. Any organisation running the affected product should treat remediation as urgent.

How to think about this CVE now that exploitation is confirmed

CVE-2024-28986 should be treated as an active exploitation event, not a theoretical deserialization flaw. The practical question is not whether the bug exists, but whether your SolarWinds Web Help Desk deployment is exposed, whether it can be reached by an attacker, and whether response needs to move from normal patch cadence to emergency triage. For vulnerability handling, the CISA Known Exploited Vulnerabilities Catalog is the most important external signal because inclusion means CISA has reliable evidence of exploitation. The NIST National Vulnerability Database remains useful for record hygiene and product identification, but KEV status is what should drive urgency.

Because the issue is a deserialization of untrusted data weakness, the main exposure is remote code execution through crafted input. That means the control problem is broader than simply “apply a patch later”: you need to assume the vulnerable service may already have been targeted, and that exploitation can happen without the attacker needing prior account access. The correct operational stance is to treat any reachable instance as high risk until you have confirmed exposure status and completed remediation.

SolarWinds Web Help Desk should therefore be handled as a priority asset, especially where it is Internet-facing, reachable from less trusted network zones, or integrated with systems that hold administrative credentials or service access. A vulnerability of this kind is most dangerous when the application sits near sensitive tickets, automation, or privileged workflows, because code execution inside the help desk stack can become a bridge to broader administrative compromise.

What to confirm before you assume you are safe

Start by confirming whether the product is deployed anywhere in your environment, including forgotten test or backup systems. Then confirm whether the instance is reachable from the internet or from any user-facing segment, and whether compensating controls such as segmentation, application filtering, or upstream reverse proxies are actually constraining the attack surface. If the system exists but cannot be reached, the risk changes materially; if it is reachable, you should assume exploitation is plausible.

Next, verify whether the vulnerable instance has any sign of suspicious activity around the KEV date and after it, including unexpected process creation, unusual child processes from the web application, new scheduled tasks, unfamiliar outbound connections, or changes to local accounts and service configuration. For a deserialization flaw, compromise assessment matters as much as patching because exploitation can be fast and may leave limited obvious traces unless you look for process and file-system side effects.

Use the vendor advisory and the CISA catalogue together for authoritative version and mitigation detail rather than trying to reconstruct the affected build path from secondary writeups. If your exposure is uncertain, the safest assumption is that the installation should be treated as potentially vulnerable until the vendor’s guidance proves otherwise.

What good remediation looks like in practice

Remediation should be executed as an emergency change when the product is exposed. Patch or mitigate first, then validate that the service still functions, and finally review whether any credentials or sessions used by the application need to be rotated because the platform may have exposed them during compromise. If the application stores service account material, API keys, or administrative tokens, treat those as part of the blast radius, not as a separate later task.

When patching must wait, reduce exposure immediately. That usually means restricting network access to the application, placing it behind tighter allowlists, disabling unnecessary interfaces, and increasing monitoring for exploitation indicators. If the platform must remain online, the compensating controls need to be specific enough to reduce reachability, not just general statements that “the system is monitored.”

The most useful follow-up is a short post-remediation check: confirm no new admin-level accounts, no unexplained configuration drift, no unknown web shells or scheduled jobs, and no strange outbound connectivity from the host. If you find evidence of compromise, treat the issue as an incident, not as a patching problem.

Risk and Threat Considerations

Active exploitation changes this CVE from a software defect into a live intrusion path. The risk is not limited to the vulnerable application itself: successful deserialization attacks can give an attacker code execution, which in turn can support persistence, credential access, or pivoting into adjacent systems if the host is trusted by other tools or administrators.

Failure mechanism: Attackers can send or trigger crafted untrusted input that the application deserializes, allowing hostile objects or gadget chains to execute code in the server context and potentially bypass normal application logic.

Impact: The likely consequence is server compromise, followed by theft of sensitive data, tampering with help desk or administrative workflows, and possible lateral movement if the host is connected to privileged services or stores reusable secrets.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	DE.CM-01 — Networks and Network Services Are Monitored	Confirmed exploitation requires active monitoring for signs of compromise on exposed hosts.
Recommendation — Monitor the Web Help Desk host for suspicious processes, connections, and configuration changes.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	An actively exploited CVE demands urgent flaw remediation and verification.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and exploited-vulnerability triage are central to this question.
Recommendation — Prioritise rapid remediation for the vulnerable SolarWinds Web Help Desk installation. Continuously identify whether any Web Help Desk instance remains exposed to the vulnerable condition.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-driven triage is a core vulnerability management use case.
	CIS-17 — Incident Response Management	Possible active exploitation means compromise assessment and incident handling may be required.
Recommendation — Use KEV status to escalate, track, and close the affected instance immediately. Escalate to incident response if compromise indicators appear during validation.

Practitioner Guidance

What to prioritise: Treat any exposed SolarWinds Web Help Desk system as an urgent remediation item, ahead of ordinary patch backlogs, because KEV inclusion means exploitation is already established. If the system is externally reachable or supports privileged workflows, escalate it immediately.

What to verify: Confirm the product’s presence, exposure, and any compromise indicators before relying on a “patched” label. A fixed version alone is not enough if the host was already used as an entry point or if adjacent credentials may have been exposed.

Decision rule: If you cannot patch immediately, reduce network reachability first and then hunt for post-exploitation activity on the host. If you find signs of compromise, move to incident response and credential review rather than treating the event as a routine vulnerability closure.

Practitioner takeaway: KEV status means this is an exploitation problem with operational urgency, so the right sequence is exposure confirmation, rapid remediation, and compromise validation, not patching in isolation.