SolarWinds Serv-U and Web Help Desk Hardening Guide: Patch, Restrict and Monitor Exposed Servers

SolarWinds Serv-U and Web Help Desk (WHD) are internet-facing by design, and attackers have repeatedly turned unpatched instances into a foothold on the internal network. Serv-U is a file transfer server for FTP, FTPS, SFTP and HTTPS; WHD is a ticketing and asset management application that often holds directory bind accounts and integration credentials. The CISA Known Exploited Vulnerabilities (KEV) catalogue lists four Serv-U entries and five WHD entries as of 27 October 2026, including a 2021 Serv-U SSH flaw used by a China based group and a 2024 WHD hardcoded credential. This guide covers how each product authenticates users and administrators, which accounts and keys need governing, what to log and hunt for, and a hardening baseline. It is for system owners, security engineers and responders. For the wider file transfer picture, see the Managed File Transfer (MFT) Security Guide; this page goes deeper on these two products only.

Key takeaways

• Patch speed is the main control. Every KEV entry for both products is fixed by a hotfix or new release, and several were exploitable without authentication, so a missed hotfix on an exposed server is the usual root cause.
• Serv-U administrators are just users with a privilege flag. The Administration Privilege field on a user account grants System, Domain or Group administrator rights, and attackers who exploited CVE-2021-35211 created a new global user to give themselves administrator access.
• WHD holds other systems' credentials. Directory, mail and integration accounts plus REST API keys stored in WHD become the attacker's after a WHD compromise, so plan to rotate them.
• Watch the service process, not just the logs. Microsoft's guidance for the 2021 Serv-U campaign was to alert on Serv-U.exe spawning cmd.exe, powershell.exe or mshta.exe; the same principle applies to the Java process behind WHD.
• Keep data and administration out of the DMZ. The Serv-U Gateway acts as a reverse proxy so the file server does not store data in the DMZ, and neither product's administration interface should be reachable from the internet.

How identity and access work in Serv-U and Web Help Desk

Serv-U

Serv-U organises everything into global (server) settings and one or more domains. Users and groups can be created at the global level or inside a domain, and settings flow down from server to domain to group to user. SolarWinds' documentation states that "Settings at the user level override all others", which means a single user record can silently weaken a server-wide control.

• Local users: stored by Serv-U, with a Login ID, password, home directory, directory access rules and optional SSH public key (MFT edition). The special IDs Anonymous and FTP need no password, and SolarWinds notes that a blank password lets anyone who knows the Login ID sign in.
• Windows Active Directory: limited to one Windows machine or domain per Serv-U domain. Serv-U impersonates each user, so NTFS permissions apply to their files.
• LDAP: can reach several directories (Active Directory, OpenLDAP and others) and suits Serv-U on Linux. NTFS permissions do not apply, so directory access rules must be defined in Serv-U.
• Multifactor authentication: a six-digit authenticator app code, set to Enabled or Enforced at global, domain, group or user level under Limits & Settings. SolarWinds documents it as available for web (HTTP) sessions, so FTP, FTPS and SFTP logins are not covered by it.

Web Help Desk

WHD has three kinds of account: admins and techs, who use the tech interface, and clients, who raise tickets. Authentication is chosen under Setup > General > Authentication.

Two WHD settings matter on every install. "Require Authentication on External Hyperlinks" stops anyone with a URL from opening linked content such as attachments and FAQs. The Password Security Migration Tool moves stored tech and client passwords to FIPS 140-2 cryptography, invalidating weaker hashes; techs who have not signed in before migration must recover their password, which needs the Web Help Desk method with the Forgot Password button enabled.

Admin roles and privileged access

In Serv-U, administrative rights are an attribute of an ordinary account, set in the Administration Privilege field.

