SolarWinds Attack: WHD Exploit on Exposed Servers

software exposure and potential compromise history. A broader Cyber Security Assessment can help review internet-facing systems, identity controls, network exposure, endpoints, and other security weaknesses that may increase the impact of an application compromise.

Which SolarWinds WHD Vulnerabilities Are Linked to the Attacks?

Three vulnerabilities are central to the investigation because affected systems were exposed to them during the relevant period.

CVE	Vulnerability	Authentication	Severity / Context	Why It Matters
CVE-2025-40551	Deserialization of untrusted data leading to RCE	Not required	9.8 Critical	Can allow commands to run on a vulnerable WHD host
CVE-2025-40536	Security-control bypass	Not required	8.1 High	Can expose functionality that should otherwise be restricted
CVE-2025-26399	AjaxProxy deserialization RCE	Not required	Critical historical WHD flaw	Earlier vulnerability relevant to systems involved in the investigation

SolarWinds documents CVE-2025-40551 and CVE-2025-40536 in its official WHD 2026.1 release notes, along with several other security fixes released at the same time.

CVE-2025-40551: Unauthenticated Remote Code Execution

CVE-2025-40551 is the most severe of the newly disclosed vulnerabilities associated with the incident.

SolarWinds describes it as a deserialization flaw that can allow remote code execution without authentication. In practical terms, a remote attacker may be able to send specially handled data to a vulnerable WHD system and cause the application to execute commands on the underlying server.

The vulnerability's exploitation status can also be checked through CISA's official Known Exploited Vulnerabilities Catalog, which tracks vulnerabilities with evidence of exploitation in the wild.

CVE-2025-40536: Security-Control Bypass

CVE-2025-40536 is different from the RCE flaw.

SolarWinds says the vulnerability could allow an unauthenticated attacker to access functionality that should normally be restricted. The vendor rated it 8.1 High.

The distinction matters because not every vulnerability involved in an attack chain has to provide full remote code execution on its own. A control bypass can still remove barriers that protect sensitive application functionality.

CVE-2025-26399: An Earlier WHD RCE Flaw

CVE-2025-26399 predates the January 2026 WHD vulnerability group.

The official NIST National Vulnerability Database entry for CVE-2025-26399 describes it as an unauthenticated AjaxProxy deserialization issue affecting SolarWinds Web Help Desk.

This older vulnerability is important because the systems Microsoft investigated were exposed to more than one relevant WHD weakness. That makes it difficult to attribute initial access to one CVE with certainty.

Did Microsoft Confirm Which WHD CVE Attackers Used?

No. Microsoft confirmed exploitation of vulnerable WHD servers, but it did not reliably identify the exact vulnerability used to gain the initial foothold in its December 2025 cases.

This is one of the most important facts in the incident.

The attacks occurred before the January 28 disclosure of CVE-2025-40551 and CVE-2025-40536. At the same time, affected systems were also vulnerable to the previously known CVE-2025-26399.

Because several relevant weaknesses existed simultaneously, Microsoft's investigation could not establish which one supplied initial access.

Confirmed vs. Not Confirmed

Question	Evidence Status
Were internet-exposed WHD systems exploited?	Confirmed
Did attackers achieve remote execution on affected WHD systems?	Confirmed
Was CVE-2025-40551 definitely the initial exploit?	Not confirmed
Was CVE-2025-40536 definitely the initial exploit?	Not confirmed
Could CVE-2025-26399 have been involved?	Possible; not established as the sole initial vector
Did attackers use legitimate administrative or remote-management tools?	Confirmed
Did some activity reach credential and domain-level operations?	Confirmed
Was every publicly accessible WHD installation compromised?	No evidence supports that conclusion

This distinction prevents a common security-reporting mistake: a vulnerability associated with an affected system should not automatically be described as the proven initial exploit.

How Did Attackers Move From WHD Access to Broader Compromise?

The larger concern was what happened after attackers gained access to the WHD host.

Microsoft documented several stages.

PowerShell and BITS Execution

The compromised WHD service spawned PowerShell, after which attackers used the Windows Background Intelligent Transfer Service, or BITS, to retrieve and execute additional payloads.

PowerShell and BITS are legitimate Windows capabilities, so their presence alone is not proof of malicious activity.

Security teams need to examine:

·         which parent process launched them;

·         the commands used;

·         network destinations;

·         user context;

·         timing;

·         whether the activity matches normal administration.

Remote Management and Interactive Access

Microsoft observed components associated with Zoho ManageEngine, a legitimate remote-monitoring and management platform, on several affected hosts.

