SolarWinds has released a third patch for essentially the same critical Java deserialization vulnerability in its Web Help Desk product. The original flaw was first patched in August 2024 with warnings from CISA that it had been exploited in the wild.
“This vulnerability is a patch bypass of CVE-2024-28988, which in turn is a patch bypass of CVE-2024-28986,” SolarWinds wrote in its new advisory, which tracks the latest issue as CVE-2025-26399.
While the three CVE IDs are different, they stem from the same bug: an unsafe Java deserialization issue in the AjaxProxy component that can lead to remote code execution without authentication. The flaw is rated with 9.8 out of 10 on the CVSS severity scale.
In programming, serialization is the process of converting data into a stream of bytes, usually to transmit it over the wire. Deserialization reverses that process and, like most data parsing operations, it can be a source of vulnerabilities.
Deserialization flaws most often impact Java applications, but apps written in other programming languages such as ASP.NET can also be affected. These vulnerabilities often result in arbitrary command execution, making them popular with attackers.
Only a few days after CVE-2024-28986 was patched in August 2024, CISA added it to its Known Exploited Vulnerabilities (KEV) catalog, though it’s not clear if the flaw was exploited as a zero-day before the patch was released.
In October 2024, SolarWinds released a new hotfix to address a bypass to its initial fix that was discovered by researchers working with Trend Micro’s Zero Day Initiative (ZDI) program. Almost a year later, researchers working with ZDI found a bypass to the bypass.
“Third time’s the charm?” asked Ryan Dewhurst, head of proactive threat intelligence at watchTowr. “The original bug was actively exploited in the wild, and while we’re not yet aware of active exploitation of this latest patch bypass, history suggests it’s only a matter of time.”
Patch bypasses are not necessarily rare, especially when dealing with flaws involving unsafe parsing of untrusted user input. That’s because many developers take a blacklist approach to fixing such flaws and will simply block the specific input used in the known proof-of-concept or weaponized exploit.
But that often doesn’t address the root of the problem, leaving other ways to evade the blacklist and reach the same vulnerable part of the code. It’s hard to say how often this happens because many developers will treat a patch bypass as a separate flaw and not disclose it as a bypass.
No Responses