• Remote administration equals console access: SolarWinds warns that a System Administrator signed in through HTTP remote administration can manage the server as if they had physical access. Restrict that listener with IP Access rules to an administration network and enforce MFA for web sessions.
• Avoid "Always allow login": it bypasses limits such as maximum sessions. SolarWinds suggests reserving it for critical administrator accounts; IP access rules still take precedence.
• Global users are the high value target: a global user exists across all domains. In the 2021 campaign the attacker added a global user, so review the Users tab at global level and the files in C:\ProgramData\RhinoSoft\Serv-U\Users\Global Users on a schedule.
• WHD admins and techs: limit the admin role to a small named group, move techs to SAML so the IdP enforces MFA, and keep "Show Forgot Password Button" off for the tech population once SSO works.
• Host administrators: whoever is a local administrator on the Windows or Linux host can read both products' configuration and stored credentials. Manage those logons through your Privileged Access Management Guide process.

Integrations, API tokens and service accounts

Both products depend on machine identities that are easy to forget because no person signs in with them.

• Directory bind accounts: Serv-U LDAP and WHD AD or LDAP connections each use a bind account. Give it read-only rights on the user OUs it needs, use Secure LDAP, and rotate it after any compromise of the server. See the LDAP Security Deep Dive Guide.
• WHD API keys: WHD's REST API accepts an application key or an individual tech's key. SolarWinds' own guidance is that application keys grant broad API access, that individual tech keys should be used where possible, that keys should only be sent over SSL, and that they should be exchanged for session keys. Record each key's owner and consumer in your inventory.
• Mail and integration accounts (own knowledge, check your version): WHD commonly holds mailbox credentials for email-to-ticket and connection details for asset discovery sources. Treat each as a service account with an owner and a rotation date.
• Serv-U SSH keys: SSH public keys are referenced by path, for example %HOME%\%USER%.pub. SolarWinds advises storing them in a secured directory. Partner and automation accounts that use keys should be non-interactive, locked in their home directory and set to expire or disable on a date where the relationship is time limited.
• Service accounts for the products themselves: run each service as a dedicated low privilege account rather than LocalSystem or root where the installer allows it (own knowledge: SolarWinds documents service account options per version). See the Windows Services and Service Account Security Guide.

The identity lesson from CVE-2024-28987 is direct: a credential hardcoded in WHD 12.8.3 HF1 and earlier let a remote, unauthenticated user reach internal functionality and change data. You cannot rotate a vendor's hardcoded secret yourself, which is why the hotfix, plus rotation of everything WHD stored, is the only complete fix. The Service Account Security Guide covers the inventory and rotation process.

Known exploited vulnerabilities and patching

All entries below are in the CISA KEV catalogue (cache checked 27 October 2026). Version details come from the SolarWinds advisories listed in the references.

1. Inventory: find every Serv-U and WHD instance, including trial installs and old DR copies, and record version, hotfix level, edition and exposure.
2. Subscribe: follow the SolarWinds Trust Center advisories and the KEV feed; KEV entries carry federal due dates that make a sensible internal deadline. See the CISA KEV Catalogue Guide.
3. Stage: Serv-U advisories note that older versions must be upgraded in sequence, so test the upgrade path on a clone first, with a configuration and user database backup to roll back to.
4. Reduce exposure while you wait: restrict access to the web interface with IP Access rules or a reverse proxy, and disable SSH on Serv-U if it is not used (for CVE-2021-35211 SolarWinds states the flaw does not exist when SSH is disabled).
5. Hunt, then trust: after patching an instance that was exposed and behind, run the hunt in the next section before returning it to service. The Emergency Out-of-Band Patching Playbook covers the process.

Logging and detection

Serv-U logging is set at server, domain and user level (which messages, log path and parameters), and the console shows a Server Log and Active Sessions. Forward host logs and EDR telemetry to the SIEM rather than relying on the product's own view.

Metrics:

• Days from SolarWinds advisory to hotfix on internet-facing instances (target: inside the KEV due date, ideally under 7 days).
• Percentage of Serv-U and WHD instances on the latest release.
• Number of System Administrator and global users, reviewed quarterly against a named list.
• Percentage of tech and web users with MFA enforced (SSO for WHD, Enforced for Serv-U web).
• Percentage of stored integration credentials and API keys with a named owner and a rotation date.

Hardening baseline

