SolarWinds Serv-U CVE-2026-28318: CISA KEV Added - Patch or Mitigate?

Thanks for the scripts. We run Serv-U on Linux for our legacy client transfers. I'm checking our versions using this simple bash command to ensure we aren't running an vulnerable build:

dpkg -l | grep -i serv-u


We are actually seeing some odd memory spikes on the box before it crashes. It looks like it might be a specific malformed packet triggering the overflow. Definitely blocking external access at the firewall until we can schedule maintenance.

It's worth noting that while it's a DoS, availability is a huge CIA triad concern for orgs moving financial data via FTP. A crash during end-of-day processing is a nightmare scenario.

I'd recommend checking your IDS/IPS for rules targeting SolarWinds Serv-U specifically. Snort/Suricata usually pick up on the anomaly patterns for these types of crashes fairly quickly. We updated our ruleset this morning and are already seeing noise from known scanner IPs.

Valid concern on the financial impact, Joe. Since Tom covered the Linux checks, Windows admins can verify their installed Serv-U build using this quick PowerShell snippet to ensure they are patched:

Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*" | Where-Object {$_.DisplayName -like "*Serv-U*"} | Select-Object DisplayName, DisplayVersion


If patching isn't immediate, I'd suggest restricting inbound traffic to known IPs on ports 21/22 as a temporary choke point to reduce the attack surface while the update is staged.

Great points on version checking. Since this is actively exploited, you should also audit your logs for the crash pattern to confirm if you're being targeted. If you have centralized logging, use this regex to catch the specific malformed requests triggering the service termination:

regex /Serv-U.[Pp]rocess.[Tt]erminated|[Ee]rror.*0x[a-fA-F0-9]{4,8}/

Catching the precursor traffic can help identify the source IP for blocking if immediate patching isn't feasible.

Solid checks, everyone. If you're stuck waiting for a change window, consider limiting exposure by restricting access to the Serv-U ports strictly to trusted subnets. This mitigates the external DoS vector while you schedule the patch.

For Linux admins enforcing this immediately, here’s a quick iptables command to lock down port 22 (SFTP):

iptables -A INPUT -p tcp --dport 22 -s  -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP


It's not a fix, but it buys time safely.

Good points on the impact. Since availability is the main risk here, if you can't patch immediately, ensure your Linux instances are configured to auto-recover. You can override the systemd configuration to automatically restart the service upon failure.

Run systemctl edit serv-u and add the following to minimize downtime while you wait for your change window:

ini [Service] Restart=on-failure RestartSec=10

Solid points everyone. To expand on Zara's note about auditing, rapid service restarts are a strong indicator of a successful DoS attempt. For those using Microsoft Sentinel, you can hunt for these patterns in your System logs using this KQL query to detect repeated Serv-U crashes:

Event
| where Source == "Service Control Manager" and EventID == 7031
| where RenderedDescription contains "Serv-U"
| summarize Count = count() by Computer, bin(TimeGenerated, 10m)
| where Count > 5

Expanding on network mitigation, layering rate-limiting rules at the perimeter can blunt the DoS impact before it hits the application. Even if you restrict subnets, a single compromised host could still flood the service.

For those using Linux firewalls, this iptables rule caps new connections on the default FTP port:

iptables -A INPUT -p tcp --dport 21 -m connlimit --connlimit-above 50 -j REJECT

This buys time for the change window without halting all operations.