How do you patch or mitigate CVE-2024-28987 (SolarWinds Web Help Desk Hardcoded Credential)?

CISA’s required action for CVE-2024-28987 is to apply mitigations per vendor instructions 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 this CVE means in practice for SolarWinds Web Help Desk

This is a hardcoded credential issue, so the core task is not just “apply a patch” but confirm where Web Help Desk is deployed, whether the vendor fix or mitigation is available for that instance, and whether the product can be isolated if remediation is delayed. Treat every exposed deployment as a potential entry point until you verify the mitigation path and exposure status.

Because the weakness involves embedded authentication material, the practical scope includes administration access, service access, and any path that could let an attacker reuse the product’s trust. If you cannot remove the vulnerable instance quickly, reduce its reachable surface first and then verify whether any secrets, sessions, or connected systems may have been exposed through the product.

For a broader playbook on exploited-vulnerability response, the Zero-Day and Exploited Vulnerabilities Guide is the best internal starting point for triage, emergency mitigation, and post-patch hunting.

How to confirm exposure and choose the safest remediation path

Start by locating every SolarWinds Web Help Desk installation, including forgotten test, support, and backup environments. Then confirm whether that instance is on the vendor-supported remediation path, because the right answer depends on whether a documented security update or mitigation exists for the specific deployment.

If the vendor fix is available, apply it through your normal change process, but do not stop at installation success. Verify that the vulnerable service is no longer Internet-reachable where that was previously a factor, and review any adjacent access paths such as reverse proxies, VPN routes, and administrative portals that may still expose the application.

If the vendor mitigation cannot be applied, the decision shifts from patching to risk containment. In that case, remove external exposure, restrict access to the smallest possible administrative network, or take the product out of service if you cannot reduce the risk to an acceptable level.

The most useful parallel check is whether the product has already been abused. Use logs, configuration state, and account activity to look for signs that the hardcoded credential may have been used before remediation, because a fix alone does not reverse earlier compromise.

For direct remediation examples involving hardcoded credentials, see Gladinet Hard-Coded Keys RCE Exploitation and SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890), which both show why hardcoded access material must be treated as a systemwide trust failure, not a narrow configuration defect.

What to do after patching or mitigation is in place

Once the vulnerable instance is updated or isolated, assume the credential issue may have exposed more than one layer of access. Review administrator accounts, service accounts, API integrations, and any tokens or keys that Web Help Desk could have used to talk to other systems.

Rotate only the credentials that are actually in the trust path, but rotate them decisively if the product could authenticate into other systems, write to directories, or reach support tooling. Where the product was Internet-facing, assume an attacker may have had enough time to enumerate the service and test the exposed access path before you contained it.

Keep evidence of what changed, when it changed, and which hosts were affected. That record matters if you later need to prove whether the exposure was limited, whether a login path was abused, or whether a downstream system needs its own investigation.

For external confirmation of the vulnerability record and remediation status, consult the CISA Known Exploited Vulnerabilities Catalog and the NIST National Vulnerability Database.

Risk and Threat Considerations

A hardcoded credential turns a product defect into a reusable trust break. If the value is recoverable or guessable from the application, an attacker does not need a user to disclose it, which makes exposure especially dangerous on Internet-facing or broadly reachable deployments.

Failure mechanism: The application embeds authentication material that should have been unique, protected, or externally managed, so compromise of the product can become compromise of the access path it protects.

Impact: Attackers may gain unauthorized administrative or service-level access, move into connected systems, or preserve access until every dependent credential and trust relationship is reviewed.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	Hardcoded credentials are secret leakage that can expose product trust paths.
	NHI-05 — Overprivileged NHI	A leaked product credential can grant broader access than intended.
	NHI-07 — Long-Lived Secrets	Hardcoded credentials are typically long-lived and hard to revoke quickly.
Recommendation — Eliminate embedded secrets and rotate any exposed credentials immediately. Reduce the credential's permissions to the minimum required. Replace long-lived embedded secrets with managed, rotating credentials.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Mitigation depends on securing the affected software configuration and exposure.
	CIS-5 — Account Management	Credential exposure requires review of accounts and access paths the product could use.
	CIS-18 — Penetration Testing	Post-fix validation should confirm the exposed access path is no longer exploitable.
Recommendation — Harden the deployment and remove unnecessary network exposure. Inventory and rotate affected accounts, keys, and service access. Validate that the vulnerability is no longer reachable after remediation.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Hardcoded credentials violate authenticator lifecycle and revocation expectations.
	AC-6 — Least Privilege	Mitigation should limit what the exposed credential can reach if abused.
Recommendation — Replace embedded authenticators and revoke any exposed secrets. Constrain the product's access to the smallest necessary set of resources.

Practitioner Guidance

What to prioritise: Triage Internet-exposed Web Help Desk instances first, then any deployment that can authenticate into other systems or reach sensitive support workflows. Those are the instances where a hardcoded credential most quickly turns into real blast radius.

What to verify: Confirm that the vendor mitigation actually removed the vulnerable access path, not just the symptom. If the product remains reachable, assume an attacker can still test the old trust boundary unless you have evidence that the credential is no longer usable.

Decision rule: If patching or mitigation cannot be applied promptly, take the product out of service or remove external exposure before spending time on lower-value hardening. For this kind of flaw, containment is the risk-reduction step that buys time.

Practitioner takeaway: With hardcoded credentials, the real question is whether the product can still be trusted to hold its own access boundary, not whether the binary is technically patched.