A Crash, Not a Shell: SolarWinds Serve-U CVE-2026-28318

TL;DR:

SolarWinds Serv-U 15.5.4 and earlier can be killed by a single unauthenticated request: a POST request carrying Content-Encoding: deflate and any body crashes the service. Underneath the crash is real heap corruption, the kind that sometimes turns a “denial of service” into remote code execution, so we spent the time to find out. The bottom line: it does not, on the builds we analyzed. We chased three separate roads to RCE and proved each one is a dead end, which means the honest impact is exactly what SolarWinds rated it, an availability-only DoS (CVSS 7.5). Patch to Serv-U 15.5.4 HF1, or if you cannot patch yet, block POST requests that carry a Content-Encoding header at your WAF. We are releasing a safe detection tool that flags vulnerable hosts without crashing them.

What's Broken

On June 3, 2026, SolarWinds published CVE-2026-28318, an unauthenticated denial-of-service affecting Serv-U, its widely deployed managed file transfer and FTP server. The vulnerability is reachable on the web interface that ships enabled by default, and it scores CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). A POST request with Content-Encoding: deflate feeds its body content into an in-memory decompressor whose buffer management performs an invalid free(), and the hardened system allocator responds by aborting the whole process. A body must be present, but it does not have to be valid compressed data.

Bishop Fox reverse engineered vulnerable and patched Serv-U builds to confirm the root cause, reproduce the crash, and prove the advisory’s assertion that it only causes a crash and can’t provide a viable initial access vector. We built a production-safe detection check that tells vulnerable hosts apart from patched ones without ever sending the input that triggers the crash. It’s available on GitHub at https://github.com/BishopFox/CVE-2026-28318-check.

Anatomy of the Crash

The advisory tells defenders the essentials: everything up to and including Serv-U 15.5.4 is affected, the fix is 15.5.4 HF1, and the trigger is Content-Encoding: deflate. SolarWinds also notes the functionality “is not required by the service,” which is a strong hint about how the bug was fixed.

The root cause is a safety check wired to the wrong condition. Serv-U’s web server is supposed to reject deflate encoding, but the check that does it only runs when HTTP compression is disabled. Compression is enabled by default, so on a normal install the check is skipped and the deflate-encoded body is handed straight to the decompressor. From there, a buffer-management bug frees a pointer it should not, the allocator detects the corruption, and Serv-U aborts. One unauthenticated request takes the service down, and it works every time.

Interestingly, the HF1 fix does not repair the decompressor at all. Instead, it adds a universal gate: any request that has a body and a non-empty Content-Encoding header is rejected with 415 Unsupported Media Type before the body is ever processed. That gate is what makes safe detection possible. Send a POST with a body and a harmless encoding such as identity, and a patched server answers 415 while a vulnerable server handles the request normally and stays up. Because the probe never sends deflate, it never reaches the decompressor and never risks the crash. That single behavioral difference is what our detection check keys on.

Chasing the Shell

This is the part that earned a closer look: the crash happens because the program corrupts its own memory, and memory corruption is sometimes the first rung on a ladder that ends in remote code execution. If an attacker can steer the damage precisely instead of just toppling the program, a denial of service becomes a break-in. This bug even hands over the ingredients you would want for that. The attacker controls which piece of memory the program throws away and the data sitting right next to it, which is the raw material exploits are built from. We took the time to attempt it, testing against a live server at every step along the way.

We went down three roads that normally lead to code execution, and every one hit a wall:

• Tricking the program into discarding memory at an address of our choosing. We got further than expected, slipping past the memory manager’s built-in safety check. But the shape of the request forced one of the key values to be larger than all the memory a program could ever use, so the only outcomes on offer were “do nothing” or “destroy everything.” There was no version we could actually aim.
• Faking a neighboring block of memory to corrupt the memory manager’s internal bookkeeping. This textbook follow-up failed for the same reason. The same impossibly large value pushed the calculation far outside valid memory before anything useful could happen.
• Exploiting a separate counting bug in the decompressor. It tracks sizes with a counter that is too small and silently rolls over once the data gets big enough. The flaw is real, but the amount of memory the program asks for and the amount it then copies are driven by the same broken counter, so they always go wrong together. The result is the program requesting an impossible amount of memory and giving up. That is just a slower, more resource-hungry way to reach the same crash.

Any one of these would usually be a promising lead, but here, quirks of the bug itself closed all three. We can’t prove conclusively that no viable attack path exists, but the obvious routes are genuinely dead. Our conclusion based on tested impact, therefore, is the one the vendor assigned: denial of service.

The Bottom Line

CVE-2026-28318 is a real, unauthenticated, single-request kill switch for an internet-facing file transfer service, and it deserves prompt patching. It is not, as far as our analysis goes, a route to remote code execution. The heap corruption is authentic but boxed in, so the right threat model is a reliable DoS, not a breach.

What defenders should do:

• Patch. Update to Serv-U 15.5.4 HF1 (build 15.5.4.125) or later. Everything at or below 15.5.4 is affected.
• If you cannot patch immediately, filter the trigger. Block POST requests that carry a Content-Encoding header at your WAF or reverse proxy; the feature is not needed by the service, and SolarWinds publishes ready-made rules for the common WAF vendors. Where you can, restrict the Serv-U web interface to trusted networks.
• Sweep for exposure. Run our safe detection check against any reachable Serv-U instance, including internal ones. It never sends the crashing input, so it is safe to run in production.

As usual, our Cosmos customers were notified about our research into this vulnerability shortly after the vendor advisory. If you are interested in learning more about managed services delivered through our Cosmos platform.

For more vulnerability intelligence insights, visit the Bishop Fox Blog.