CVE-2026-46368

The vulnerability in luci-app-https-dns-proxy stems from the LuCI wrapper passing the 'name' parameter directly into shell execution via the setInitAction ubus method without sanitizing metacharacters. This is command injection. The ubus RPC layer authenticates the caller — it confirms who is making the request — but it does not validate whether the command itself is safe to execute. Authentication and input validation are separate security functions, and this CVE conflates them. The attack works because the 'name' parameter flows directly into a shell command. Any metacharacter (semicolons, pipes, backticks, $() subshells) that survives the parameter gets interpreted by the shell with root privileges. On default OpenWrt configurations, ubus is network-accessible unless firewalled, meaning the attack surface isn't limited to localhost. Anyone who can reach the ubus socket with valid credentials — including stolen session tokens or compromised accounts — can achieve root command execution. Check your deployment: verify whether ubus is exposed beyond localhost. If LuCI is accessible over the network, ubus likely is too. Patch luci-app-https-dns-proxy immediately. More importantly, audit every ubus method handler in your installed LuCI apps for the same pattern — unquoted parameters flowing into shell commands. This is a known class: CVE-2020-27873 involved the same flaw in a different LuCI app, and the pattern persists because the ubus RPC layer has no mandatory input-validation primitives. The fix in this package will quote the parameter. The next vulnerable package won't inherit that fix architecturally — it will wait for its own CVE.

Reviewed through automated stages and approved by a human before publication.