CVE-2021-27102 is an OS command injection 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 an OS command injection vulnerability exploited via a local web service call.
What this vulnerability means in practice
CVE-2021-27102 is dangerous because OS command injection turns a web-facing flaw into potential operating-system level execution. In products like Accellion FTA, that matters because a small input-handling weakness can become a full compromise path when the vulnerable service can invoke shell commands.
The important security idea is not just “input was unsanitised”, but that the application trusted data enough to pass it into a command context. That crosses a boundary from application logic into system-level execution, which is why command injection is consistently treated as a high-impact web application risk. For a broader catalogue of common web injection patterns, see the Web Application Attacks Guide and the OWASP Top 10.
Why exposure assessment matters
With a KEV-listed vulnerability, organisations should assume exposure is not theoretical. The practical question becomes whether any asset still runs the vulnerable product, whether it is reachable from untrusted networks, and whether compensating controls around the affected service are actually in place.
Because the exploit path is tied to a specific product and service behaviour, asset inventory and external exposure checks are essential. The safest authoritative starting points are the vendor advisory for product-specific remediation and the NIST National Vulnerability Database and CVE Program for canonical record information.
Remediation and compensating controls
When a patch or upgrade cannot be applied immediately, the priority is to reduce exploitability, not to rely on detection alone. That usually means limiting access to the vulnerable web service, removing unnecessary reachability, tightening segmentation, and disabling or constraining any function that can influence command execution paths.
For this kind of issue, remediation should be paired with broader vulnerability management discipline: confirm scope, prioritise based on exploitable exposure, and verify that the fix actually removed the vulnerable condition. The Vulnerability Management Guide is useful here because it emphasises scope, prioritisation, verification and exception handling rather than treating patching as a one-time event. Where network controls are needed, NIST Cybersecurity Framework 2.0 supports the broader identify-protect-detect-response loop around exposed systems.
Detection and post-exploitation review
Command injection often leaves operational traces before or after compromise, such as unusual process spawning, unexpected child commands, abnormal web-service behaviour, or file and configuration changes that do not match normal application activity. After patching, organisations should review for signs that the flaw was already abused before remediation.
That review should include authentication artefacts, service-account activity, and any suspicious outbound connections or persistence mechanisms created after initial execution. If the web service or surrounding platform can execute commands, then compromise review must assume the attacker may have moved beyond the original vulnerable input point. The State of NHI & AI Agent Breach Report 2026 is a useful reminder that credentialed access and lateral movement often follow initial exploitation, even when the first foothold looks like a simple application flaw.
Risk and Threat Considerations
This vulnerability is materially dangerous because OS command injection can convert application access into system execution, which expands the blast radius from a single request to host-level compromise. In internet-facing file-transfer or web-service products, that can expose stored data, credentials, and internal trust relationships very quickly.
Failure mechanism: The application passes attacker-controlled input into a command context, allowing shell metacharacters or crafted parameters to alter what the operating system executes.
Impact: Attackers may gain arbitrary command execution, steal data or secrets, alter files, establish persistence, and pivot into adjacent systems.
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 OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V1 — Encoding and Sanitization | Command injection is prevented by strict input handling and output encoding at the web boundary. |
| Recommendation — Validate and sanitise all command-influencing input before it reaches execution paths. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | This vulnerability exists because untrusted input reaches a command interpreter without adequate validation. |
| CM-7 — Least Functionality | Reducing exposed functions and services limits the attack surface for command injection exploitation. | |
| Recommendation — Enforce input validation on all parameters that can influence command execution. Disable unnecessary services and command-capable features on exposed systems. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The term is a real exploited CVE, so prioritisation, verification and remediation tracking materially apply. |
| Recommendation — Prioritise exploited vulnerabilities and verify remediation on all in-scope assets. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | OS command injection maps directly to adversary use of system command interpreters. |
| Recommendation — Detect and investigate unexpected command interpreter activity spawned by exposed services. | ||
Practitioner Guidance
Why practitioners should care: KEV inclusion means this is not a hypothetical weakness, it is an exploited issue that warrants priority handling based on actual exposure. Treat the vulnerable product as high priority wherever it is still deployed or internet-reachable.
What to watch for: Review web-service logs, command-line telemetry, process creation patterns, and any unexpected changes made by the application runtime after the suspected exposure window. If you find evidence of abuse, rotate affected credentials and investigate whether the compromise reached beyond the original host.