CVE-2024-28987 is a hardcoded credential vulnerability in SolarWinds Web Help Desk. CISA added it to the Known Exploited Vulnerabilities catalogue on 15 October 2024, which means attackers have used it in real attacks. SolarWinds Web Help Desk contains a hardcoded credential vulnerability that could allow a remote, unauthenticated user to access internal functionality and modify data.
What hardcoded credentials mean in a web application
hardcoded credential are embedded directly into application code, configuration, or shipped assets instead of being provisioned and protected at runtime. That makes them especially dangerous in web applications, where a single exposed secret can bypass normal authentication boundaries and reveal internal functions or data.
For a product like SolarWinds Web help desk, the security problem is not just that a secret exists, but that the secret becomes part of the attack surface. Once attackers discover it, they may be able to act as a trusted component or user without needing to steal a password through normal means.
Why this vulnerability class is dangerous
Hardcoded credentials are risky because they are often reused, copied into multiple environments, and forgotten during deployment and maintenance. They are also difficult to revoke cleanly when they are built into software rather than issued through a controlled secret-management process. NHIMG’s Massive Docker Hub Secrets Leak shows how quickly embedded secrets spread once they leave controlled storage.
The danger increases when the credential unlocks internal functionality rather than a single isolated feature. In that case, one secret can expose administrative actions, internal APIs, or data modification paths that were never meant to be reachable by unauthenticated users. That is why hardcoded secrets are treated as a design flaw, not just a bad password choice.
How organisations check exposure and scope
Exposure review starts with inventory: which systems run the vulnerable product, where it is deployed, and whether any instance is reachable from the internet or a partner network. Organisations should compare that inventory with the vendor advisory and the CISA Known Exploited Vulnerabilities catalogue to confirm whether the weakness is both present and actively exploited.
Because this issue is a hardcoded credential problem, version checking alone is not enough. Teams also need to ask whether the application was cloned, image-copied, or restored from backups in a way that preserved the embedded secret across environments. NHIMG’s Gladinet Hard-Coded Keys RCE Exploitation and ASP.NET machine key attacks 2025 are useful comparisons because they show how embedded secrets can survive long enough to be reused by attackers.
Remediation, detection, and compromise review
Remediation should prioritize removing the embedded secret, replacing it with a unique and revocable credential, and validating that the secret cannot still authenticate anywhere after the fix. If patching is delayed, restrict network exposure, reduce access to the affected service, and watch for requests that indicate unauthorised access to internal functions or data.
Detection should focus on both pre-patch abuse and post-patch compromise review. Logs may show unusual unauthenticated access, unexpected changes to records, or internal-function requests that should never appear from the outside. After remediation, teams should review whether the credential was copied into scripts, automation, documentation, or secondary systems, because a hardcoded secret can remain usable even after the primary application is repaired. NHIMG’s Account Recovery and Help Desk Security Guide is a reminder that internal trust paths often become the next target once a trusted control is bypassed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Hardcoded credentials are an authenticator lifecycle failure. |
| IA-2 — Identification and Authentication (Organizational Users) | The flaw can let unauthenticated users reach trusted internal functionality. | |
| Recommendation — Replace embedded credentials with managed, revocable authenticators and rotate them after exposure. Require strong authentication boundaries before internal functions are exposed. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | A hardcoded credential can bypass normal authentication checks in exposed web functionality. |
| Recommendation — Verify that exposed interfaces reject access unless authentication is validated through normal controls. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Exploited embedded credentials create unauthorized access paths that must be revoked. |
| Recommendation — Remove unnecessary access paths and revoke any credential that may have been exposed. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The issue breaks expected access control by embedding a credential into the application. |
| Recommendation — Apply managed authentication and access control so embedded secrets cannot grant standing access. | ||
Practitioner Guidance
Why practitioners should care: Treat this class of issue as a secret-lifecycle failure, not a narrow vulnerability in one product. If a credential is built into the software, compromise can outlast the original patch unless the embedded secret is invalidated everywhere it was trusted.
What to watch for: Pay attention to externally reachable deployments, cloned environments, and any signs that unauthenticated traffic is reaching internal-only functionality. A hardcoded credential vulnerability often becomes a persistence problem if the exposed secret is never rotated out of downstream systems.
Practitioner takeaway: After the software is fixed, confirm that the credential itself is dead, not just that the code was updated.
Related resources from NHI Mgmt Group
- What breaks when identity verification is missing from help desk credential recovery processes?
- Why does help desk-based credential recovery create such a high identity risk?
- Why does CVE-2024-53677 create such a high-risk condition in Java web applications?
- What should security teams do first after a help desk credential compromise is suspected?