Critical Flaws in SolarWinds Web Help Desk Allow Unauthenticated Attackers to Bypass Security and Execute Code

Product: SolarWinds Web Help Desk (WHD)

Affected versions: versions prior to 2026.1 (WHD installations not upgraded to 2026.1 are at risk)

Official patch / upgrade (vendor): https://thwack.solarwinds.com/discussion/151643/solarwinds-web-help-desk-2026-1-is-available

SolarWinds Web Help Desk — a web-based help‑desk and asset management product used by many IT teams — had a cluster of six vulnerabilities disclosed at once. Four of those are critical (CVSS 9.8) and can be triggered without logging in. Two of the critical ones allow an attacker to send specially-crafted data that the server deserializes and then runs — which can let an attacker run commands on the server as if they were sitting at the machine. Others either bypass authentication entirely or use hard-coded credentials.

If your WHD instance is reachable from the internet or sits on a network segment that untrusted users can reach, treat this as an emergency: upgrade to WHD 2026.1 or apply vendor guidance immediately.

Comparison table — at-a-glance

CVE name	CVE ID	CVSS v3.1	Severity	Exploitability (auth)	Exploit availability	Short description
Security control bypass	CVE-2025-40536	8.1	High	Unauthenticated	No public PoC known (vendor/industry aware)	Bypass of access controls to reach restricted functionality
Hard-coded credentials (“client”)	CVE-2025-40537	7.5	High	May be unauthenticated (uses built-in client account)	No public PoC known	Static/embedded credential allows access to admin functions
Untrusted deserialization → RCE	CVE-2025-40551	9.8	Critical	Unauthenticated	No widely-published PoC (research writeups exist)	Deserialization of attacker data allows command execution
Authentication bypass (actions/methods)	CVE-2025-40552	9.8	Critical	Unauthenticated	No public PoC known	Missing auth checks let attacker call protected methods
Untrusted deserialization → RCE	CVE-2025-40553	9.8	Critical	Unauthenticated	No widely-published PoC (research writeups exist)	Second deserialization path leading to RCE
Authentication bypass — Web Help Desk specific	CVE-2025-40554	9.8	Critical	Unauthenticated	No public PoC known	Allows invocation of internal WHD actions without auth

Detailed extraction by CVE

Note: the following is written to be direct, explainable to technical staff, and include practical detection and response guidance. If you need a one‑page exec summary, I can produce that from this report.

CVE-2025-40536 — Security control bypass (CVSS 8.1)

What it is / impact (plain): an attacker can reach functions in the application that should require special permissions. Think of it as finding a backdoor doorway to pages or APIs that should be fenced off.

How it can be exploited (example playbook): an attacker sends crafted HTTP requests to public endpoints that exercise authorization code paths; due to missing or weak validation, the server responds as if the request came from an authorized user.

Exploitability & availability: can be triggered without credentials (if the endpoint is reachable). At the time of writing, there is reporting by vendors and researchers; no reputable public exploit repository contains an easily reusable PoC, but the flaw is straightforward to weaponize by an experienced attacker.

How to detect:

Look for strange requests to admin-style URLs from unfamiliar IPs (HEADERS: missing or malformed session cookies, or repeated attempts to access /api/admin/, /jsonrpc/ or similar paths).
Watch for responses that return privileged resources (e.g., full user lists, admin pages) to unauthenticated clients.

Example detection payloads / indicators:

HTTP requests with Content-Type: application/json to endpoints like /jsonrpc / /api that return 200 OK with admin payloads.
Unusual GET/POSTs containing parameters that change user roles or return configuration objects.

Suggested detection rules (examples):

SIEM rule: flag any 200 responses for paths matching /admin or /api/admin where the source IP is external AND the request lacks a valid session cookie.
EDR/IDS signature: detect POST to /jsonrpc containing serialized Java objects or long base64 blobs (common when attackers attempt serialized payload delivery).

Log sources to monitor: web server access logs, application logs (WHD request logs), firewall logs, authentication logs.

Mitigation / fix: upgrade to WHD 2026.1 or apply vendor hotfix; restrict access to WHD from untrusted networks until patched.

CVE-2025-40537 — Hard-coded credentials (“client”) (CVSS 7.5)

