Join our Newsletter — 33% off our NHI Course

Is CVE-2022-30525 (Zyxel Multiple Firewalls OS Command Injection) being exploited in the wild?

Yes. CISA added CVE-2022-30525 to its Known Exploited Vulnerabilities catalogue on 16 May 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. A command injection vulnerability in the CGI program of some Zyxel firewall versions could allow an attacker to modify specific files and then execute some OS commands on a vulnerable device.

How to interpret active exploitation for CVE-2022-30525

This is not a theoretical or “patch someday” issue. Once CISA places a CVE in the Known Exploited Vulnerabilities catalogue, the practical assumption is that real-world exploitation is already happening somewhere, so the reader should treat exposed Zyxel firewall instances as immediately relevant assets rather than background inventory.

For this class of edge-appliance flaw, the first question is whether any device is internet-facing, reachable from untrusted networks, or still carrying administrative exposure that should have been removed. Edge Device Security Guide is useful here because it frames the operational reality of firewalls, gateways, and similar appliances as high-value targets where management exposure, firmware state, and logging quality all matter.

The second question is what the vulnerability actually enables on a vulnerable device. Command injection in a firewall is especially serious because it can shift from a narrow web-facing bug into full device-level execution, configuration tampering, rule manipulation, or recovery-blocking changes. That is why exploited edge-device flaws are usually triaged as exposure, persistence, and control-plane risk, not just as a generic software defect.

What to verify before you treat the device as safe

Start by confirming whether the affected Zyxel firewall is in your asset inventory, whether it is exposed to the internet, and whether its management plane or CGI interface has any reachable path from outside trusted administration networks. If the device is still in service, verify firmware status against the vendor advisory and cross-check current exploitation status against the CISA Known Exploited Vulnerabilities Catalog rather than relying on a generic scanner result alone.

Because this is a KEV-listed issue, prioritisation should be based on exposure and exploitability, not on whether a given firewall has already shown obvious malfunction. A vulnerable appliance can be exploited without leaving an immediately visible service outage, so verification should include configuration review, admin account review, and log review for unexpected requests or command execution traces. Where the device is a perimeter control, the absence of alarms is not evidence of absence.

Use the vendor advisory for exact affected and fixed versions, then validate the device state directly on the appliance. If the firmware cannot be confirmed from the management interface with confidence, assume you do not yet have enough evidence to declare it safe.

How to handle patching, mitigation, and compromise checks

If the device can be patched, do that first and then review whether any configuration drift, unauthorized rules, or unexpected administrative changes occurred before and during the exposure window. For exploited edge appliances, remediation is not complete when the image is updated, because an attacker may have already used the command execution path to alter the box or pivot to adjacent systems. The Zero-Day and Exploited Vulnerabilities Guide is a useful companion for deciding when emergency mitigation, compromise assessment, and post-patch hunting should follow a KEV entry.

If patching must wait, reduce reachable surface area immediately: restrict management access, block untrusted source paths to the CGI interface, and apply any vendor mitigation exactly as published. For perimeter devices, this often matters more than rate-limiting or generic hardening because the attacker only needs one viable management path. If the appliance supports detailed logging, preserve logs before changing the configuration so you do not destroy the evidence you need for investigation.

After remediation, check for earlier compromise. Review administrator accounts, VPN or remote-access settings, firewall rules, cron or scheduled tasks, and any outbound connections initiated by the appliance. If you find signs of command execution, treat credential rotation for the device and adjacent administrative systems as part of the response, because edge-device compromise often creates follow-on access rather than stopping at the appliance itself.

Risk and Threat Considerations

Perimeter firewall exploitation is high impact because the device sits in a trusted path and can be used to alter policy, hide traffic, or open paths into internal networks. When a command injection flaw is already in KEV, the likely concern is not just initial compromise but durable control of a boundary system that defenders rely on for segmentation and enforcement.

Failure mechanism: An attacker reaches the vulnerable CGI program, injects operating-system commands, and uses the appliance’s own privileges to change files, settings, or traffic-handling behavior. That can create persistence, selective bypass of controls, or a foothold for lateral movement.

Impact: The organisation can lose trust in the firewall as an enforcement point, and remediation may require rebuild or forensic reset rather than simple patching if the box was modified after exploitation.

Standards & Framework Alignment

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

OWASP API Security Top 10 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 KEV-listed appliance flaws require timely remediation and patch verification.
AU-6 — Audit Record Review, Analysis, and Reporting Command injection on an edge device demands review of logs for compromise evidence.
Recommendation — Prioritise and verify remediation for the vulnerable Zyxel firewall. Review appliance logs for exploit attempts and post-compromise activity.
CIS Controls v8 CIS-7 — Continuous Vulnerability Management The question is about whether a known exploited CVE is active in the wild and needs prioritised remediation.
CIS-4 — Secure Configuration of Enterprise Assets and Software Edge firewalls need hardened management exposure and secure configuration to reduce exploitability.
Recommendation — Prioritise, track, and remediate the KEV-listed vulnerability immediately. Harden the firewall’s management exposure and configuration.
OWASP API Security Top 10 API8 — Security Misconfiguration The flaw is in a web-accessible CGI path on the appliance, making exposed management configuration central.
Recommendation — Restrict and verify the appliance’s externally reachable management surfaces.

Practitioner Guidance

What to prioritise: Treat exposed firewalls and gateways as emergency assets when they appear in KEV, even if the environment has not reported an incident. The decision point is exposure plus exploitability, not whether security tooling has already flagged abuse.

What to verify: Confirm the exact appliance model, firmware branch, management exposure, and log retention before you touch the system. Preserve evidence first if there is any chance the device has already been reached from untrusted networks.

Decision rule: If you cannot prove the device is patched and not externally reachable on the vulnerable path, assume it is at risk and escalate to containment plus compromise assessment rather than waiting for a routine maintenance window.

Practitioner takeaway: For KEV-listed perimeter flaws, the safe posture is to assume exploitation is plausible until you can prove otherwise, and to validate both patch state and post-exploitation integrity before declaring the device healthy.