Is CVE-2021-27103 (Accellion FTA Server-Side Request Forgery (SSRF)) being exploited in the wild?

Yes. CISA added CVE-2021-27103 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Accellion FTA contains a server-side request forgery (SSRF) vulnerability exploited via a crafted POST request to wmProgressstat.html.

What “exploited in the wild” means for CVE-2021-27103

For this CVE, the practical question is not whether the flaw exists, but whether defenders should treat it as an active exposure. CISA’s KEV inclusion means the vulnerability has passed a higher bar than a theoretical or lab-only issue, so exposure should be assumed urgent until inventory, mitigation and compromise checks are complete. If your environment still contains Accellion FTA, treat it as a priority asset.

The right first step is to confirm whether any internet-facing or internally reachable FTA instance is present, including legacy or forgotten deployments. That matters because SSRF issues are often exploitable without direct user interaction, and a crafted request can be enough to trigger the vulnerable code path. Keep the focus on reachability, version lineage and whether compensating controls actually block the relevant request path.

Why SSRF flaws in file transfer platforms are high impact

SSRF is dangerous in a file transfer product because the server can be induced to make requests on the attacker’s behalf. That can turn a perimeter-facing application into a pivot point for internal access, metadata retrieval or other unintended outbound requests. SSRF prevention guidance is especially relevant here because the same control themes, URL validation, outbound filtering and metadata-service protection, are the main ways teams limit blast radius.

In this case, the exploit path described by the direct answer matters more than the label alone: a crafted POST request to a vulnerable endpoint is enough to trigger the behaviour. That means attackers do not need a long chain of prerequisites once the service is exposed, and defenders should think in terms of request handling, egress control and what internal systems the server can contact once the flaw is reached. SSRF abuse in a real-world breach is a reminder that request-forging flaws can become access problems, not just application bugs.

What defenders should check, patch and verify next

Use the vendor advisory and CISA KEV catalogue for authoritative remediation details, then verify three things: whether the product is present, whether the vulnerable attack surface is exposed, and whether the environment shows signs of earlier compromise. For a legacy file transfer platform, the compromise question is often as important as the patch question because exploitation may have occurred before the system was isolated, replaced or retired.

Where patching or removal is delayed, reduce exposure by blocking the vulnerable interface from untrusted networks, tightening egress so the server cannot freely reach internal or metadata targets, and monitoring for unusual POST requests or outbound request patterns. If the system handled sensitive files, also review whether any credentials, tokens or internal connection details may have been exposed through the vulnerable flow and rotate them if there is any credible chance they were touched.

Risk and Threat Considerations

Active exploitation changes the decision threshold. Once a vulnerability is in KEV, the main risk is no longer future possibility, it is ongoing exploitation against exposed systems, often before normal maintenance cycles can catch up. That is especially serious for a file transfer platform because the service is already positioned at a trust boundary and may have access to sensitive internal resources.

Failure mechanism: The SSRF condition lets a remote requester influence server-side network activity through a crafted request, which can bypass normal user-facing controls and reach internal destinations the attacker cannot access directly.

Impact: The result can include internal reconnaissance, access to sensitive internal services, downstream credential exposure or a broader foothold if the platform can reach privileged resources.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, 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 CSF 2.0	ID.RA-01 — Asset Vulnerabilities Identified and Recorded	Tracks known vulnerable assets like exposed Accellion FTA.
	PR.DS-04 — Information is Protected from Unauthorized Exfiltration	SSRF can enable unintended data access or exfiltration paths.
	DE.CM-01 — Networks and Network Services Are Monitored	Suspicious SSRF exploitation is detected through network and request monitoring.
Recommendation — Inventory any Accellion FTA exposure and record it as a known vulnerable asset. Restrict outbound paths so the server cannot exfiltrate or reach sensitive internal targets. Monitor request and egress patterns for signs of SSRF exploitation.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Active exploitation requires rapid identification and triage of vulnerable systems.
	SI-4 — System Monitoring	SSRF abuse is often detected through anomalous request and network activity.
	SC-7 — Boundary Protection	SSRF risk is reduced by controlling inbound reachability and outbound destinations.
Recommendation — Scan for exposed Accellion FTA instances and verify remediation status quickly. Monitor for anomalous server-side requests and unexpected outbound connections. Constrain reachability and outbound connections around the vulnerable service.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Known exploited CVEs require rapid identification and remediation.
Recommendation — Prioritise and remediate KEV-listed Accellion FTA exposure immediately.
OWASP ASVS	V4 — API and Web Service	SSRF is a server-side web/service request-handling flaw.
	V8 — Authorization	If SSRF reaches internal systems, authorization boundaries are at risk.
	V13 — Configuration	Secure configuration limits dangerous request destinations and egress.
Recommendation — Validate server-side request handling and outbound destination restrictions. Ensure internal resources are not reachable through unauthorised server-side requests. Harden configuration to block unsafe outbound requests and internal reachability.

Practitioner Guidance

What to verify: Confirm whether any Accellion FTA instance still exists, whether it is externally reachable, and whether you have evidence of suspicious requests or outbound behaviour around the exposure window. If you only check patch state and not logs or network telemetry, you may miss prior compromise.

Decision rule: If the system processed sensitive transfers while exposed, treat containment and compromise assessment as part of the fix, not a separate task. If it cannot be confidently remediated, isolate it and plan for retirement rather than extending its exposure window.

Practitioner takeaway: For a KEV-listed SSRF issue, the meaningful question is not just “is it patched?” but “was it reachable long enough to be abused, and what internal trust did it expose?”