How do you patch or mitigate CVE-2021-20028 (SonicWall Secure Remote Access (SRA) SQL Injection)?

CISA’s required action for CVE-2021-20028 is to the impacted product is end-of-life and should be disconnected if still in use. In practice, find every instance of SonicWall Secure Remote Access (SRA) in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service.

What this CVE means operationally for SonicWall SRA

CVE-2021-20028 is an SQL injection issue in SonicWall Secure Remote Access (SRA), so the immediate concern is not just a software flaw, but a remotely reachable path into a remote access appliance. Because the direct answer says the product is end-of-life, the practical decision is exposure management first: inventory it, confirm where it is still reachable, and stop treating it as a normal patch-and-forget asset.

If you still have SRA in production or in a staging path that can reach production data, Edge Device Security Guide is the right lens for the underlying control problem: internet-facing appliances need the same lifecycle discipline as any other exposed edge system, including management surface reduction and explicit end-of-life handling.

For this CVE, the vendor update or documented mitigation is only part of the response. If the device cannot be brought to a supported, defensible state, removal from service is the safer outcome than leaving an exposed remote access path in place.

How to confirm exposure and apply the fix

Start by locating every SonicWall SRA instance, not just the ones the network team remembers. The common failure mode here is shadow exposure: an appliance remains reachable through a forgotten DNS entry, an old VPN profile, a partner route, or a management interface that was never fully removed from the internet.

Once found, verify whether the instance is on the current vendor-supported path, whether the applicable update or mitigation has actually been applied, and whether the appliance still has external reachability. The safest order is exposure check, remediation, then validation. That sequence matters because a patched but still broadly exposed remote access box can remain a high-value target if the fix was incomplete or the exposure was never narrowed.

For broad vulnerability handling, the workflow in Vulnerability Management Guide fits this case well: identify scope, prioritise known exploited issues, verify remediation, and track exceptions rather than assuming a one-time change is enough.

If the vendor path is unavailable or the system is too old to support a reliable fix, treat the product as disposable infrastructure. That usually means removing it from the internet, disabling the service, and planning a controlled migration to a supported remote access platform.

What to do if patching must wait

When immediate patching or replacement is not possible, reduce blast radius aggressively. Restrict who can reach the appliance, eliminate unnecessary inbound exposure, and make sure any remaining access is tightly constrained and monitored. An internet-exposed remote access appliance should never be left in a permissive state just because the patch window is difficult.

This is also where SQL injection guidance becomes practical. A flaw like this can sometimes be chained into broader compromise if the appliance exposes configuration data, authentication material, or backend trust relationships. The useful question is not only whether exploitation is confirmed today, but what the appliance could expose if it were abused before retirement.

SQL Injection Prevention Guide is useful here because it reinforces the defensive mindset behind the mitigation, parameterisation, reduced database privilege, and detection of suspicious query behaviour, even when the immediate fix is constrained by end-of-life status.

If the device has been internet-facing for any period while unpatched, assume the possibility of earlier compromise and check logs, admin changes, unexpected configuration drift, and any unusual remote access sessions. For high-value environments, also review whether the appliance held reusable credentials, cached secrets, or trust relationships that would warrant rotation after removal.

Risk and Threat Considerations

An end-of-life remote access appliance with a known SQL injection issue creates a direct exposure to unauthorised access and downstream compromise. The risk is amplified because remote access systems sit on a trust boundary, so a successful exploit can affect more than one user or one session.

Failure mechanism: Attackers exploit the injection flaw to manipulate backend queries, reach sensitive data or control paths, and then use that access to pivot deeper into the environment or extract material that should never have been reachable from the edge device.

Impact: The likely consequences are credential exposure, administrative compromise, lateral movement, and loss of trust in the remote access path itself. If the appliance cannot be confidently updated and contained, the safest security outcome is to disconnect it rather than keep it available as a high-risk entry point.

Standards & Framework Alignment

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

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	This CVE requires rapid identification, prioritisation and remediation of an actively risky exposed system.
Recommendation — Scan for SRA exposure, prioritise the KEV item, and verify remediation or retirement.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The answer depends on locating vulnerable instances and validating remediation state.
	SI-2 — Flaw Remediation	This is a patch-or-retire decision for a known software flaw in an exposed appliance.
	AC-4 — Information Flow Enforcement	Mitigation may require removing internet exposure or constraining access paths to the appliance.
Recommendation — Continuously inventory SRA assets, scan for exposure, and track remediation to closure. Apply the vendor fix or documented mitigation, then retire unsupported instances. Restrict inbound access to the appliance and remove unnecessary exposure.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	The issue is a technical vulnerability requiring tracking, remediation and exception handling.
Recommendation — Record the vulnerability, remediate it, and escalate unsupported exposure for retirement.

Practitioner Guidance

What to prioritise: Treat supported-status verification as part of remediation, not a side note. If the device is end-of-life, a successful patch does not necessarily make it a good candidate for ongoing exposure.

What to verify: Confirm internet reachability, current configuration, and whether any account, session, or administrative material on the appliance could have been exposed before mitigation. If the answer is uncertain, assume the blast radius is wider than the appliance itself.

Decision rule: If you cannot move the instance onto a vendor-supported remediation path quickly, remove it from service and replace it with a supported remote access control rather than extending the risk window.

Practitioner takeaway: For end-of-life remote access appliances, the real remediation decision is often retirement, because continued exposure is harder to justify than replacement when the flaw is remotely exploitable.