What it is / impact: a built-in credential (an account named client) is embedded or predictable, allowing attackers to log into higher-privilege functions. Hard-coded credentials are a classic privilege escalation vector.

How it can be exploited: an attacker sends a login attempt with the known username (and possibly known default password); if the instance accepts it, the attacker gains access to management pages or APIs.

Exploitability & availability: if the product ships with a predictable credential and it’s exposed, exploitation is trivial. No widely-published PoC code is required — simple login attempts will succeed until credentials are rotated.

How to detect:

Unusual logins for the client username, especially from external sources.
Successful authentications where the originating IP is not in your normal admin range.

Detection rule example:

SIEM: alert on any successful login where username == "client" and source_ip NOT IN <trusted_admin_range>.

Log sources: authentication logs, application login logs, privileged action audit logs.

Mitigation / fix: rotate or disable the client account immediately, apply patches in 2026.1, and restrict admin console access through network controls.

CVE-2025-40551 — Untrusted data deserialization → RCE (CVSS 9.8)

What it is / impact: the application accepts serialized data from a client and deserializes it insecurely. If that data contains objects the application will instantiate, an attacker can craft serialized payloads to execute code when the server deserializes them — full RCE.

How it can be exploited (example chain):

Attacker crafts a malicious serialized payload (often using gadget chains available in Java libraries used by the application).
Attacker sends the payload in a POST to an endpoint that deserializes input (file upload, JSONRPC bridge, session cookie, etc.).
The server instantiates the malicious object and triggers code execution — which can spawn a shell, download ransomware, or create persistent access.

Exploitability & availability: remote, unauthenticated. Researchers have published writeups describing the vulnerable deserialization paths; public exploit code may appear quickly due to the high severity, but at the moment of writing there is no stable, widely-shared PoC repository (research blogs provide technical details).

How to detect:

Network indicators: large POST bodies containing base64 blobs, binary serialized Java objects, or suspicious Content-Type headers on unexpected endpoints.
Host indicators: unexpected process creation (e.g., cmd.exe, bash, netcat), suspicious child processes of the WHD Java process, new outgoing network connections to unknown hosts.
Application logs: exceptions thrown during object deserialization, stack traces referencing ObjectInputStream, readObject, or libraries known for gadget chains.

Example payload signs:

Base64 strings that decode to non-JSON content in fields expected to carry JSON.
Multipart uploads where a field contains .ser or Java object streams.

Detection rules:

Splunk: index=webhelpdesk sourcetype=access_logs method=POST | search body="*base64*" OR body="*rO0AB*" then alert on hits where user agent is not internal.
Elastic (example): event.dataset: "apache.access" AND http.request.body:*rO0AB* then create rule to investigate.
EDR: alert on Java process spawning cmd, powershell, sh, or on java writing suspicious files to disk.

Log sources: application logs, web server access logs, Java application stdout/stderr logs, EDR process creation logs, firewall egress logs.

Mitigation / fix: patch to WHD 2026.1. If patching is delayed, block access to vulnerable endpoints with WAF rules that reject suspicious payloads, and isolate WHD from public networks.

CVE-2025-40552 — Authentication bypass (CVSS 9.8)

What it is / impact: certain internal methods or actions can be invoked by unauthenticated requests because the authentication layer is bypassable.

How it can be exploited: an attacker sends crafted requests that manipulate parameters or headers to skip the authentication checks (for example, manipulating an internal flag, a referer header, or abuse of JSONRPC endpoints that do not verify session state).

Exploitability & availability: remote and unauthenticated. No public PoC widely available; however the vulnerability is straightforward to test, which means commodity exploit scripts could appear quickly.

How to detect:

Requests that produce state-changing responses (e.g., ticket creation, configuration changes) from source IPs without valid session cookies.
Unexpected API calls returning OK for actions normally limited to authenticated administrators.

Detection rules:

SIEM: alert on HTTP 200 responses to endpoints that change state when the session_id is missing or invalid.

Log sources: application logs, access logs, change/audit logs within WHD.

Mitigation / fix: upgrade to WHD 2026.1 and restrict access. Add WAF rules to block suspicious patterns and consider rate-limiting or IP allowlisting for admin endpoints.

