CVE-2021-27103 is a server-side request forgery (SSRF) vulnerability in Accellion FTA. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2021, which means attackers have used it in real attacks. Accellion FTA contains a server-side request forgery (SSRF) vulnerability exploited via a crafted POST request to wmProgressstat.html.
What this SSRF means in practice
Server-side request forgery matters because the vulnerable server is tricked into making requests on the attacker’s behalf. In an internet-facing file transfer appliance, that can turn a single web request into access to internal services, metadata endpoints, or other trusted network locations that were never meant to be directly reachable.
For practitioners, the danger is not just that the application accepts an unexpected URL, but that it executes that request from a privileged network position. That is why SSRF is often used as an initial foothold for reconnaissance, trust boundary abuse, and follow-on exploitation inside segmented environments.
Why Accellion FTA was a high-value target
Accellion FTA was a file transfer platform, so it often sat at the boundary between external users and sensitive internal workflows. A flaw in that layer is especially consequential because file transfer systems frequently handle confidential documents, authenticated workflows, and integrations that assume the appliance is trustworthy.
The supplied definition notes exploitation through a crafted POST request to wmProgressstat.html, which shows how a seemingly narrow request-handling weakness can become a practical attack path. Web application attacks such as SSRF remain dangerous precisely because they abuse normal application behaviour rather than crashing the service outright.
How organisations assess exposure and exposure paths
Exposure review for an SSRF issue starts with asset inventory and service mapping. Organisations need to know where Accellion FTA is deployed, whether it is reachable from untrusted networks, and what internal systems it can contact from its own network segment or cloud placement.
Vendor advisories and vulnerability intelligence are also central because the practical remediation question is usually version- and deployment-specific. CISA’s Known Exploited Vulnerabilities catalogue and the official vulnerability record help establish whether the issue is actively exploited and how urgently it should be prioritised. See CVE Program for the canonical identifier record and NIST National Vulnerability Database for structured vulnerability reference data.
Vulnerability management should then determine whether the appliance is still reachable, whether compensating controls are in place, and whether the exposed service can reach sensitive internal targets such as metadata services, admin APIs, or backend storage.
Remediation, detection, and identity impact
Remediation should focus first on the vendor’s documented fix path and then on constraining the appliance’s outbound reach until patching is complete. Where immediate patching is not possible, restrict egress, segment the appliance, and block access to internal-only endpoints that SSRF commonly targets.
Detection should look for unusual outbound requests from the appliance, unexpected internal probing, and signs that the server fetched resources it normally never contacts. If exploitation is suspected, review logs for follow-on access to sensitive systems and treat the appliance as a potential bridge into the internal environment.
If the exploit led to downstream compromise, rotate any credentials, session material, or service account secrets the appliance could have exposed or used to pivot. In file transfer environments, the identity impact can matter as much as the vulnerable request itself because one exploited server may reveal many trusted connections.
Risk and Threat Considerations
SSRF is dangerous here because it can bypass the normal trust boundary around a managed file transfer server and turn that system into an internal proxy for an attacker. In a product like Accellion FTA, the most serious concern is not just data exposure, but the ability to reach internal-only services that assume requests originate from trusted infrastructure.
Failure mechanism: The attacker supplies input that the server uses to generate an outbound request, then steers that request toward an internal host, metadata service, or privileged local endpoint. Once that request path exists, the attacker may gain information, reach restricted services, or chain the flaw into broader compromise.
Impact: The result can include internal reconnaissance, credential or token exposure, lateral movement, and access to sensitive files or downstream systems that trusted the appliance’s network position.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | SSRF exploits boundary trust by forcing internal outbound requests. |
| SI-4 — System Monitoring | SSRF requires detecting unusual requests and follow-on probing from the appliance. | |
| Recommendation — Restrict the server’s outbound paths and isolate internal-only services. Monitor appliance egress and alert on unexpected internal request patterns. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Network segmentation and exposure control reduce SSRF blast radius on internet-facing systems. |
| Recommendation — Segment the appliance and limit its reach to only required internal destinations. | ||
| OWASP ASVS | V4 — API and Web Service | SSRF is a web-service request handling weakness that belongs in API and service security review. |
| Recommendation — Validate server-side URL handling and block untrusted request destinations. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | This CVE is an exploited public-facing application weakness used to gain initial access. |
| Recommendation — Map exposed appliance behaviour to initial-access hunting and attack-path analysis. | ||
Practitioner Guidance
Why practitioners should care: Treat SSRF in file transfer appliances as a boundary-control failure, not just an application bug. The key governance question is whether the system is allowed to reach anything more trusted than the application truly needs.
What to watch for: Pay close attention to outbound traffic patterns, especially requests that appear to target internal ranges, cloud metadata services, or administrative interfaces. Those patterns often reveal whether the vulnerable server is being used as an access bridge rather than a simple web endpoint.
Practitioner takeaway: The fastest way to reduce SSRF blast radius is to limit what the server can reach, then verify whether exploitation already occurred before assuming patching alone is enough.
Related resources from NHI Mgmt Group
- CVE-2021-22175 (GitLab Server-Side Request Forgery (SSRF))
- CVE-2021-39935 (GitLab Community and Enterprise Editions Server-Side Request Forgery (SSRF))
- CVE-2021-21973 (VMware vCenter Server and Cloud Foundation Server Side Request Forgery (SSRF))
- CVE-2021-40438 (Apache HTTP Server-Side Request Forgery (SSRF))