Zyxel hardening and exploited-vulnerability guide: Securing ZLD Firewalls, VPN and Admin Access

Zyxel ATP, USG FLEX and USG/ZyWALL VPN firewalls are widely deployed at the edge of small and mid-sized networks, and attackers have repeatedly exploited their web management interface, VPN services and stored accounts to gain a foothold, plant rogue admin accounts and deploy ransomware. CISA's Known Exploited Vulnerabilities catalogue (version 2026.10.21) lists 13 Zyxel entries across firewalls, NAS devices, DSL CPE, routers and GS1900 switches. This guide covers Zyxel-specific hardening of ZLD-based firewalls: management exposure, administrator and VPN identities, the credentials a configuration holds, logging, the exploited vulnerabilities and how to check a device after exposure. It is for network and security engineers running Zyxel gear. General edge practice is in the Edge Device Security Guide, which this page does not repeat. Menu paths and advisories were checked against Zyxel support articles, Zyxel Community posts and Zyxel security advisories on 28 October 2026.

Key takeaways

• Close WAN management first. Zyxel's own guidance is to allow only the services you need from WAN to the device, restrict any web management to a fixed source IP or FQDN, and end Admin Service Control with an ALL deny rule.
• Treat accounts as the persistence layer. Past Zyxel compromises left unknown admin-type and SSL VPN accounts and rogue policy rules. Auditing Object > User/Group > User and Security Policy rules is part of every patch cycle.
• Enable 2FA for every admin, then check it applies. Admin 2FA uses an authenticator app, and users without 2FA configured can still log in without it, so enforcement must be verified per account.
• Patch to a fixed ZLD release quickly. CVE-2024-11667 affected ZLD 5.00 to 5.38 and is flagged in KEV for known ransomware use; Zyxel says 5.39 and later are immune. Models outside the vulnerability support period do not get fixes.
• Protect the configuration file. It holds pre-shared keys, directory bind credentials and local passwords. Use Sensitive Data Protection with a custom key and treat backups as secrets.

How identity and access work in Zyxel firewalls

ZLD firewalls authenticate three groups of identities, each with its own entry points.

Two access lists control who can reach these entry points: Security Policy rules (Configuration > Security Policy > Policy Control), which govern traffic to the device from each zone, and Admin and User Service Control under System > WWW, which govern who may use the web interface and user portals. Both must be restrictive; either alone leaves gaps.

Admin roles and privileged access

• Named admins only: give every administrator a named admin-type account and remove or disable shared ones. Reserve limited-admin accounts for staff who only need to view or make restricted changes.
• Two-factor authentication: enable 2FA for admin access with Google Authenticator, as Zyxel recommends, and set it up for each admin individually. Zyxel notes that users without 2FA configured can still log in without it, so check every admin account. The ZLD 5.40 Security Best Practices wizard makes 2FA mandatory for administrator-level accounts.
• Admin Service Control: under System > WWW, add accept rules for specific admin IP addresses first, then an ALL/ALL deny rule as the last entry, so you do not lock yourself out.
• Management ports: move the HTTPS server port off 443 and common alternatives, enable redirect HTTP to HTTPS, and consider Authenticate Client Certificates so the web interface requires a trusted client certificate (this breaks SecuExtender VPN provisioning, so test first).
• Disable unused services: Telnet, FTP (except when HA-Pro needs it), SNMP if you do not monitor, ZON, and SSH if you do not use it regularly. The web console can take CLI input.
• Password hygiene: set password complexity and change intervals under Login Security, and User IP Lockout to limit wrong passwords before a temporary block. The 5.40 wizard prompts for a change when the admin password is more than 60 days old.
• Privileged CLI risk: CVE-2026-14818 (advisory 4 August 2026) lets an authenticated administrator execute a crafted configuration file through a CLI command. A stolen admin session therefore becomes code execution on the device; 2FA and source restriction are the main defences.

See the Network Device Management Plane Hardening Guide for vendor-neutral management plane design.

Integrations, API tokens and service accounts

A Zyxel firewall configuration is a store of non-human credentials. Inventory each one and know how to rotate it.

If a firewall is compromised, assume every secret in its configuration is exposed. Rotate them in this order: admin passwords and 2FA, directory bind and RADIUS secrets (which work elsewhere in the network), IPSec keys with each peer, then VPN user credentials. See the Secrets Management Guide.

Logging and detection

• Admin alerts: under Configuration > Log & Report > Log Settings, set email alerts for events such as administrator logins, especially on devices nobody checks daily. Since ZLD 4.65 and 5.02, admin-type account changes are logged at higher severity.
• Central logging: forward logs to a syslog collector or SIEM so evidence survives a device wipe and so you can correlate VPN logins with directory events.
• What to watch: new or changed admin-type accounts, new SSL VPN users, policy rules or policy routes added outside change windows, admin logins from unexpected sources, bursts of failed logins and IP lockouts, and firmware or configuration file uploads.
• Known indicators from past incidents: Zyxel's 2021 incident FAQ described unknown accounts named zyxel_sllvpn, zyxel_ts, zyxel_vpn_test and manage, and rogue policy rules with descriptions containing "loseang" or "loosing". These names are examples; attackers change them, so look for any account or rule you cannot attribute.

Metrics that show the programme is working:

