Is CVE-2021-20022 (SonicWall Email Security Unrestricted Upload of File) being exploited in the wild?

Yes. CISA added CVE-2021-20022 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. SonicWall Email Security contains an unrestricted upload of file with dangerous type vulnerability that allows a post-authenticated attacker to upload a file to the remote host.

How CISA’s KEV listing changes the answer

The key point is not just that CVE-2021-20022 exists, but that CISA placed it in the Known Exploited Vulnerabilities catalog. That makes this an active-exploitation question, not a hypothetical weakness question. For SonicWall Email Security operators, the practical implication is that exposure must be treated as time-sensitive, with KEV status taking priority over routine vulnerability backlogs.

Because the flaw is an unrestricted file upload issue in an email security product, the first thing to verify is whether the appliance is actually exposed to untrusted upload paths and whether those paths are reachable by authenticated users who should not be able to introduce arbitrary files. Email gateways and security appliances often sit in privileged positions, so even a post-authenticated upload flaw can become a foothold for persistence or follow-on abuse.

What makes unrestricted upload dangerous on an email security appliance

Unrestricted upload flaws are dangerous because they can let an attacker place content on a server where the application later processes, serves, or executes it. In an email security platform, that can matter in several ways: a malicious file may be staged for later retrieval, used to alter application behavior, or become part of a larger compromise chain if the appliance also has broad trust relationships with mail flow, administrative functions, or internal infrastructure.

The risk is amplified when the vulnerable system is internet-facing or closely integrated with mail routing and incident-response workflows. Even when the initial access is post-authenticated, the security impact can extend beyond a single user session if the attacker can upload content that survives logouts, bypasses normal review, or is reachable through a predictable path. That is why file upload controls on security appliances deserve the same scrutiny as authentication and patch hygiene.

For broader guidance on the underlying weakness class, see the File Upload Security Guide, which covers validation, storage isolation, and malware scanning, and the Email Security Guide, which places upload handling in the context of email gateway architecture and remediation. Where patch and exposure decisions are being prioritised across multiple issues, the Zero-Day and Exploited Vulnerabilities Guide explains how KEV status should accelerate response.

What to check before and after remediation

Confirm whether any SonicWall Email Security instances are still running the vulnerable release and whether administrative or user-upload functions are enabled in a way that broadens exposure. If patching is delayed, inspect the appliance for unusual uploaded files, unexpected web content, recently changed configuration artifacts, and signs that the system has been used as a staging point rather than just a mail filter.

Also review whether the appliance has been used to relay credentials, tokens, or administrative sessions that could let an intruder move further once the upload flaw is abused. On a device that protects email and may have privileged network visibility, compromise assessment should include the surrounding environment, not only the appliance itself. If any uploaded content could have been executed or referenced by the application, treat credentials and active sessions as potentially exposed.

When operationally possible, preserve logs and file-system evidence before making disruptive changes so you can distinguish a patching event from signs of earlier compromise. That matters because KEV-listed vulnerabilities are often exploited quickly, and the presence of a fix alone does not answer whether the system has already been used.

Risk and Threat Considerations

This issue is materially risky because it combines an upload flaw with a security appliance that often has high trust and broad visibility into email traffic. That makes it attractive for attackers looking for persistence, staging, or a trusted foothold after initial access. CISA’s ransomware note also raises the stakes, because exploited perimeter appliances are frequently used in the early phase of intrusion chains.

Failure mechanism: A post-authenticated attacker abuses the upload path to place dangerous content on the appliance, then uses that foothold to persist, stage follow-on activity, or support lateral movement.

Impact: The result can include appliance compromise, exposure of email-security controls, broader network reach, and faster progression from a single vulnerability to ransomware-relevant intrusion activity.

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, OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Unpatched KEV-listed flaws require prompt remediation and exposure verification.
Recommendation — Prioritise SI-2 remediation for the vulnerable appliance and verify closure after patching.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes vulnerability prioritisation and remediation tracking central.
Recommendation — Track this KEV item under CIS-7 and accelerate remediation with exposure-based prioritisation.
OWASP ASVS	V5 — File Handling	The issue is an unrestricted upload weakness, which maps directly to file handling controls.
Recommendation — Apply V5 file-handling requirements to restrict file type, storage, and post-upload processing.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and documented	KEV-listed exploitation requires identifying vulnerable assets and documenting exposure.
Recommendation — Identify exposed instances and document the vulnerable appliance in your risk register.
MITRE ATT&CK	T1105 — Ingress Tool Transfer	Uploaded files can function as attacker-delivered payloads for staging and follow-on activity.
Recommendation — Hunt for suspicious inbound file staging and correlate it with post-authenticated access.

Practitioner Guidance

What to verify: Treat KEV listing as a response trigger, not just a prioritisation signal. Verify exposed instances, confirm the exact build against the vendor advisory, and check whether any uploaded files, admin actions, or unexplained configuration changes predate remediation.

Decision rule: If the appliance is internet-facing or supports privileged administrative workflows, prioritise emergency remediation and compromise assessment together. If patching must wait, isolate the system, restrict upload paths, and increase monitoring for abnormal file creation and mail-flow changes.

Practitioner takeaway: The main decision is whether the appliance is only vulnerable or already a likely intrusion point, because KEV status means exploitation is a live assumption until disproven.