CVE-2024-28986

What it actually does

CVE-2024-28986 is a Java deserialization remote code execution vulnerability in SolarWinds Web Help Desk. A vulnerable server can deserialize attacker-controlled data and instantiate or invoke dangerous Java gadget chains, allowing commands to execute in the context of the Web Help Desk application service account. Successful exploitation can provide full compromise of the application host, including read/write access to application data, credential material available to the service, and the ability to deploy additional tooling. Although the issue was reported as unauthenticated, SolarWinds stated it could not reproduce exploitation without authentication; defenders should treat exposed instances as high risk because the CVSS vector is network-accessible, low-complexity, and no-user-interaction, and the vulnerability is listed in CISA KEV with active exploitation in the wild.

Why it matters to the business

An exploited Web Help Desk server can become an entry point into the organization, allowing attackers to disrupt help desk operations, steal ticket data and credentials, pivot to internal systems, or deploy malware. Because this vulnerability is in the CISA Known Exploited Vulnerabilities catalog, has a high EPSS score, and the remediation deadline of 2024-09-05 has long passed, unpatched internet-facing systems should be considered urgent exposure. Compromise may affect IT support continuity, incident response operations, employee data in tickets, internal infrastructure details, and regulatory obligations if sensitive information is accessed.

How an attack unfolds

An attacker first identifies an exposed SolarWinds Web Help Desk instance, commonly by scanning for the Web Help Desk web interface or fingerprinting application responses. The attacker then sends a crafted request containing serialized Java data to a vulnerable application path or function that processes the object. If the request reaches the vulnerable deserialization code path, the application deserializes attacker-controlled content and triggers a gadget chain that executes operating system commands under the Web Help Desk service account. Depending on the server configuration, the attacker may need valid credentials or may exploit another weakness to obtain access first. After command execution, the attacker typically validates execution with a benign command, writes a web shell or downloader, creates persistence, dumps configuration files and credentials, and uses the compromised server to access ticket data or move laterally.

How to fix it

Apply the SolarWinds Web Help Desk vendor patch or hotfix that remediates CVE-2024-28986 on all affected instances. If package-level remediation data is being tracked for the supplied inventory item, upgrade cloud-init on AlmaLinux 8 to 21.1-7.el8.alma or later; also verify that this package entry is actually relevant to the asset because the vulnerability itself concerns SolarWinds Web Help Desk. Until patching is complete, remove Web Help Desk from direct internet exposure, restrict access by VPN or allowlisted administrative networks, enforce strong authentication, disable unused accounts, rotate credentials stored or used by the application, and monitor closely for command execution artifacts. If compromise is suspected, do not rely on patching alone: isolate the server, collect forensic evidence, rebuild from trusted media where appropriate, rotate secrets, and review adjacent systems for lateral movement.

How to confirm the fix worked

Confirm the installed SolarWinds Web Help Desk build includes the vendor fix for CVE-2024-28986 and that no older vulnerable instances remain online. Validate from both asset inventory and network perspective: enumerate exposed Web Help Desk interfaces, check application version banners or administrative version pages where available, and confirm external scanners no longer identify vulnerable Web Help Desk services. For AlmaLinux 8 systems where the supplied package data is applicable, verify `rpm -q cloud-init` reports version 21.1-7.el8.alma or later. After patching, review access controls to ensure the Web Help Desk interface is not unnecessarily internet-facing and test that monitoring is collecting Web Help Desk application logs, web access logs, Tomcat logs, operating system process creation logs, and endpoint telemetry.

Typical attack path

