The fix description names the input, not the parser
The release notes for Serv-U 15.5.4 Hotfix 1 describe the change in one sentence: "An attacker can no longer crash the Serv-U service by sending a simple request to the server with Content-Encoding: deflate and some data."
The sentence is precise about what it says, and about what it omits. The fix prevents the crash. The fix changes how Serv-U responds to a class of input. The fix does not say the decoder no longer crashes on that input. It says Serv-U no longer hands the input to whatever crashes.
The files the hotfix replaces are Serv-U.exe, Serv-U.dll, and RhinoNET.dll. RhinoNET is the SolarWinds HTTP layer. The patch lives in the layer that decides what to do with the body. It is not, by the file list, a replacement of any standalone decompression library.
The workaround is the same patch, in a different layer
SolarWinds' documented mitigation for customers who cannot install the hotfix is to configure an upstream load balancer, reverse proxy, or WAF to drop or strip the Content-Encoding: deflate header on inbound POSTs before the request reaches Serv-U. The same configuration works on nginx, F5, Citrix ADC, Azure Application Gateway, or any product that can match a request header and either reject or rewrite the request. The intervention is the same in every case: never let Content-Encoding: deflate reach Serv-U's HTTP listener.
Tod Beardsley, VP of Security Research at runZero, wrote about the mitigation guidance the day after the CVE published:
w/r/t CVE-2026-28318 - I kinda like the mitigation guidance of "well just block HTTP clients from sending Content-encoding: deflate on POSTs and you're good." Which sounded crazy to me at first, but is it? I know POSTs can be compressed, but I'd expect clients to use gzip pretty much exclusively. The history of deflate is fraught with compatability issues.
Beardsley's observation reads as a defense of the mitigation. It is also a description of the bug. In production HTTP, almost nothing legitimately sends Content-Encoding: deflate on a POST. Browsers do not. Most application clients do not compress request bodies at all; the ones that do use gzip. The deflate codec has been ambiguous in HTTP since 1999, when implementations disagreed on whether deflate meant raw deflate (RFC 1951) or zlib-wrapped deflate (RFC 1950). Microsoft IIS, Mozilla Firefox, and Apache historically shipped different choices, and production deployments converged on gzip because deflate could not be relied on to round-trip across them.
In a production Serv-U deployment, an inbound POST with Content-Encoding: deflate is by default suspicious. The mitigation tells customers to act on that defaultness: refuse the header, drop the body, never call the decompressor. The mitigation is enforceable at the proxy because legitimate clients never send the header in the first place. The mitigation is necessary at all because the decompressor, when called, crashes.
CISA added it to KEV the day after the CVE published
The CVE record was published 2026-06-04. CISA added CVE-2026-28318 to the Known Exploited Vulnerabilities catalog the next day with a federal patch deadline of 2026-06-19, under Binding Operational Directive 22-01. Federal civilian agencies have fourteen days to install the hotfix or apply the workaround.
CISA does not add to KEV on severity alone. The catalog's inclusion criterion is evidence of active in-the-wild exploitation. A pre-authentication denial-of-service bug being added to KEV is unusual, because DoS bugs do not typically destroy enough data to justify a federal patch directive. The exception is when the DoS is being used at scale against products whose availability is the asset.
Serv-U's job is to be available. Customers run Serv-U because they have batch file transfers that have to land on schedule: settlement files for clearing houses, claims files for healthcare counterparties, EDI files for procurement, scheduled drops from contractors. A Serv-U service that crashes is a missed transfer window. A Serv-U service that crashes on attacker command is a missed transfer window scheduled by the attacker. The federal deadline treats CVE-2026-28318 as evidence that the second case has been observed.
The crash class names the decoder as the asset
NVD classifies CVE-2026-28318 as CWE-400, Uncontrolled Resource Consumption. The category covers three common decoder failure modes against compressed input: decompression bombs, where a small compressed input expands into an output large enough to exhaust memory; pathological inputs that drive the parser into an unbounded loop on malformed framing; and integer overflow on length fields that allocates more memory than the host has, then writes to it. The CVE description's phrase, "a simple request... with Content-Encoding: deflate and some data," is consistent with the first two. A few hundred bytes on the wire is enough.
Bugs of this shape against HTTP servers' compression layers recur on a measured cadence. The deflate codec and its surrounding utilities have produced CWE-400 and CWE-122 findings in zlib's inflate routines, in nghttp2's HPACK header decoder, and in the MiniZip archive code zlib ships in contrib/. Each one took the same shape: a server-side decoder running on attacker-controlled bytes ahead of any authentication check. The decoder layer is where this class of bug arrives. The vendor that ships an HTTP server is the vendor who will, eventually, ship a member of the class.
The class of bug is the asset. The decoder that fails on attacker input was always going to be the target; the question for any given product is which decoder, in which release, takes which form of malformed input. SolarWinds' answer in June 2026 is RhinoNET.dll, on Content-Encoding: deflate, on inbound POST bodies, on a managed file transfer service running on the public internet.
Serv-U is on this catalog because Serv-U has been on this catalog
CVE-2026-28318 is not Serv-U's first KEV entry. CVE-2024-28995, a Serv-U directory-traversal bug, landed on KEV in June 2024 after exploit code from Rapid7 was picked up by ransomware operators including Lace Tempest, the Cl0p affiliate that ran the MOVEit campaigns. Three months before this CVE, in February 2026, SolarWinds patched four critical pre-authentication remote code execution bugs in Serv-U 15.5: CVE-2025-40538, CVE-2025-40539, CVE-2025-40540, and CVE-2025-40541. Each was rated CVSS 9.1. Each allowed root code execution on Linux or SYSTEM on Windows. The February patch and the June patch are in adjacent areas of Serv-U's HTTP request handling.
Serv-U is the recurring case. The category around Serv-U is named on this site as MFT as Primary Target. Managed file transfer products sit on the public internet by design, authenticate to internal systems with durable service accounts, and carry the files customers pay money to move. Attackers picked the category in 2023 and have stayed with it through MOVEit, Cleo, GoAnywhere, CrushFTP, and Progress WS_FTP. Serv-U joins the list by the same logic. The product-level explanation is Design Debt Driver: a long-running codebase with HTTP, FTP, and SCP layered onto an architecture older than the threat model that now applies to it. The disclosure dynamic, with the CVE landing on KEV the day after publication, is Disclosure After Exploitation: the vendor's advisory catching up to a thing the attackers found and used first.
Customers running Serv-U as part of their MFT stack have, by 2026, paid for what an earlier nefariousplan editorial called a vulnerability subscription. The subscription's billing cycle for Serv-U is measured in months. CVE-2026-28318 is this month's invoice.
The mitigation is the patch's confession
The hotfix and the workaround do the same thing in different layers. The hotfix changes Serv-U.exe, Serv-U.dll, and RhinoNET.dll so that the request that crashed Serv-U no longer reaches whatever crashed. The workaround changes the customer's reverse proxy so that the same request never reaches Serv-U at all. The boundary the two interventions enforce is the same boundary: the deflate stream does not get to the decoder.
The decoder is in RhinoNET.dll. The decoder is still in RhinoNET.dll after the hotfix. The hotfix replaces the file, but the fix description does not claim the decoder no longer crashes, only that the service no longer routes the input to it. The decoder is what the workaround keeps offline at the proxy. The decoder is what neither intervention vouches for.
The patch is in the dispatcher, not in the decoder; the workaround is in the proxy, not in the decoder; the decoder remains.
The decoder was for a code path SolarWinds' customers do not use. RFC 9110 §8.4 permits Content-Encoding on requests, and Serv-U implemented it because the RFC permits it. Production HTTP converged on gzip for the rare cases where request bodies are compressed at all, and deflate specifically has been the codec everyone agrees not to rely on. The decoder accepted attacker input pre-auth, on the public-internet attack surface of a managed file transfer product, until in-the-wild exploitation prompted a fourteen-day federal patch directive. The hotfix kept the input out of the decoder's dispatch path. The workaround kept the input off the wire. The decoder kept its place in the binary, where it has been since whichever Serv-U release first added the deflate branch to the HTTP layer.
PoC commentary: @todb on infosec.exchange
SolarWinds did not fix the decoder. SolarWinds taught the rest of the stack to refuse to call it.