How do you patch or mitigate CVE-2024-28995 (SolarWinds Serv-U Path Traversal Vulnerability)?

CISA’s required action for CVE-2024-28995 is to apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable. In practice, find every instance of SolarWinds Serv-U 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. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

How to patch or mitigate Serv-U safely

The first step is inventory, not patching. Identify every SolarWinds Serv-U instance, confirm whether it is internet-facing, and then apply the vendor security update or documented mitigation exactly as instructed. If you cannot apply a fix, reduce exposure immediately by removing public access or taking the service out of production use until you can do so.

When you are dealing with an exploited vulnerability, the practical objective is to close the reachable attack path as fast as possible. That is why emergency mitigation matters even before a full maintenance window. For vulnerability triage and exploited-in-the-wild response, the most useful starting point is NHIMG’s Zero-Day and Exploited Vulnerabilities Guide, which covers emergency mitigation, KEV triage and post-patch hunting.

If you need a broader operational baseline for this work, use the Vulnerability Management Guide to keep the response tied to asset scope, remediation SLAs, verification and exception handling rather than ad hoc patching.

What to do if patching must wait

If patching is delayed, treat the unpatched Serv-U server as a live exposure and shrink its blast radius. The most effective mitigation is to remove external reachability, limit network paths to trusted admin sources only, and avoid leaving the product available on the public internet while the flaw remains open. If the vendor states that no mitigation is available for your deployment, discontinuing use is the safer option.

In practice, this means favouring containment over convenience. A vulnerable file transfer service is especially sensitive because it often sits near data repositories, automated jobs and privileged transfer workflows, so any exposure should be assumed to have operational consequences beyond the single host. The right benchmark is whether an attacker can still reach the vulnerable path, not whether the service is still nominally running.

For a worked example of why exposed update paths and reachable management surfaces matter, compare this case with Ivanti Connect Secure exploitation 2024, where public exposure created a fast path to credential theft and downstream compromise.

How to verify the fix and look for earlier compromise

After remediation, verify that the specific vulnerable Serv-U instance is no longer reachable in the way the flaw required. Then check logs, authentication records and unusual file-transfer activity for signs that the issue was used before you patched it. If the server handled sensitive transfers or stored automation credentials, review whether those credentials or sessions may need rotation as part of the cleanup.

Do not stop at “the patch installed successfully.” For an exploited vulnerability, the meaningful question is whether the system was already touched. A clean patch does not prove a clean history, so post-remediation hunting should include suspicious requests, unexpected uploads or downloads, and any transfer activity that does not fit the normal operating pattern.

The same post-incident discipline applies in other exploited-vulnerability cases, which is why NHIMG’s SolarWinds supply chain compromise and Mimecast certificate compromise 2021 are useful reference points for thinking about what may need to be reviewed after exposure.

Risk and Threat Considerations

A path traversal flaw in a file transfer product matters because it can let an attacker reach resources outside the intended directory boundary. When the service is exposed to the internet, that boundary failure can become a direct route to data disclosure, tampering, or follow-on access into adjacent systems that trust the transfer server.

Failure mechanism: The vulnerable path handling can allow crafted requests to escape the expected file path and interact with unintended files or locations, especially when the product is reachable from untrusted networks.

Impact: Exposure can range from unauthorized file access to broader compromise of workflows that depend on the server, including theft of sensitive transfers, credentials or configuration material that supports further intrusion.

Standards & Framework Alignment

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

MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while 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	Serv-U patching and KEV-driven triage are core vulnerability management work.
Recommendation — Prioritise, remediate and verify the Serv-U exposure using a risk-based vulnerability process.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Finding all Serv-U instances and verifying remediation requires vulnerability discovery and tracking.
	SI-2 — Flaw Remediation	The question is about applying the vendor fix or mitigation for an exploited product flaw.
	AC-4 — Information Flow Enforcement	Removing internet exposure is a containment step that limits the vulnerable service's reachable paths.
Recommendation — Scan for Serv-U exposure, track remediation status and validate closure after mitigation. Apply the vendor mitigation or update, then confirm the flaw is remediated on every instance. Restrict network access to the vulnerable service until remediation is complete.
OWASP ASVS	V15 — Secure Coding and Architecture	Path traversal is an architectural and input-handling failure that ASVS helps prevent and verify.
Recommendation — Review path handling and input validation to prevent traversal-style flaws in exposed services.
MITRE ATT&CK	T1006 — Path Traversal	The flaw type is path traversal, so this technique directly frames attacker abuse and detection.
Recommendation — Map the vulnerable requests to path-traversal detection and hunt for related malicious access.
OWASP API Security Top 10	API8 — Security Misconfiguration	Exposure and mitigation depend on whether the service is safely configured and externally reachable.
Recommendation — Harden the exposed service and remove unsafe access paths that enable exploitation.

Practitioner Guidance

What to prioritise: Prioritise any Serv-U instance that is internet-facing or sits in a high-trust segment. Those systems have the smallest margin for delay, because the attack path is usually short and the operational impact of compromise can be wider than the product itself.

What to verify: Confirm that the vendor update or mitigation is actually applied on the affected host, that external access is removed where needed, and that the service is no longer reachable through the vulnerable path. If the deployment cannot be fixed quickly, treat removal from service as a valid risk-reduction decision, not a failure.

Practitioner takeaway: For exploited file transfer flaws, the safest sequence is exposure reduction first, verified remediation second, and compromise review third. If you skip the last step, you may preserve a vulnerable-looking service that is already an incident.