How do you patch or mitigate CVE-2020-5135 (SonicWall SonicOS Buffer Overflow)?

CISA’s required action for CVE-2020-5135 is to apply updates per vendor instructions. In practice, find every instance of SonicWall SonicOS 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. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What CVE-2020-5135 Means for SonicOS Exposure

CVE-2020-5135 is a buffer overflow issue in SonicWall SonicOS, so the practical question is not just whether a device is patched, but whether it is still reachable and still running the affected software path. For internet-facing appliances, that usually means inventory first, then urgent remediation, then exposure reduction if the fix cannot be applied immediately.

For this class of flaw, the remediation decision should be tied to the device’s role in the environment. If the SonicWall is protecting remote access or edge traffic, downtime planning matters, but so does the possibility that the device itself has already been touched by exploitation before you got to it.

Where an appliance sits on the perimeter, the safest interpretation is that delay increases both exploitability and blast radius. That is why the response is usually framed as patch, mitigate, or remove from exposure rather than simply “schedule maintenance.”

How to Patch or Mitigate It Safely

Start by locating every SonicWall SonicOS instance and confirming which ones are internet reachable, because exposed appliances deserve priority over internal-only devices. Then apply the vendor security update or the documented mitigation path from the advisory, using the vendor’s instructions rather than assumptions about version compatibility or service impact.

If patching cannot happen right away, the fallback is to reduce exposure as much as possible. That can mean removing direct internet access, restricting management and VPN exposure, or taking the product out of service until a supported fix is in place. For a perimeter device, “temporary” exposure should be treated as a controlled exception, not a steady state.

After the change, validate that the device is actually on the remediated path and that no alternate management route still exposes it. A common failure mode is leaving one interface, rule, or remote access path open while believing the system is no longer reachable.

What to Check After Remediation

Once the patch or mitigation is in place, review logs and adjacent telemetry for earlier exploitation attempts. Because this flaw was used in the wild, the question is not only whether the device is now fixed, but whether it was already used as an entry point or foothold before remediation.

Look for unusual authentication events, configuration changes, new administrative actions, unexplained restarts, or traffic patterns that do not fit normal appliance behavior. If you see signs of compromise, treat the issue as incident response, not just vulnerability management, and expand the review to connected systems that depended on the SonicWall.

If the appliance handled remote access, also review whether any sessions, credentials, or secrets exposed through that path should be rotated. That is especially important when the device sat on a privileged boundary or mediated access into higher-trust networks.

Risk and Threat Considerations

Internet-facing security appliances are attractive targets because they sit at trust boundaries and often combine remote access, management access, and traffic inspection in one place. A buffer overflow in that position can move quickly from simple device compromise to broader network exposure, especially if the attacker can pivot through trusted connectivity or retained sessions.

Failure mechanism: An attacker can exploit the overflow to destabilize the appliance or gain execution on a device that is trusted by the rest of the network. If the device remains exposed, mitigation by delay or partial configuration change may still leave a usable attack path.

Impact: The result can include device compromise, service disruption, loss of perimeter trust, and follow-on access to internal resources that depended on the SonicWall for segmentation or remote access control.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Applies because the issue requires finding, prioritising and remediating an actively exploited vulnerability.
Recommendation — Prioritise and remediate the affected SonicWall instances, then verify exposure reduction and remediation status.
NIST CSF 2.0	RS.MA-01 — Mitigation is performed	Applies because the response centers on applying vendor mitigation and removing exposure to stop exploitation.
	DE.CM-09 — Configurations are monitored for changes	Applies because post-fix review should detect earlier compromise or unauthorized appliance changes.
Recommendation — Apply the vendor fix or mitigation and confirm the appliance is no longer exposed to the vulnerable path. Review logs and configuration changes for signs the SonicWall was exploited before remediation.
OWASP Non-Human Identity Top 10	NHI-06 — Insecure Cloud Deployment Configurations	Applies where mitigation depends on removing exposed access paths and hardening an internet-facing appliance.
	NHI-01 — Improper Offboarding	Applies when an unsupported or unpatchable appliance must be removed from service instead of left exposed.
Recommendation — Remove unnecessary external exposure and harden management access until the fix is deployed. Retire or isolate appliances that cannot be brought onto a supported, remediated state.

Practitioner Guidance

What to prioritise: Prioritise externally reachable SonicWall instances first, then devices that terminate VPN or remote access, because those have the highest likelihood of exposure and the highest potential downstream impact if compromised.

What to verify: Verify both the firmware state and the actual exposure state. A device is not effectively remediated if the patch is applied but management, VPN, or another externally reachable path still leaves it open to attack.

Decision rule: If you cannot patch promptly, do not leave the device in its original exposure state, remove internet reachability or retire it from service until the supported fix is installed and validated.

Practitioner takeaway: For exploited perimeter flaws, the real control is not patching alone, it is patching plus exposure reduction plus confirmation that the device was not already used as a foothold.