• Percentage of firewalls on a fixed, supported ZLD release within 14 days of an advisory.
• Devices with web management reachable from the internet without a source restriction (target zero).
• Admin accounts with 2FA configured as a share of all admin accounts (target 100 percent).
• Unattributed accounts or policy rules found per quarterly audit.
• Devices beyond Zyxel's vulnerability support period still in service.

Known exploited Zyxel vulnerabilities

From the CISA KEV catalogue (local copy, version 2026.10.21). Always read the current Zyxel advisory for fixed versions.

The pattern is clear: most firewall entries are pre-authentication flaws in services exposed to the WAN, and several affected product lines (older routers, some DSL CPE) are end of life. KEV's required action for the DSL CPE entries warns the products may be end of life or end of service. For those, replacement is the fix; see the Edge Device End of Life Replacement Playbook. Prioritisation guidance is in the CISA KEV Catalogue Guide.

Hardening baseline

1. Inventory and support status: list every Zyxel device with model, ZLD version and whether it is inside Zyxel's vulnerability support period. Plan replacement for anything outside it.
2. Update firmware: move to the current fixed ZLD release (at least 5.39 for CVE-2024-11667 and 5.43 for CVE-2026-14818 on ATP and USG FLEX). Enable automatic updates where manual updates are often missed. If you cannot patch, Zyxel advises temporarily disabling remote access until you can.
3. WAN to ZyWALL policy: allow only the services you use (IPSec ESP, IKE and NAT-T; Wiz_2FA or Wiz_SSLVPN only if required), restrict HTTPS management to a single source IP or FQDN rather than GeoIP, and end with a deny rule.
4. LAN to ZyWALL policy: grant full device access only from a dedicated management network or admin IPs; open DNS, RADIUS or SNMP only where needed.
5. Web management: non-standard HTTPS port, HTTP redirected, Admin Service Control allow-list with a final deny, User Service Control restricted or denied if portals are unused.
6. Admin identity: named admin accounts, 2FA on every admin, password complexity and change intervals, IP lockout, limited concurrent logins (not set to 1).
7. VPN: prefer IKEv2 with certificates and EAP for clients; avoid L2TP; avoid SSL VPN where possible, and if used, move it off 443, require certificate authentication and restrict the source.
8. Services off: Telnet, FTP, SNMP and ZON off unless needed; SSH off if not used.
9. Threat protection: enable Anomaly Detection and Prevention with the default profile on the WAN zone.
10. Configuration protection: Sensitive Data Protection with a custom key; store backups and the key in a secrets vault.
11. Logging: admin login email alerts and syslog forwarding to a central collector.

Test policy and Service Control changes during a maintenance window with console or out-of-band access available, and export the configuration first so you can roll back.

Checking a device after exposure

If a device ran a vulnerable release with WAN management or VPN exposed, assume compromise until checked. Based on Zyxel's incident guidance:

1. Preserve logs and export the configuration before changing anything.
2. Review Configuration > Object > User/Group > User and delete unrecognised accounts and the rules linked to them.
3. Review Policy Control rules and Policy Routes (Configuration > Network > Routing > Policy Route) for entries you cannot attribute.
4. Check IPSec VPN Gateway pre-shared keys for changes.
5. Upgrade firmware, then change all admin passwords and rotate the configuration secrets listed above.
6. Hunt downstream: VPN sessions from the exposure window, directory logins by the bind account and any new accounts in the internal directory.

The full process is in the Edge Device Compromise Investigation Playbook.

Common misconfigurations

• GeoIP instead of a source allow-list: country filters still expose management to every attacker in that country or using infrastructure there. Zyxel recommends a single IP or FQDN.
• 2FA enabled but not configured per user: accounts without a configured second factor can still log in with a password only.
• SSL VPN on 443 with local users: the most exposed configuration, combining a common port, password-only accounts and an internet-facing portal.
• Patching without auditing: firmware fixes the flaw but leaves any account, rule or route an attacker added. Audit after every emergency update.
• Domain admin as the LDAP bind account: a device compromise becomes a directory compromise.
• Unprotected configuration backups: backups copied to file shares or tickets expose every PSK and bind password.

Framework mapping

Practitioner checklist

• Every Zyxel device inventoried with model, ZLD version and support status.
• Firmware on a fixed release for all KEV-listed firewall flaws; automatic updates considered.
• WAN management restricted to a fixed source or disabled; Admin Service Control ends with a deny rule.
• 2FA configured and verified on every admin account.
• Telnet, FTP, SNMP, ZON and unused SSH disabled.
• SSL VPN and L2TP replaced by IKEv2 with certificates where possible.
• Sensitive Data Protection enabled and backups stored as secrets.
• Admin login alerts and syslog forwarding in place.
• Quarterly audit of users, policy rules and policy routes against change records.
• End-of-support devices on a replacement plan.

Standards and references

• Zyxel: Security Advisories
• Zyxel: Security advisory, protecting against recent firewall threats
• Zyxel: Security advisory for CVE-2026-14818 in ZLD firewalls
• Zyxel Support: USG/ATP/VPN Basics of securing a firewall
• Zyxel Community: ZLD 5.40 Update, Security Best Practices
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Exploit Public-Facing Application

Related NHI Mgmt Group resources: Edge Device Security Guide · VPN Security Guide · Edge Device Exploitation by Threat Actors Guide · SOHO and SMB Router Hardening Guide