Is CVE-2024-28987 (SolarWinds Web Help Desk Hardcoded Credential) being exploited in the wild?

Yes. CISA added CVE-2024-28987 to its Known Exploited Vulnerabilities catalogue on 15 October 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 hardcoded credential vulnerability that could allow a remote, unauthenticated user to access internal functionality and modify data.

What makes a hardcoded credential CVE worth urgent attention?

A hardcoded credential is not just a coding flaw, it is an access flaw. When a product ships with embedded credentials, the risk is that anyone who discovers or reverse engineers them can reach functionality that should have been protected. For practitioners, the key question is whether the credential exposes administrative, internal, or otherwise sensitive paths.

In practice, that means treating the finding as both a vulnerability-management issue and an access-control failure. The immediate focus should be on exposure scope, whether the credential is reusable outside its intended environment, and whether any authentication or authorization path depends on it. For context on actively exploited weaknesses and response triage, see the Zero-Day and Exploited Vulnerabilities Guide.

Why active exploitation changes the response posture

Once a CVE is known to be exploited in the wild, the priority shifts from normal patch planning to containment-minded response. The issue is no longer hypothetical exposure, because attackers are already using the weakness as an access path. That raises the value of rapid identification, emergency mitigation, and post-fix verification.

For a hardcoded credential issue, active exploitation can mean unauthorized access before defenders have had time to patch, disable the vulnerable component, or rotate exposed secrets. When the flaw enables remote, unauthenticated access, defenders should assume that opportunistic scanning and automated abuse may already be underway. The CISA Known Exploited Vulnerabilities Catalog is the authoritative source for confirming exploitation status and response urgency.

What practitioners should verify before calling the issue contained

Containment is not just “patch installed.” Teams should verify whether the affected service was reachable from untrusted networks, whether the embedded credential had broader privileges than expected, and whether any logs show access attempts, unusual admin actions, or data changes. If the vendor advisory or product documentation describes local internal functionality being reachable through the flaw, that access path deserves immediate review.

When patching is delayed, the practical question is what can be disabled, isolated, or access-restricted without breaking the business process. If the exposed credential was used for service access, session handling, or backend administration, review whether adjacent secrets, tokens, or accounts need rotation as a precaution. For exploitation likelihood and triage prioritisation, the FIRST EPSS can help determine how aggressively to prioritise response work, alongside KEV status and asset criticality.

Risk and Threat Considerations

Hardcoded credentials are attractive because they compress the attack path: discovery of the credential can immediately become authenticated access. In an internet-facing product, that can turn a single weakness into broad unauthorized reach, especially if the credential is shared across environments or grants write access to internal data.

Failure mechanism: The embedded credential can be extracted from the product, then reused by a remote attacker to authenticate without needing to defeat normal login controls or user oversight.

Impact: Attackers may access internal functionality, alter data, enumerate backend paths, or establish a foothold that survives until the credential is rotated and the affected component is verified clean.

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
CIS Controls v8	CIS-5 — Account Management	Hardcoded credentials are an account-management failure that demands inventory and removal.
Recommendation — Inventory embedded credentials and remove any account material tied to exposed product secrets.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Hardcoded credentials are authenticators that require lifecycle control, rotation, and revocation.
	AC-6 — Least Privilege	The flaw matters more when the embedded credential grants excess internal privilege.
Recommendation — Rotate and revoke any embedded authenticators associated with the vulnerable component. Restrict the credential's permissions to the minimum function needed or remove it entirely.
OWASP Non-Human Identity Top 10	NHI-02 — Secret Leakage	The CVE centers on embedded secret exposure that enables unauthorized access.
	NHI-05 — Overprivileged NHI	A hardcoded credential is most dangerous when it can reach internal functions with excess privilege.
Recommendation — Eliminate embedded secrets from products and replace them with managed, rotatable credentials. Reduce any product credential to the minimum reachable scope and separate duties by environment.

Practitioner Guidance

What to prioritise: Treat KEV-listed hardcoded credential flaws as exposure events first and patch events second. Confirm whether the vulnerable service is internet reachable, whether the credential is still valid, and whether the access path can modify data or invoke privileged functions.

What to verify: Look for signs of prior abuse, including unusual administrative requests, unexpected record changes, new accounts, or backend access outside normal support windows. If the product stores configuration or credentials locally, check whether backups, images, or cloned instances preserved the same secret.

Decision rule: If you cannot prove the credential was never exposed or reused, assume the system may already have been accessed and rotate any adjacent secrets or accounts that share trust with the vulnerable component.

Practitioner takeaway: A hardcoded credential CVE is dangerous because exploitation can be immediate and silent, so containment depends on proving who could use the credential, where it was exposed, and what it could change.