Restricting Serv-U access before patching
The SolarWinds Serv-U flaw can crash the service with a crafted remote request, so exposed servers are the thing to worry about first. Once the service starts dropping over, incident response gets dragged into a mess that should have been boring. The sensible move is to cut off the easy path while the patched build is going on.
Block the obvious exposure path first
POST requests carrying a Content-Encoding header are the trigger to care about here, and that makes edge filtering a practical stopgap. Dropping those requests before they reach Serv-U removes the most direct crash path, which is a lot cheaper than discovering the same failure through a dead file transfer service at 02:00.
Drop POST requests with Content-Encoding at the edge
Put the block as far out as you can. A proxy, reverse proxy, firewall rule, or web application gateway can reject the pattern before Serv-U has to parse it. That matters because the flaw is unauthenticated and remote, so there is no login to lock down and no user session to revoke.
This is a narrow control, not a cure. It buys time for patching, and not much else.
Limit Serv-U to known source addresses while patching is pending
If Serv-U must stay reachable, restrict access to known source addresses while the patch is pending. That can mean an allow list for office IPs, VPN ranges, partner links, or whatever actually needs the service.
Internet-exposed Serv-U servers are the obvious target. If the service does not need broad access, broad access should not be there. The smaller the edge, the less chance an attacker gets to hammer the box into a crash loop.
Keep the service standing until the patched build lands
SolarWinds fixed the issue in Serv-U 15.5.4 Hotfix 1. Until that is in place, the main job is keeping the service alive long enough to patch without turning the fix into a rescue operation.
Watch for crash loops and repeated remote hits
Repeated POSTs with Content-Encoding: deflate are a useful sign that someone is poking at the flaw. If Serv-U starts crashing and restarting, treat that as active exploitation or at least a very poor sign.
Log review should focus on the sequence, not just the individual request. A single failed hit is noise. A burst of remote requests followed by service crashes is not. If you have process monitoring, service restarts, or Windows Event Log entries tied to Serv-U, keep them under watch until the patch is in place.
CISA added the issue to its Known Exploited Vulnerabilities Catalog, so this is not a theoretical bug sitting in a lab somewhere. It has already been used in the wild, which is usually the point where complacency becomes expensive.
Verify the fix against the Serv-U FTP server and incident response notes
Patch Serv-U Managed File Transfer and the Serv-U FTP server to the fixed build, then check that the service comes back cleanly on the systems that matter. Serv-U runs across Windows and Linux, and it supports HTTP, HTTPS, FTP, FTPS, and SFTP, so the change should be checked in the actual service path you use, not in some tidy test box that behaves itself.
Incident response notes should carry the timeline, request pattern, and service behaviour before and after the patch. That record matters if the box was already hit, and it matters just as much if it was only exposed. A patched vulnerability is still worth verifying, because a service that restarts once and then quietly fails again is not patched in any useful sense.
