Yes. CISA added CVE-2021-35247 to its Known Exploited Vulnerabilities catalogue on 21 January 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. SolarWinds Serv-U versions 15.2.5 and earlier contain an improper input validation vulnerability that allows attackers to build and send queries without sanitization.
What this CVE tells you about active exploitation
This is not a theoretical weakness to file away for later. CISA’s KEV listing means defenders should treat the issue as actively abused and prioritize exposure checks, containment, and remediation ahead of lower-confidence findings. For a vulnerability like this, the operational question is not whether exploitation is possible, but whether your environment is still reachable in the vulnerable state.
For practitioners, the useful first step is to confirm whether any internet-facing or partner-facing Serv-U instances remain in scope. If you do not know where Serv-U is deployed, asset inventory is already part of the problem, because you cannot assess exposure, compensating controls, or blast radius without a reliable list of instances.
For vulnerability triage and emergency response, use the Zero-Day and Exploited Vulnerabilities Guide to align your response to KEV-style prioritisation, verification, and post-patch checking.
Why improper input validation matters here
The flaw type matters because input validation failures tend to sit on the boundary between data handling and command logic. When an application builds queries from unsanitized input, the attacker is often trying to change how the backend interprets a request, not just corrupt a single record. That makes the issue especially relevant when the vulnerable service processes externally supplied data before authorization, logging, or backend execution paths.
In practice, this means defenders should think beyond simple patch status. If the service accepted malformed or attacker-controlled query content, the security questions become whether that input reached sensitive operations, whether logs or traces captured suspicious payloads, and whether exploitation attempts left indicators in web, application, or database telemetry.
If you need a deeper root-cause lens on this vulnerability class, the Secure Coding Guide and the CWE Top 25 Guide are the most relevant internal references for understanding how input validation defects become exploitable weaknesses.
For the authoritative product and record context, check the vendor advisory and the NIST National Vulnerability Database entry for the exact CVE record and associated metadata.
What to do if patching is delayed or compromise is uncertain
If remediation cannot happen immediately, treat the instance as exposed and reduce the attack surface before you do anything else. That usually means isolating the service, tightening network access, restricting administrative reach, and reviewing whether the affected deployment is reachable from the internet or from untrusted partner networks. If the service is business critical, the highest-value interim control is to reduce who can reach it and from where.
You should also check for earlier compromise, not just current vulnerability status. Review access logs, authentication events, process activity, and any unusual outbound connections around the window when exploitation may have occurred. When an exploited service can touch credentials, sessions, or adjacent systems, the response may need to include credential rotation and session invalidation in addition to the software fix.
Use the CISA Known Exploited Vulnerabilities Catalog to confirm the current remediation expectation and the FIRST EPSS service to help with broader prioritisation across your backlog.
Risk and Threat Considerations
Actively exploited server vulnerabilities tend to be used quickly, before organisations have finished inventory, patching, or maintenance windows. The main risk is not only initial compromise, but also follow-on access if the vulnerable service sits near sensitive data, privileged administrative functions, or trust relationships with other internal systems.
Failure mechanism: The attacker abuses unsafe query construction or malformed input handling to reach unintended backend behaviour, then uses that access to enumerate data, change application state, or establish a foothold for further activity. If the service is exposed externally, exploitation can begin with little or no prior access.
Impact: Successful exploitation can lead to data exposure, service disruption, and in some environments further lateral movement if the application has broad connectivity or sensitive credentials available to it. Even without confirmed ransomware linkage, the practical impact can be severe because the service may become an entry point into a wider environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | CVE response requires timely remediation of the vulnerable component. |
| RA-5 — Vulnerability Monitoring and Scanning | Exposure confirmation depends on finding all affected Serv-U instances. | |
| IR-4 — Incident Handling | Active exploitation requires validation, containment, and compromise assessment. | |
| Recommendation — Prioritise SI-2 to identify, remediate, and track the Serv-U flaw promptly. Use RA-5 to inventory, scan, and confirm where Serv-U is deployed and exposed. Apply IR-4 to investigate possible exploitation and contain impacted systems. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | Exploited CVEs require knowing which assets remain vulnerable. |
| PR.IP-12 — Vulnerability management plan is established and maintained | KEV-listed issues require an accelerated remediation process. | |
| Recommendation — Identify all affected Serv-U assets and document their exposure status. Maintain a vulnerability process that escalates KEV-listed flaws first. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed exploitation demands prioritised vulnerability management and verification. |
| Recommendation — Continuously scan, prioritise, and remediate the Serv-U vulnerability. | ||
Practitioner Guidance
What to verify: Confirm every Serv-U instance, its exposure path, and whether any compensating controls actually block untrusted access. Do not rely on a patch ticket alone if the system is externally reachable or if the inventory is incomplete.
Decision rule: If the vulnerable service is reachable from outside your trusted boundary, treat exposure as material until proven otherwise. If patching is delayed, prioritise isolation and access restriction over passive monitoring.
What practitioners underestimate: The hardest part is often not applying the fix, it is proving whether the service was already abused before remediation. Log review, credential hygiene, and follow-up validation matter because exploited infrastructure can remain a trust anchor after the original flaw is gone.
Practitioner takeaway: For KEV-listed flaws, the decision point is not “is there a patch?” but “can this system still be reached and abused right now?”
Related resources from NHI Mgmt Group
- CVE-2021-35247 (SolarWinds Serv-U Improper Input Validation)
- Is CVE-2021-25489 (Samsung Mobile Devices Improper Input Validation) being exploited in the wild?
- Is CVE-2021-38406 (Delta Electronics DOPSoft 2 Improper Input Validation) being exploited in the wild?
- Is CVE-2026-6973 (Ivanti Endpoint Manager Mobile (EPMM) Improper Input Validation) being exploited in the wild?