Omada Gateway EUVD-2026-63544

The OpenVPN Server feature must be explicitly enabled on the Omada gateway, the OpenVPN service (its listening UDP/TCP port) must be network-reachable by the attacker, and the attacker must be able to initiate an OpenVPN connection attempt to the device. No authentication and no user interaction are required, since the injection occurs during connection establishment before authentication completes (PR:N/UI:N). The primary limiting factor is that this is not a default-on service: gateways without OpenVPN Server configured, or with the VPN port filtered/unreachable, are not exploitable. Exploitation is confined to the specific TP-Link/Omada ER- and DR-series models and firmware builds enumerated in the advisory.

The signals align toward high priority: CVSS 4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N gives network-reachable, low-complexity, unauthenticated exploitation with high confidentiality, integrity and availability impact (VC/VI/VA:H) plus low subsequent-system impact, scoring 9.3. The single meaningful limiter is configuration: the OpenVPN Server feature must be enabled and the VPN service must be reachable by the attacker, so exposure is narrower than a default-on network service. No EPSS score, KEV listing, or POC was provided, so there is no evidence of active exploitation or public exploit code yet - the urgency derives from the pre-auth RCE severity and the fact that VPN endpoints are by design internet-facing, not from observed attacks. Any operator running these gateways as an internet-exposed OpenVPN Server should treat this as urgent and patch promptly, since a compromised gateway sits at the network perimeter and can pivot inward. The absence of EPSS/KEV data means the exploitation-probability picture is incomplete rather than reassuring.

An attacker locates an internet-facing Omada gateway with the OpenVPN Server enabled and initiates an OpenVPN connection to it. During the pre-authentication handshake they supply crafted client input that the gateway passes into a backend command, executing attacker-chosen OS commands as the device's service account and gaining control of the perimeter gateway. No credentials or user interaction are required (AV:N/AC:L/PR:N/UI:N); no public POC has been identified at time of analysis.