How do you patch or mitigate CVE-2025-26399 (SolarWinds Web Help Desk Deserialization of Untrusted Data)?

CISA’s required action for CVE-2025-26399 is to apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable. In practice, find every instance of SolarWinds Web Help Desk in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service.

What CVE-2025-26399 Means Operationally

CVE-2025-26399 is a deserialization flaw in SolarWinds Web Help Desk, so the practical question is whether the product is present, reachable, and still exposed in a way that makes the known vendor mitigation usable. For this class of issue, the priority is not only patching, but also reducing exposure while you verify that the product is no longer externally reachable through the vulnerable path.

Because the problem is deserialization of untrusted data, the failure mode is often remote code execution or equivalent arbitrary behaviour once an attacker can send crafted input. That is why a simple “installed versus not installed” check is not enough. You need to confirm whether the vulnerable component is deployed, whether any compensating control is actually in front of it, and whether the vendor’s documented mitigation can be applied cleanly in your environment.

If you are triaging exposure, the fastest useful checks are asset inventory, service inventory, and external reachability. Find every Web Help Desk deployment, confirm which instances are internet-facing or reachable by untrusted users, and verify whether any local hardening or proxy restriction is already limiting the attack surface. For background on how exploited vulnerabilities should be prioritised and handled under emergency conditions, see the Zero-Day and Exploited Vulnerabilities Guide.

Patch, Mitigation, and Exposure Reduction

The correct remediation path is to apply the vendor security update or the vendor-documented mitigation exactly as instructed, then confirm the fix by re-testing the exposed service and checking that the vulnerable behaviour is no longer reachable. If your environment uses cloud services or managed hosting controls that fall under CISA guidance, align the response with the relevant BOD 22-01 expectations referenced in the direct answer.

When patching is delayed, mitigation needs to be concrete, not advisory. The most effective interim actions are to remove internet exposure, restrict access to trusted networks only, and take the product out of service if no acceptable mitigation exists. If the application is business-critical, place it behind stricter network controls and monitor for any suspicious requests or abnormal server behaviour until the fix is in place.

Use vulnerability management discipline rather than ad hoc patching. Confirm the asset is in scope, assign an owner, track remediation to closure, and verify the result instead of assuming a change window equals a fix. The Vulnerability Management Guide is the relevant internal reference for prioritisation, exception handling, and verification after remediation.

For the technical root cause, it also helps to anchor the response in the deserialization pattern itself. If your team is unsure whether the product is vulnerable because input handling looks “protected,” review the broader failure mode in the Insecure Deserialisation Guide, since allowlists and filtering only help when they are implemented in a way that blocks attacker-controlled object graphs.

What to Check After You Patch

After remediation, validate more than the version state. Reconfirm that the vulnerable endpoint is no longer reachable, that any removed exposure has not been silently reintroduced, and that logs do not show suspicious activity around the window when the flaw was exposed. If the instance was internet-facing before mitigation, treat the post-fix review as a compromise check, not just a patch verification step.

If there is any sign the service may have been accessed before remediation, investigate for server-side abuse, unexpected configuration changes, new accounts, or lateral movement from the affected host. For exploited vulnerabilities, post-patch hunting matters because attackers often act before defenders can complete rollout. The CISA Known Exploited Vulnerabilities Catalog is the authoritative source for confirming that this issue is being handled as an exploited vulnerability, and the NIST National Vulnerability Database is useful for record-level validation and product matching.

Risk and Threat Considerations

Deserialization flaws are dangerous because they turn untrusted input into executable object handling, which can give an attacker a direct path from a network request to application-level compromise. If the system is exposed externally, the attack window is often short, and defenders may not notice exploitation until after the product has already been used as the entry point.

Failure mechanism: An attacker supplies crafted data that the application deserializes into unexpected objects or code paths, allowing malicious behaviour before normal access controls or business logic can stop it.

Impact: The result can include remote code execution, service compromise, data exposure, persistence, or follow-on movement from the vulnerable host into adjacent systems.

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 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.AM-01 — Asset Inventory	Identifies every Web Help Desk instance before remediation.
	PR.PS-01 — Configuration Management	Supports applying vendor mitigations and hardening exposed instances.
	DE.CM-01 — Monitoring for Unauthorised Activity	Supports post-patch hunting for signs of pre-remediation abuse.
Recommendation — Inventory all deployments and external exposures before you decide patch priority. Apply the vendor fix and lock down the affected service configuration. Review logs and telemetry for suspicious activity around the exposure window.
NIST SP 800-53 Rev 5	SI-10 — Information Input Validation	Deserialization flaws are fundamentally unsafe input handling problems.
	RA-5 — Vulnerability Monitoring and Scanning	Supports finding every affected instance and tracking remediation.
Recommendation — Validate and constrain untrusted inputs before they reach deserialisation logic. Scan for affected assets and track remediation until exposure is closed.

Practitioner Guidance

What to prioritise: Treat internet-facing Web Help Desk instances as the highest-priority assets, then move inward to internally reachable deployments. If multiple instances exist, remediate the most exposed one first, because exposure materially changes the likelihood of exploitation before the rest of the estate is even finished being inventoried.

What to verify: Verify that the vendor fix or mitigation has been applied to every instance, and then verify that the vulnerable path is actually unreachable. A patch without reachability testing is not a complete security decision for this CVE.

Decision rule: If you cannot apply the vendor mitigation quickly and safely, remove external exposure or discontinue use of the product rather than leaving a known exploited flaw online. That is the right call when the remaining risk is less about inconvenience and more about preventing a predictable compromise path.

Practitioner takeaway: For an exploited deserialization issue, the operational goal is to shrink exposure first, confirm the fix second, and assume compromise until logs and host telemetry prove otherwise.