CVE-2025-40553 — Untrusted data deserialization → RCE (CVSS 9.8)

What it is / impact: second deserialization path in the application leading to RCE. Two independent deserialization vulnerabilities increases the chances an attacker will find a working chain.

How it can be exploited: same general pattern as CVE-2025-40551 but via a different endpoint or data flow — e.g., file upload or JSONRPC channel.

Exploitability & availability: unauthenticated remote RCE. Researchers have described technical details but public, turnkey PoC was not widely published at time of advisory.

How this can realistically be exploited

A typical exploitation flow looks like this:

The attacker identifies an endpoint in WHD that accepts serialized input (for example, a JSON‑RPC interface, background task handler, or upload‑related function).
The attacker builds a malicious serialized Java object using known gadget chains present in common Java libraries bundled with the application.
The payload is sent in a POST request. The server deserializes it automatically.
During deserialization, the gadget chain triggers execution of system commands.

Once this happens, the attacker can:

Spawn a shell on the server
Download and execute malware
Create backdoor accounts
Pivot to other systems on the internal network

Practical exploitation characteristics

No login required
Single HTTP request may be sufficient
Works even if no valid session cookie is present
Does not rely on brute force or guessing

Indicators and payload characteristics

Attack payloads for deserialization vulnerabilities often have recognizable traits:

Long Base64‑encoded strings in POST bodies
Binary data sent where JSON or form data is expected
Serialized Java object stream headers (commonly starting with specific byte patterns)
Abnormally large request bodies to application endpoints

How to detect exploitation attempts

Network-level signs

POST requests to WHD endpoints containing unusually large or encoded payloads
Requests with Content-Type values that do not match the endpoint’s intended use

Host-level signs

The WHD Java process spawning command interpreters (cmd, powershell, bash, sh)
Unexpected outbound connections from the WHD server
Creation of new executable files in temporary or application directories

Application-level signs

Deserialization or class‑loading exceptions in logs
Stack traces referencing object input streams or reflection

Example detection rules (conceptual)

SIEM logic:

Alert when POST requests contain large Base64‑like strings and target WHD API endpoints
Alert when HTTP responses return 500 errors followed by successful requests from the same IP

EDR logic:

Flag child processes spawned by the Java runtime that are not part of normal WHD operations

Relevant log sources

Web server access logs (Apache / Nginx)
WHD application logs
Java runtime logs
EDR process creation logs
Firewall egress logs

CVE-2025-40554 — Authentication bypass in Web Help Desk

Certain internal Web Help Desk actions are exposed through endpoints that do not consistently enforce authentication checks. This allows attackers to call internal methods directly, as if they were a logged‑in user, even when they are not authenticated.

This is not a password issue — the application simply fails to confirm who the caller is before performing sensitive actions.

How this can realistically be exploited

A typical attacker workflow:

The attacker sends crafted HTTP requests directly to WHD internal action endpoints.
Because authentication validation is skipped or incomplete, the request is processed.
The attacker gains access to functionality such as configuration access, workflow execution, or privileged data retrieval.

This vulnerability is often used as a door opener — once inside, attackers can look for ways to escalate further or chain into RCE vulnerabilities.

Practical exploitation characteristics

No credentials required
Requests appear similar to legitimate internal traffic
Can be automated and scanned at scale

How to detect exploitation attempts

Network indicators

Requests to internal‑style WHD endpoints from external IP addresses
Requests lacking valid session cookies that still return successful responses

Application indicators

Audit logs showing administrative actions without a corresponding login event
Configuration or data changes with no recorded user session

Example detection rules (conceptual)

SIEM logic:

Alert on successful responses for sensitive endpoints when authentication tokens are missing
Correlate admin‑level actions with prior login events; alert when no login exists

WAF logic:

Block direct access to internal WHD action endpoints unless a valid session cookie is present

Relevant log sources

WHD authentication and audit logs
Web server access logs
Reverse proxy or WAF logs
Firewall logs

Immediate defensive actions

Upgrade WHD to version 2026.1 immediately.
Restrict WHD access to trusted networks only until patched.
Review logs for unauthenticated access to internal endpoints.
Hunt for suspicious Java child processes or outbound connections.
Assume potential compromise if the server was internet‑exposed.