Attackers used remote access to interact with compromised systems and enumerate sensitive Active Directory users and groups, including Domain Admins.

This is a useful reminder that security monitoring cannot rely entirely on identifying obviously malicious software. Legitimate administrative products can become attacker infrastructure when installed or operated without authorization.

Reverse SSH, RDP, and Virtualized Persistence

Microsoft also observed reverse SSH and Remote Desktop activity.

In some environments, a scheduled task launched a QEMU virtual machine under the SYSTEM account during startup. Microsoft assessed this as a persistence mechanism that could help maintain access while isolating part of the attacker's environment inside a virtual machine.

Credential Access and DCSync

The intrusion became more serious when attackers moved toward credentials.

Microsoft documented DLL sideloading activity involving wab.exe and a malicious DLL as well as behavior associated with LSASS credential access.

In at least one observed case, activity progressed to DCSync.

DCSync is an Active Directory technique in which a sufficiently privileged actor impersonates domain-replication behavior to request password-related directory information.

Once activity reaches this stage, security teams should not assume that remediation of the original WHD server has resolved the wider incident.

How Can Organizations Detect SolarWinds WHD Exploitation?

Detection should focus on both the WHD application and what happened around it.

Microsoft's investigation provides several useful behavioral starting points.

Review WHD Child Processes

Investigate unexpected operating-system commands, script interpreters, or utilities started by WHD-related Java, Tomcat, or wrapper processes.

A help-desk service unexpectedly launching PowerShell or system reconnaissance commands deserves investigation.

Review Newly Installed Remote-Management Software

Identify administrative and RMM products installed around the suspected compromise window.

Ask:

·         Was the installation authorized?

·         Which user or process installed it?

·         When did it first run?

·         Which external services did it contact?

·         Does the activity match normal administrative procedures?

Hunt for Unexpected SSH and RDP Activity

Look for unexplained:

·         reverse SSH connections;

·         tunnels;

·         port forwarding;

·         RDP sessions;

·         newly established remote-access mechanisms involving the WHD host.

Investigate Credential-Access Signals

Review:

·         suspicious LSASS access;

·         unusual DLL loading;

·         abnormal privileged-account behavior;

·         unexpected service-account usage;

·         domain-replication events;

·         DCSync-related activity.

Preserve Evidence

If compromise is suspected, preserve the evidence needed to reconstruct what happened.

Useful sources may include:

·         WHD application logs;

·         endpoint telemetry;

·         Windows event logs;

·         identity and Active Directory events;

·         firewall and proxy logs;

·         remote-management installation records;

·         authentication logs;

·         EDR alerts.

If suspicious activity is already present and the internal team cannot determine how far the intrusion progressed, Hoplon's Incident Readiness, Response & Recovery service is the most directly relevant professional support option.

It can be appropriate when an organization needs to investigate suspected access, contain confirmed activity, determine scope, and support recovery decisions.

Visual Data Overview

This table highlights why traditional detection methods struggled in this case.

What Should You Do If Your WHD Server Was Exposed?

The correct response depends on the server's historical exposure and the evidence available.

Scenario 1: WHD Is Current and Was Not Publicly Accessible

Confirm:

·         installed version;

·         security updates;

·         authentication configuration;

·         access controls;

·         logging and monitoring.

Continue normal vulnerability-management practices.

Scenario 2: WHD Was Internet-Facing During a Vulnerable Period

Do not stop after confirming that the server is patched today.

Establish:

1.      which WHD version was running during the exposure period;

2.      when public access existed;

3.      whether suspicious process activity occurred;

4.      whether remote-management or tunneling tools appeared;

5.      whether privileged credentials were used unexpectedly.

Scenario 3: Suspicious Post-Exploitation Activity Exists

If WHD launched unusual command interpreters, unauthorized remote-management tools appeared, unexplained tunnels were established, or privileged-account activity changed, treat the situation as a potential incident.

Evidence preservation and investigation matter more at this point than simply applying another patch.

Scenario 4: Compromise Is Confirmed

Investigate the wider environment for:

·         persistence;

·         credential exposure;

·         lateral movement;

·         privileged-account use;

·         domain-controller access;

·         unauthorized RMM software;

·         suspicious network connections.

Credential rotation may be necessary depending on which accounts or secrets were exposed.

Should SolarWinds Web Help Desk Be Internet-Facing?

Only when public access is genuinely required and the deployment is appropriately protected.

SolarWinds advises customers to protect WHD from unauthorized public access. Where internet-facing access is unnecessary, organizations should avoid exposing the server publicly.

