Yes. CISA added CVE-2020-5135 to its Known Exploited Vulnerabilities catalogue on 15 March 2022, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. A buffer overflow vulnerability in SonicOS allows a remote attacker to cause Denial of Service (DoS) and potentially execute arbitrary code by sending a malicious request to the firewall.
What this means for a SonicOS appliance in practice
CVE-2020-5135 is not a theoretical weakness to track later. Because CISA placed it in KEV and tied it to ransomware activity, the practical question is whether any SonicWall SonicOS instance is exposed to untrusted traffic and whether it has already passed through the period when exploitation was active. For internet-facing edge devices, treat the device itself as the target, not just the network behind it.
The useful first step is simple exposure confirmation: identify every SonicWall appliance, verify which ones are reachable from untrusted networks, and check whether the management path, VPN path, or other exposed service area aligns with the product condition described in the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog. If the asset is still externally reachable, it belongs in the same urgent review queue as any other actively exploited edge system.
For edge appliances, the right response is usually not just “patch” in the abstract. It is patch or mitigate, then validate from the outside that the exposure is actually gone, because edge device security failures often persist when management interfaces, remote access paths, or legacy configurations remain open after the software update. If patching must wait, isolate the appliance as much as possible, restrict source networks, and reduce any administrative exposure until the vendor fix can be applied.
When a buffer overflow is being actively exploited, a clean patch does not end the analysis. Review logs and surrounding telemetry for signs of prior access, unexpected reboots, anomalous requests, configuration changes, or outbound activity that does not match normal firewall behavior. For devices that mediate remote access, also consider whether sessions or credentials tied to the appliance should be reviewed or rotated if there is any indication the device was used as an entry point.
Where the attack path and blast radius usually widen
The main security issue is that an exploitable edge device sits at a high-trust boundary. Once an attacker can trigger the overflow, the impact can move from denial of service to code execution, and from there to configuration tampering, traffic interception, or an internal foothold. That is why KEV-listed device flaws are operationally more urgent than ordinary backlog items.
Buffer overflows are especially dangerous on firewalls and VPN gateways because the attacker does not need a user to click anything. A single malicious request can be enough if the exposed service is reachable, which makes perimeter exposure the key condition that changes the risk from “latent” to “immediate.”
In a firewalls-and-gateways context, the most important consequence is not only service disruption but trust compromise. If the appliance is modified or monitored by an attacker, internal segmentation and remote access assumptions can fail at once, and the blast radius can extend well beyond the appliance itself.
For a broader view of why that class of issue keeps showing up in perimeter products, the Zero-Day and Exploited Vulnerabilities Guide is useful because it frames the difference between a vulnerability that exists and one that is already being operationalized. The CVE Program and the NIST National Vulnerability Database remain the authoritative places to anchor the identifier and record details, while CISA KEV tells you whether the issue has crossed into known exploitation.
How to handle it when patching, validation, and hunting are all needed
Practitioners should treat this as a verification problem, not only a remediation task. The question is whether the vulnerable SonicOS instance is present, reachable, patched or mitigated, and free from evidence of prior compromise. That sequence matters because exploited edge devices can remain dangerous even after the headline vulnerability is addressed.
A sensible response sequence is: confirm inventory, confirm exposure, apply the vendor fix or mitigation, verify the device is no longer externally exploitable, and then review for compromise indicators. If the appliance supports logs or exportable diagnostics, preserve them before making major changes so that any incident review has evidence to work with.
Vulnerability management discipline matters here because KEV-listed issues need faster prioritisation than routine findings. Use the vendor advisory and the KEV entry for authoritative version and mitigation detail instead of relying on secondary summaries, especially when the asset is an internet-facing security control.
The practical mistake to avoid is assuming that “the firewall is the security device, so it is probably fine.” Firewalls are high-value targets precisely because they sit at the boundary. If the device is old, hard to patch, or still reachable from the internet, the correct assumption is that the risk is elevated until proven otherwise.
Risk and Threat Considerations
Actively exploited edge-device flaws create two simultaneous risks: direct compromise of a boundary system and downstream exposure of the network it protects. A buffer overflow on a firewall or VPN appliance is especially serious because successful exploitation can turn a defensive control into an attacker foothold.
Failure mechanism: A remote attacker sends a crafted request that overflows memory in SonicOS, potentially causing a crash or enabling code execution if the vulnerable service is reachable.
Impact: The device may be taken offline, modified, or used as an entry point for internal access, traffic interception, or follow-on ransomware 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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Active exploitation makes timely remediation central to this edge-device flaw. |
| SI-4 — System Monitoring | Exploit checks and post-remediation hunting require monitoring for abnormal device activity. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Hunting for prior compromise depends on reviewing appliance and adjacent logs. | |
| Recommendation — Accelerate remediation for the vulnerable SonicOS appliance and verify the fix is actually deployed. Monitor the firewall for unusual requests, crashes, and configuration changes. Review logs for signs of exploitation before and after mitigation. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | KEV-listed exploitation requires urgent vulnerability prioritisation and verification. |
| CIS-12 — Network Infrastructure Management | The subject is a firewall appliance whose exposure and configuration must be governed. | |
| Recommendation — Prioritise and verify remediation for KEV-listed SonicOS exposure. Inventory, harden, and monitor the edge appliance configuration and access paths. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | The vulnerability is remotely exploitable through an externally reachable service. |
| Recommendation — Hunt for exploitation attempts against the public-facing SonicOS service. | ||
Practitioner Guidance
What to prioritise: Treat the appliance as an exposed security boundary first, and as a software patching task second. If the device is internet-facing, the exposure itself is the risk multiplier.
What to verify: Confirm the exact device inventory, external reachability, current firmware state, and whether logs show suspicious requests or configuration changes before and after remediation.
Decision rule: If patching is delayed, reduce exposure immediately by constraining access paths and monitoring the device more closely; do not wait for a broader maintenance window if the device is still reachable from untrusted networks.
Practitioner takeaway: For an actively exploited firewall flaw, the real question is not only whether a patch exists, but whether the boundary device has already become part of the attack surface and compromise path.
Related resources from NHI Mgmt Group
- CVE-2020-5135 (SonicWall SonicOS Buffer Overflow)
- Is CVE-2020-15069 (Sophos XG Firewall Buffer Overflow) being exploited in the wild?
- Is CVE-2025-20333 (Cisco Secure Firewall Adaptive Security Appliance (ASA) and Secure Firewall Threat Defense (FTD) Buffer Overflow) being exploited in the wild?
- Is CVE-2023-33009 (Zyxel Multiple Firewalls Buffer Overflow) being exploited in the wild?