1. Scan the internet or internal network for SolarWinds Web Help Desk instances.
2. Fingerprint the exposed application version and determine whether it is unpatched.
3. Obtain or abuse application access if authentication is required in the target configuration.
4. Send a crafted Java serialized payload to the vulnerable Web Help Desk endpoint or function.
5. Trigger deserialization and execute commands as the Web Help Desk application service account.
6. Run reconnaissance commands to identify host privileges, network reachability, and stored credentials.
7. Deploy follow-on tooling such as a web shell, reverse shell, downloader, or persistence mechanism.
8. Access help desk ticket contents, configuration files, logs, attachments, or credentials available to the application.
9. Use the compromised host as a foothold for lateral movement or data theft.

How to detect it

Hunt for evidence of exploitation across application, web, host, and network telemetry. Review SolarWinds Web Help Desk logs, embedded Tomcat logs, reverse proxy logs, WAF logs, EDR telemetry, Windows Event Logs, Linux audit logs, shell history, and firewall/proxy records. Look for unusual POST requests to Web Help Desk paths, large or binary-looking request bodies, Java serialization errors, unexpected HTTP 500 responses followed by successful requests, or requests from scanning infrastructure. On the host, prioritize detection of Java or the Web Help Desk service spawning operating system shells or utilities such as cmd.exe, powershell.exe, bash, sh, curl, wget, certutil, bitsadmin, nc, ncat, python, perl, or chmod. Review newly created or modified files under Web Help Desk installation, webroot, temp, upload, and Tomcat work directories. Investigate newly created application users, privilege changes, abnormal logins, unusual ticket or attachment access, and configuration exports. Because this vulnerability has been exploited in the wild and the KEV deadline has passed, absence of a single IOC is not sufficient; combine version validation, exposure review, process telemetry, file-system timeline analysis, and credential-use review.

• java.io.InvalidClassException
• java.io.StreamCorruptedException
• invalid stream header
• java.io.ObjectInputStream
• ysoserial
• commons-collections
• Runtime.getRuntime
• ProcessBuilder
• cmd.exe /c
• powershell.exe -enc
• powershell.exe -EncodedCommand
• /bin/sh -c
• /bin/bash -c
• curl http://
• wget http://
• certutil.exe -urlcache
• bitsadmin /transfer
• java.exe spawning cmd.exe
• java.exe spawning powershell.exe
• java.exe spawning /bin/sh
• java.exe spawning /bin/bash
• C:\Program Files\WebHelpDesk\
• C:\Program Files (x86)\WebHelpDesk\
• /usr/local/webhelpdesk/
• /Library/WebHelpDesk/
• catalina.out
• localhost_access_log
• whd.log
• .jsp uploaded under WebHelpDesk
• .war created under WebHelpDesk
• /tmp/ysoserial
• /tmp/.java
• nc -e
• ncat -e

What your security team should do

• Immediately identify all SolarWinds Web Help Desk instances, especially internet-facing systems, and prioritize remediation because the vulnerability is in CISA KEV and exploitation is active in the wild.
• Patch Web Help Desk using the SolarWinds vendor fix; if the supplied AlmaLinux package entry applies to tracked assets, update cloud-init to 21.1-7.el8.alma or later.
• Treat unpatched or previously exposed instances as potentially compromised and perform threat hunting before returning them to normal operation.
• Restrict Web Help Desk access to trusted networks or VPN users; remove direct public exposure wherever possible.
• Rotate credentials used by Web Help Desk, including database, LDAP/AD, SMTP, service-account, API, and integration credentials if compromise cannot be ruled out.
• Review application users for newly created accounts, privilege changes, unexpected technician accounts, and suspicious login patterns.
• Collect and preserve Web Help Desk, web server, Tomcat, operating system, EDR, firewall, and proxy logs for the period before and after patching.
• Search for suspicious child processes spawned by Java or the Web Help Desk service, such as shell interpreters, download utilities, encoded PowerShell, or archive tools.
• Inspect the Web Help Desk installation directories and web-accessible paths for recently modified JSP, WAR, JAR, script, or binary files.
• If evidence of command execution, web shell deployment, or credential access is found, initiate incident response, isolate the host, rebuild if needed, and investigate lateral movement.