luci-app-openvpn CVE-2026-72841

Exploitation requires an authenticated LuCI session (PR:L) on a device with the luci-app-openvpn plugin installed and its web-based OpenVPN configuration upload feature reachable. The concrete prerequisite is the ability to submit the file-upload request and control the instance_name2 parameter so it carries a path-traversal payload; no user interaction (UI:N) or special attack requirement (AT:N) is needed beyond that. Limiting factors: the attacker must already hold valid web-UI credentials, the luci-app-openvpn package must be present (it is an optional add-on, not part of a minimal OpenWrt image), and the LuCI interface must be network-reachable - devices with the admin UI bound to LAN-only and strong credentials substantially raise the bar.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) with high vulnerable- and subsequent-system impact (VC/VI/VA:H, SC/SI/SA:H) reflects a genuinely severe, low-complexity, network-reachable flaw whose only gate is a single authenticated session - consistent with the description's 'authenticated users' and root outcome. This is not a paper-tiger high score: the impact is full device takeover with persistence. The mitigating factor is PR:L - the attacker must already hold valid LuCI credentials (or reach an authenticated session via default/weak passwords, CSRF, or a chained auth bypass), so this is not a pure unauthenticated internet worm. No EPSS score, KEV listing, or POC was provided, so real-world exploitation frequency is unconfirmed; the risk is driven by impact severity and ease of exploitation once authenticated rather than by observed active attacks. Priority should scale with exposure: routers with the LuCI interface reachable from untrusted networks warrant urgent remediation.

An attacker who has obtained (or guessed) valid LuCI credentials for an internet- or LAN-exposed OpenWrt router logs in, opens the OpenVPN configuration upload, and submits a file with an instance_name2 value containing '../' traversal sequences pointing at a system directory. The uploaded content is written as root into, for example, the Dropbear authorized_keys file, and on the next reboot (or immediately) the attacker's SSH key grants persistent root shell access. No public exploit code has been identified, but the low attack complexity makes weaponization straightforward for anyone with an authenticated session.