Inside CVE-2025-14733: The Unauthenticated RCE Hitting WatchGuard Firewalls
Analysis of CVE-2025-14733, a critical WatchGuard Firebox vulnerability. Learn why unauthenticated RCE persists even after deleting vulnerable VPN configurations.
Analysis of CVE-2025-14733, a critical WatchGuard Firebox vulnerability. Learn why unauthenticated RCE persists even after deleting vulnerable VPN configurations.
Security administrators worldwide are rushing to patch a critical security vulnerability in WatchGuard Firebox appliances that allows remote, unauthenticated attackers to execute arbitrary code with system-level privileges. Tracked as CVE-2025-14733 with a CVSS score of 9.3, the flaw targets the IKEv2 protocol implementation within the perimeter firewall's VPN stack. WatchGuard’s Product Security Incident Response Team (PSIRT) has confirmed active exploitation in the wild, identifying a coordinated campaign using malformed certificate payloads to bypass authentication and seize control of the device.
iked process.This security vulnerability is particularly attractive to state-sponsored actors and initial access brokers because it provides a pre-authentication entry point. Most perimeter attacks today require stolen credentials or MFA exhaustion; CVE-2025-14733 requires only that the VPN interface is reachable from the internet.
Current threat activity shows attackers utilizing the flaw to drop persistent binaries and establish reverse shells. A successful exploit often results in the iked process hanging or crashing, but existing VPN tunnels frequently remain active, allowing the attacker to remain undetected while moving laterally into the internal network.
Perhaps the most insidious discovery in this disclosure is what researchers are calling the "Zombie Configuration" risk. In many instances, an administrator might believe they have mitigated the risk by deleting the Mobile VPN or Branch Office VPN (BOVPN) configurations that use IKEv2.
However, the underlying iked daemon may remain vulnerable if a static peer gateway is still configured on the device. Even if the IKEv2 features are removed from the interface, the background logic continues to monitor for specific IKEv2 traffic if the peer definitions are not completely purged. This state-leakage means that firewalls presumed "clean" by their owners remain exposed to the RCE exploit.
Defenders should immediately audit logs for the following Indicators of Attack (IoAs). WatchGuard suggests that an unusually large IDi payload (greater than 100 bytes) or CERT payload (greater than 2000 bytes) is a definitive signal of an exploit attempt.
| Indicator Type | Value / String | Severity |
| IP Address | 45.95.19.50 | Critical (Known Attacker) |
| IP Address | 199.247.7.82 | Critical (Known Attacker) |
| Log Entry | Received peer certificate chain is longer than 8 | High (Exploit Attempt) |
| Log Entry | IKE_AUTH request ... CERT(sz=3000) | Critical (Buffer Overflow) |
| System Behavior | iked process crash / fault report | Medium (Post-Exploit Signal) |
While applying the latest firmware (2025.1.4, 12.11.6, or 12.5.15) is the mandatory first step, it is not a complete remediation for devices that were exposed prior to the fix. Because the exploit allows for total device compromise, a "dirty" firewall could still harbor stolen secrets.
1. Secret Rotation: Administrators must rotate all IKEv2 shared secrets, local admin passwords, and any certificates stored on the Firebox.
2. Peer Audit: Manually verify that no orphaned static gateways remain in the configuration.
3. Cloaking: If patching is delayed, restrict the IKEv2/IPSec policy to specific, trusted source IPs only, effectively hiding the daemon from the open web.