How do you patch or mitigate CVE-2020-2021 (Palo Alto Networks PAN-OS Authentication Bypass)?

By NHI Mgmt Group Editorial Team Updated October 18, 2026 Domain: Threats, Abuse & Incident Response

CISA's required action for CVE-2020-2021 is to apply updates per vendor instructions. In practice, find every instance of Palo Alto Networks PAN-OS 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 patching CVE-2020-2021 means in practice

This is an internet-facing appliance problem first and a vulnerability-management problem second. The immediate question is not just whether PAN-OS is installed, but where it sits, which interfaces are exposed, and whether the affected devices can be updated without interrupting critical traffic. For edge devices, exposure often matters as much as the patch itself, which is why the safest fallback is to remove direct internet reachability if you cannot remediate immediately.

The vendor instruction should drive the fix path, but the operational decision is broader: inventory every PAN-OS instance, confirm whether it is externally reachable, and apply the vendor update or documented mitigation everywhere you find it. If you cannot do that quickly, isolate the device, restrict management access, and treat continued exposure as a temporary exception rather than a stable state.

Because this flaw was used in the wild, patching should be paired with a compromise check, not treated as a purely preventive task. Review device logs, authentication events, configuration changes, and any unusual admin activity before and after remediation so you can tell whether the flaw was already abused.

How to reduce exposure if you cannot patch immediately

When patching is delayed, the priority is to shrink the reachable attack surface. That usually means removing the appliance from direct internet exposure, tightening access to management services, and, where possible, moving admin access behind a controlled path rather than leaving the device open to unauthenticated reachability.

For an edge platform, partial mitigation is only useful if it actually changes the attack path. A mitigation that leaves the vulnerable interface public, keeps management services broadly reachable, or depends on an informal network rule will not buy much time. If the device cannot be made materially less exposed, the safer decision is to take it out of service until the update can be applied.

Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog for the authoritative remediation details, then verify the change from the outside. Confirmation should include an external reachability test, a log review, and a quick check that no alternate path still exposes the vulnerable service.

What to check after remediation

After the update or mitigation is in place, assume the device may have been probed before you changed it. Look for login anomalies, configuration drift, unexplained policy changes, new local accounts, and any traffic or session patterns that do not match normal administration. The goal is not just to confirm the patch, but to establish whether the device was already used as a foothold.

That review matters because edge appliances sit at a trust boundary. If an attacker reached the device before remediation, the follow-on question is whether they used it to pivot, intercept traffic, or alter device settings in a way that survives the patch. If the answer is uncertain, expand the review to adjacent systems that rely on the appliance for ingress or remote administration.

Risk and Threat Considerations

An authentication bypass on an internet-facing security appliance creates direct exposure because it can let an attacker reach an administrative or trusted path without valid credentials. That makes the issue more than a simple software defect: it can become a perimeter compromise, especially when the device fronts sensitive internal services.

Failure mechanism: The vulnerable appliance accepts or processes a request in a way that bypasses normal authentication checks, allowing unauthorized access to management or control functions. If the device remains externally reachable, the attacker can probe, authenticate, or manipulate the appliance before defenders notice.

Impact: Successful exploitation can expose device configuration, allow traffic redirection or policy changes, and create a stepping stone into internal networks. Because the flaw was exploited in the wild, defenders should also assume the possibility of pre-remediation compromise and look for persistence or lateral movement indicators.

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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Applies because exposed PAN-OS devices need secure configuration and reduced attack surface.
	CIS-7 — Continuous Vulnerability Management	Applies because the question is about patching a known exploited CVE and verifying remediation.
Recommendation — Harden exposed appliances, remove unnecessary public access, and verify secure configuration after remediation. Track PAN-OS assets, prioritize the exploited CVE, and confirm remediation completion across the estate.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	Applies because the flaw is an internet-facing authentication bypass exploited against a public service.
Recommendation — Hunt for exploitation of the exposed appliance and review logs for access and follow-on activity.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Applies because the core action is vendor-directed remediation of an exploited software flaw.
	AU-6 — Audit Record Review, Analysis, and Reporting	Applies because post-patch log review is needed to check for earlier exploitation.
Recommendation — Apply the approved update or mitigation and track remediation until every vulnerable instance is addressed. Review appliance and authentication logs for signs of prior exploitation and suspicious administrative activity.

Practitioner Guidance

What to prioritize: Start with asset discovery and exposure status, not with patch deployment alone. Devices that are internet-facing or centrally placed in the traffic path deserve the fastest action because their compromise has the widest blast radius.

What to verify: Confirm that every PAN-OS instance has a recorded remediation state, that the vendor update or mitigation was actually applied, and that no alternate interface still exposes the vulnerable service. Then verify the logs for the relevant time window before you close the ticket.

Decision rule: If you cannot patch quickly and cannot materially reduce exposure, remove the device from service until you can. A partially mitigated appliance that remains publicly reachable should be treated as a live risk, not a completed remediation.

Practitioner takeaway: For edge appliance CVEs, the right sequence is exposure control, vendor-directed remediation, and compromise verification, in that order, because patching alone does not answer whether the device was already used.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org