1. Placement: put Serv-U behind the Serv-U Gateway, which acts as a reverse proxy in the DMZ (default TCP 1180 between server and Gateway, which should use a private address), so the file server neither stores data in the DMZ nor accepts connections from it into the internal network. Publish WHD only through a reverse proxy or not at all, since most help desks serve internal staff.
2. Protocols: disable plain FTP and any listener you do not use, prefer SFTP or HTTPS, and keep SSH disabled on Serv-U unless SFTP is required.
3. Administration: named administrator accounts only, MFA Enforced at global level before any lower level is set to inherit (SolarWinds warns that the wrong order disables MFA for that level), and IP Access rules limiting administration to a management network.
4. Users: no blank passwords, no Anonymous or FTP accounts unless deliberately required, "Lock user in home directory" on, expiry dates on partner accounts, and password length and complexity set under limits.
5. WHD: SAML 2.0 for techs, password policy with lockout for any remaining native accounts, "Require Authentication on External Hyperlinks" on, tech session timeout enabled, individual tech API keys over SSL, and the Password Security Migration Tool run.
6. Host: dedicated service account, EDR on the host, outbound internet access blocked except update and mail endpoints, and backups of configuration taken before every upgrade.
7. Test and roll back: apply changes to a staging copy, test partner logins for each protocol, then production with a configuration backup; roll back by restoring the backup if partner transfers fail.

Small vs large estates: a small organisation with one Serv-U server and an internally used WHD gets most of the benefit from fast hotfixes, IP restriction of the admin interface and MFA. A large estate with many partners should add the Gateway, per-partner domains with Domain Administrators, file integrity monitoring and a quarterly access review.

Common misconfigurations

• Hotfix lag on an exposed server: the Serv-U and WHD KEV entries include unauthenticated flaws, so an instance one hotfix behind is effectively open.
• User level overrides: a single account with "Always allow login" or MFA disabled at user level, set during troubleshooting and never reverted, defeats the global policy.
• Header authentication with direct access: WHD set to HTTP Header authentication while the application port is still reachable lets anyone send the header themselves.
• Not rotating after a WHD compromise: patching closes the hole but the bind account, mail account and API keys the attacker could read stay valid.
• SSH left on by default: CVE-2021-35211 needed SSH enabled; many servers ran it with no SFTP users.
• Treating the file server as a supply chain blind spot: SolarWinds has been through a major supply chain compromise before (see SolarWinds Supply Chain Compromise); SolarWinds states CVE-2021-35211 is unrelated to SUNBURST, but both show why products from any vendor need monitoring rather than blanket trust.

Framework mapping

Practitioner checklist

• List every Serv-U and WHD instance with version, hotfix level and internet exposure.
• Apply the latest hotfix or release, checking each KEV CVE in the table above.
• Disable SSH and plain FTP on Serv-U where not needed; place file transfer behind the Gateway.
• Restrict both administration interfaces to a management network and enforce MFA (Serv-U web, SAML for WHD).
• Review System Administrator, global and WHD admin accounts against a named list.
• Inventory and rotate bind accounts, mail accounts and WHD API keys; prefer individual tech keys.
• Alert on the service processes spawning shells and on new global users.
• Hunt for the 2021 and later indicators on any instance that was exposed and behind on hotfixes.
• Back up configuration before each upgrade and test partner logins after it.

Standards and references

• SolarWinds: Serv-U Remote Code Execution Vulnerability (CVE-2021-35211)
• SolarWinds: Web Help Desk Hardcoded Credential Vulnerability (CVE-2024-28987)
• SolarWinds: Web Help Desk Deserialization Vulnerability (CVE-2025-40551)
• SolarWinds: Add a Serv-U user
• SolarWinds: The Serv-U Gateway
• SolarWinds: Web Help Desk Authentication Options
• Microsoft Threat Intelligence: Threat actor targeting SolarWinds Serv-U with 0-day exploit
• CISA: Known Exploited Vulnerabilities Catalog

Related NHI Mgmt Group resources: Managed File Transfer (MFT) Security Guide · MOVEit Transfer Hardening Guide · Insecure Deserialisation Guide · Web Shell Response Playbook · API Key Management Guide