That does not mean every internet-facing WHD deployment is automatically insecure. It means public exposure should be an intentional, managed risk rather than a default configuration.

Organizations should know:

·         why WHD must be externally accessible;

·         who owns the service;

·         which networks it can reach;

·         how critical updates are prioritized;

·         what monitoring exists;

·         what happens if the server is compromised.

For organizations that want controlled validation of externally reachable applications and infrastructure, Hoplon Penetration Testing can help identify exploitable weaknesses and demonstrate how exposed systems may affect connected assets.

Is WHD 2026.1 Still the Current Version?

No.

WHD 2026.1 remains important because it addressed CVE-2025-40551, CVE-2025-40536, and other vulnerabilities disclosed in January 2026.

However, SolarWinds later released WHD 2026.2.1. Organizations should therefore check the vendor's current WHD 2026.2.1 release notes rather than treating 2026.1 as the final upgrade target.

The newer release also addresses later vulnerabilities, including CVE-2026-28323.

Those newer security issues should not be presented as proven components of the December 2025 exploitation activity. The evidence reviewed for this article does not establish such a connection.

Is This the Same as the 2020 SolarWinds Orion Attack?

No.

The WHD exploitation discussed here concerns SolarWinds Web Help Desk, vulnerabilities affecting internet-accessible installations, and attacks observed in late 2025 and reported during 2026.

The widely known 2020 SolarWinds incident involved the Orion software supply chain and the SUNBURST backdoor.

They share the SolarWinds name but involve different products, attack mechanisms, timelines, and security events.

What This Incident Teaches About Internet-Facing Management Tools

The WHD attacks show why public-facing administrative systems require more than routine patching.

First, an application compromise can become an identity compromise. Microsoft's investigation progressed from WHD access toward credentials and Active Directory activity.

Second, trusted tools can be abused. PowerShell, RMM software, SSH, RDP, virtualization, and other legitimate technologies can become part of an attack chain when operated without authorization.

Third, patching and incident response solve different problems. A patch closes a known software weakness. It does not prove that an attacker who gained access before the update has been removed.

Finally, internet exposure should be intentional. Organizations should maintain an accurate inventory of public-facing systems and understand why each service must remain externally reachable.

SolarWinds WHD Response Checklist

If your organization operates SolarWinds Web Help Desk:

1.      Confirm the WHD version currently installed.

2.      Determine which version was running during the relevant exposure period.

3.      Follow SolarWinds' current supported upgrade and hotfix guidance.

4.      Determine whether public access is actually required.

5.      Review WHD and endpoint telemetry for unexpected command execution.

6.      Investigate newly installed RMM, tunneling, SSH, RDP, or virtualization components.

7.      Review privileged and service-account activity.

8.      Hunt for credential-access and domain-replication anomalies.

9.      Preserve evidence before destructive cleanup when compromise is suspected.

10.  Escalate to incident response when available evidence cannot establish the scope of compromise.

Sources and Methodology

This article does not present original Hoplon exploitation research or claim that Hoplon investigated the incidents described by Microsoft.

Hoplon InfoSec reviewed current technical evidence and official guidance from:

·         Microsoft Defender Security Research

·         SolarWinds WHD 2026.1 Release Notes

·         SolarWinds WHD 2026.2.1 Release Notes

·         CISA Known Exploited Vulnerabilities Catalog

·         NIST NVD: CVE-2025-26399

The sources were compared to separate:

·         confirmed attack behavior;

·         vendor-documented vulnerabilities;

·         current product-version information;

·         known exploitation status;

·         unresolved questions about the initial-access vulnerability.

Where the available evidence does not establish a fact, this article does not present it as confirmed.

No vulnerability exploitation was performed for this article, and no original victim dataset was analyzed.

Final Takeaway

The SolarWinds Web Help Desk incident should not be reduced to a story about one critical CVE.

Microsoft confirmed that attackers compromised exposed WHD systems and then used techniques involving remote execution, legitimate administrative tools, persistence, credential access, and movement toward higher-value assets.

What Microsoft could not reliably establish was which specific WHD vulnerability supplied the initial foothold in its December 2025 cases.

For defenders, that uncertainty changes the response.

If a WHD server was vulnerable and internet-facing during the relevant period, confirming that it is patched today answers only one question. Organizations also need to determine whether unauthorized access happened before the patch and whether the attacker moved beyond the WHD host.

Where the available logs and security telemetry cannot answer those questions confidently, a structured incident investigation is the appropriate next step.