Is CVE-2022-23176 (WatchGuard Firebox and XTM Privilege Escalation) being exploited in the wild?

How the KEV listing changes the answer to “exploited in the wild”

CISA’s KEV inclusion is the key signal that this CVE is not just theoretical. For defenders, the practical question is no longer whether exploitation is plausible, but whether vulnerable WatchGuard appliances are still reachable, monitored, and ready for emergency action. The right response is to treat the KEV listing as an active exposure notice, not a background advisory.

When a flaw reaches KEV, it shifts from routine vulnerability tracking to time-sensitive remediation. That matters most for internet-facing management planes, because exposed administration surfaces give attackers the shortest path from a low-privilege foothold to privileged control.

For broader handling of exploited vulnerabilities, the most useful framing is Zero-Day and Exploited Vulnerabilities Guide, which is built around KEV triage, emergency mitigation, and post-patch hunting. It is the right model when the issue is not discovery alone, but confirmed exploitation pressure.

Why privileged management access makes exploitation dangerous

The core security problem here is privilege escalation through management exposure. If an attacker can authenticate with unprivileged credentials and then obtain a privileged management session, they may be able to alter firewall policy, view configuration, create persistence, or pivot into adjacent networks.

That is why this class of weakness is often more serious on perimeter appliances than on ordinary servers. The management interface is not just another application surface, it is the control point for traffic, trust, and administrative access. If that boundary fails, the attacker may inherit broad operational authority over the device.

For organizations that need a baseline for exposed appliances, Edge Device Security Guide is the most relevant internal reference because it covers exposed management interfaces, appliance hardening, logging minimums, and end-of-life planning. That combination is especially important for firewall-class devices that sit at the network edge.

External confirmation and record lookup should start with the CISA Known Exploited Vulnerabilities Catalog and the CVE Program, which help separate the vulnerability identifier from the exploitation status and authoritative record context.

What to check before you assume you are safe

First confirm whether any Firebox or XTM appliances are still in service, including devices used only for VPN termination, branch connectivity, or backup perimeter roles. Teams often miss “temporary” or legacy appliances because they are outside normal endpoint tooling.

Then verify whether management access is exposed at all, especially if administrators can reach it from untrusted networks, shared jump hosts, or split-tunnel VPN paths. If you cannot confidently prove that the management plane is constrained, you should treat the device as exposed until proven otherwise.

Use the vendor advisory and the KEV catalogue for version and fix details rather than trying to reconstruct them from secondary summaries. In parallel, check logs for unusual administrative sessions, configuration changes, account anomalies, or access from unexpected source addresses around and after the KEV date.

Where organizations need a risk-based prioritisation method for CVEs that are already under active exploitation, Vulnerability Management Guide is the best companion resource because it ties KEV status to prioritisation, exceptions, verification, and remediation tracking.

Risk and Threat Considerations

Exploited edge-device privilege flaws are high impact because they combine perimeter reachability with administrative authority. Even a single successful login path can expose routing, policy, and management functions that sit close to the trust boundary of the network.

Failure mechanism: An attacker uses unprivileged access to reach a privileged management session, then leverages that elevated session to change device settings, maintain persistence, or move toward internal systems.

Impact: The result can include loss of perimeter integrity, unauthorized traffic flow changes, data exposure, and a much larger blast radius than a typical application compromise.

Practitioner Guidance

What to prioritise: Treat any exposed or hard-to-audit WatchGuard management plane as urgent until exposure is proven removed and the vendor remediation path is completed. If the device is internet-facing or remotely manageable, it should be at the top of the patch and validation queue.

What to verify: Confirm whether the appliance has been used for administrative access from unexpected locations, whether configuration changes occurred near the exploitation window, and whether any local accounts or credentials may have been exposed through the flaw.

Decision rule: If patching must wait, restrict management reachability immediately, preserve logs, and hunt for compromise before assuming the device is merely “vulnerable but untouched.”

Practitioner takeaway: For KEV-listed edge-device flaws, the real question is not only whether the device is patched, but whether attacker-controlled management access may already have changed the trust boundary.

Related resources from NHI Mgmt Group

• CVE-2022-23176 (WatchGuard Firebox and XTM Privilege Escalation)
• Is CVE-2022-26923 (Microsoft Active Directory Domain Services Privilege Escalation) being exploited in the wild?
• Is CVE-2022-41125 (Microsoft Windows CNG Key Isolation Service Privilege Escalation) being exploited in the wild?
• Is CVE-2022-41033 (Microsoft Windows COM+ Event System Service Privilege Escalation) being exploited in the wild?