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

Yes. CISA added CVE-2025-26399 to its Known Exploited Vulnerabilities catalogue on 9 March 2026, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. SolarWinds Web Help Desk contain a deserialization of untrusted data vulnerability in AjaxProxy that could allow an attacker to run commands on the host machine.

What “exploited in the wild” means for this CVE

For a CVE question, the practical meaning is narrower than “is there a proof of concept?” It means there is credible evidence that attackers are actively using the flaw against real systems, which is why CISA places it in the KEV catalogue. For this case, the answer should be treated as an active exposure problem, not a theoretical weakness.

That distinction matters because exploited flaws change prioritisation. A deserialization issue in a public-facing management product can move from routine vulnerability handling to emergency response when exploitation is confirmed. The right question becomes whether the product is exposed, whether the vulnerable path is reachable, and whether the environment has already shown signs of command execution or follow-on activity.

For background on how to triage actively exploited vulnerabilities, use Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide to place KEV-listed issues into an emergency remediation flow rather than a standard backlog.

Why deserialization bugs are high-impact when weaponised

deserialization of untrusted data is dangerous because the application may reconstruct attacker-controlled objects with dangerous behaviour attached. In products that process remote requests, that can become command execution, service disruption, or a foothold for deeper compromise. In this CVE, the vulnerable component is AjaxProxy in SolarWinds Web Help Desk, so the issue is not just code quality, it is remote abuse of a management-plane component.

Once command execution is possible on the host, the immediate security concern is not only the original flaw but also what the attacker can do next: enumerate secrets, harvest service credentials, tamper with tickets or workflows, and use the system as a pivot point. That is why exploited deserialization bugs often show up in ransomware playbooks and broad intrusion campaigns. Insecure Deserialisation Guide covers the underlying failure mode, while The State of NHI & AI Agent Breach Report 2026 helps illustrate how initial access frequently turns into credential theft and lateral movement.

Because this is a management application, the blast radius can exceed the host itself. Operators should assume the product may hold privileged integrations, notification credentials, or administrative context that makes post-exploitation activity more damaging than a simple application crash.

What to do when patching must wait

The first step is to confirm exposure, not just presence of the software. Determine whether the vulnerable Web Help Desk instance is reachable from untrusted networks, whether AjaxProxy is exposed, and whether compensating controls can reduce reachability while you work through vendor guidance. If the system is internet-facing, treat the exposure as urgent even before you have confirmed exploitation.

If patching cannot happen immediately, mitigation should focus on reducing exploitability and limiting blast radius. That usually means restricting access to the application, placing it behind stronger filtering or a proxy, tightening administrative access, and increasing monitoring for unusual process creation, new files, unexpected outbound traffic, and unexplained account activity. CISA Known Exploited Vulnerabilities Catalog should remain the operational reference point, and the vendor advisory should be used for version-specific remediation instructions.

If the product has already been exposed for any length of time, assume the possibility of post-compromise persistence. A KEV listing means you should not stop at “we blocked the request pattern”; you should also look for evidence of command execution, new scheduled tasks or services, suspicious child processes, altered web content, and credentials used after the likely compromise window.

Risk and Threat Considerations

When a deserialization flaw is publicly known and confirmed as exploited, the main risk is not only initial access but the speed with which attackers can convert that access into broader compromise. Management tools are attractive because they often sit close to sensitive operational data, privileged workflows, and administrative trust paths.

Failure mechanism: Untrusted input is processed as executable object state, allowing remote commands or equivalent malicious behaviour on the host. In a KEV-listed issue, that means the window for safe delay is usually much smaller than teams expect.

Impact: Successful exploitation can lead to host takeover, credential exposure, service tampering, and ransomware staging, especially if the system has administrative reach into other tooling or networks.

Standards & Framework Alignment

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

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

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation requires urgent vulnerability prioritization and remediation.
	CIS-8 — Audit Log Management	Post-exploitation checks depend on host and application logging for abuse detection.
Recommendation — Prioritize and remediate KEV-listed exposures immediately. Review logs for command execution and suspicious access patterns.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	Deserialization of untrusted data is an input-handling failure that this control addresses.
	RA-5 — Vulnerability Monitoring and Scanning	KEV status makes active vulnerability monitoring central to response.
Recommendation — Validate and constrain untrusted input before processing it. Track and prioritize actively exploited vulnerabilities for rapid remediation.
OWASP ASVS	V5 — File Handling	Deserialization flaws often arise in unsafe object and file handling paths.
Recommendation — Verify that unsafe deserialization paths are eliminated or tightly constrained.

Practitioner Guidance

What to prioritise: Confirm whether any SolarWinds Web Help Desk instance is externally reachable, then check whether the vulnerable path is exposed in the exact deployment you run. If the product sits in a critical support or operations workflow, treat containment and compromise assessment as parallel tasks, not sequential ones.

What to verify: Look for evidence of earlier compromise before or during mitigation, including unexpected command execution, unusual outbound connections, new local accounts, changes to application files, and any signs that the host was used to access adjacent systems. If the product handled privileged tickets or integrations, review those downstream systems as part of the same incident scope.

Decision rule: If you cannot patch immediately, reduce exposure first, then hunt for compromise, then rotate any credentials, tokens, or service accounts that the application could have exposed. The order matters because an exploited management system can preserve attacker access even after the original vulnerability is blocked.

Practitioner takeaway: For KEV-listed deserialization flaws, the operational question is no longer “is there a bug?” but “how quickly can an attacker turn this host into a control point, and what else must be assumed compromised if they did?”