CVE-2025-40551: Another Solarwinds Web Help Desk Deserialization Issue Jimi Sebree January 28, 2026 Attack Blogs , Attack Research TL;DR We discovered a handful of security issues in Solarwinds Web Help Desk. These issues include… … an unauthenticated remote-code execution vulnerability via deserialization. … static credentials that allow limited access to authenticated functionality. … a security protection bypass regarding protected site actions. These vulnerabilities are easily exploitable and enable unauthenticated attackers to achieve remote code execution on vulnerable Solarwinds Web Help Desk instances. Solarwinds has stated that these issues are patched in Web Help Desk version 2026.1, and we encourage all users to upgrade as soon as possible. Background SolarWinds Web Help Desk (WHD) is a help-desk and IT service management platform that provides ticketing, asset tracking, SLA management, and workflow automation for support teams. Its main purpose is to centralize and streamline IT support operations and is widely deployed across organizations of all sizes. Back in August of 2024, Solarwinds released an advisory for WHD in order to address CVE-2024-28986, a deserialization vulnerability stemming from the AjaxProxy functionality that could result in remote code execution. Within a few days, this vulnerability was added to CISA’s Known Exploited Vulnerabilities catalogue. A couple of months later, another advisory (CVE-2024-28988) was released stating that a bypass had been discovered in the previous patch. Then, in September 2025, yet another advisory (CVE-2025-26399) was released in order to cover yet another discovered patch bypass. Jump to present day, yet another advisory has been released to cover yet another bypass. Yo dawg, we heard you like patch bypasses… The following sections detail the exploit chain for the most recent issues, describe potential indicators of compromise, and detail the disclosure timeline. The Issues Static Creds (CVE-2025-40537) When WHD first initializes, a client account is created for demo purposes. This account is created with a username of client and a default password of client . While this account appears to be limited in its access rights in some production environments, we’ve come across cases where this account is still associated with the default tech account and allows anyone logging in with this “client” user account to switch to the administrator account. As an example, here’s a quick clip of “client” logging into our demo environment: Security Protection Bypass (CVE-2025-40536) WHD contains a handful of request filters, much the same as any other Java web app, designed to handle things such as validating authentication headers, routing requests for static resources, handling security features such as cross-site request forgery checks, etc. As it happens, the CSRF checks implemented in WHD contain a little something extra. When filtering requests destined for WebObjects (via “wo” in the request path), the “checkCsrfTokenWo()” function is invoked. This function not only validates that the CSRF token is valid, but also validates request query parameters against a whitelist. The whitelisting functionality above can be bypassed by including a bogus URI parameter with a value of “/ajax/”. This allows for access to certain restricted functionality. For example, the “wopage” parameter can be used to allow WebObject component pages to be loaded directly. Why is this important? Well, it all has to do with how WHD works behind the scenes. WHD utilizes Java WebObjects, an older and still unfortunately somewhat common Java web application framework. Without going into too much detail about the specifics of the WebObjects framework itself, the biggest features we care about in terms of exploiting the vulnerabilities discussed in this post are… … anything you see on any given web page is a component or part of a component. … components are only created and accessible when a valid session creates and calls upon them. … pretty much everything is stateful to some degree. Under normal circumstances, when a user visits the login page, a session is created for them with the only components instantiated being those associated with the login page itself. The current component will appear in the URL as a string of integers and periods (such as “helpdesk/WebObjects/Helpdesk.woa/wo/6.7”). Once the user logs in, other components will be created and their identifiers will be appended to the URL as being “nested” in this current session (e.g. “helpdesk/WebObjects/Helpdesk.woa/wo/6.7.43.0.0.0.2.1.1.0.1.4.17.5.0.1”), which makes any given URL somewhat unique and dynamic based on the components created for the current session. Long story short, this essentially means that in order to access any particular component, you first need to know all prior components that need to be accessed in order for the target component to get instantiated. As it turns out, some of the restricted query par...