OPNsense EUVD-2026-116116

Requires (1) a valid OPNsense Web UI or API account whose delegated ACL grants access to one of the affected settings - e.g. page-services-dnsforwarder / api/dnsmasq/* for the confirmed Dnsmasq path, or the Monit, OpenVPN, Unbound, IPsec, NTP, PPP/MPD, DHCPv6, firewall, sudo, WebGUI or System General settings for the related fields; (2) the targeted service enabled (e.g. Dnsmasq DNS & DHCP must be active); and (3) the ability to apply or restart that service through the UI/API so the regenerated config is reloaded. Limiting factors that reduce real-world risk: exploitation is authenticated (PR:L, not pre-auth), is bounded to accounts that have been delegated the specific setting rather than full admins, and depends on the relevant service being in use; impact and whether it reaches command execution vary by component (root command execution confirmed only for Monit, not Dnsmasq). Affected: versions prior to 26.1.11 and prior to 26.4.1p1.

The input CVSS vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H, 8.1) is internally consistent: network-reachable (Web UI/API), low complexity, but PR:L means exploitation requires an authenticated account - specifically one holding delegated ACL access to an affected settings page. This is not a pre-auth internet-facing bug; it is a privilege/RBAC-boundary break usable by an insider or by an attacker who has already obtained limited delegated credentials. No EPSS score and no CISA KEV status were supplied in the input, so widespread-exploitation probability cannot be quantified and there is no evidence of active exploitation; the vuln.today Decision label is 'this_week' (not act_now/emergency). A public PoC is present: the GHSA advisory embeds a Python script and states the Dnsmasq path was dynamically validated in a lab. Signals therefore align on a genuine, credible, but access-gated issue rather than a drive-by: high technical impact (confirmed root command execution via the Monit path; integrity/availability damage to root-managed service configs across many components) tempered by the PR:L authentication requirement. For environments that use delegated/limited admin accounts this is a real RBAC-escalation priority worth patching promptly; for single-full-admin deployments the practical escalation benefit is smaller. Note the input vector sets C:N even though the confirmed Monit path yields root command execution (which would imply confidentiality impact) - this is a divergence between the published vector and the demonstrated worst case.

An authenticated OPNsense user who was granted only delegated access to an affected settings page (for example page-services-dnsforwarder) submits a value containing CR/LF characters in a single-line field, breaking out of the intended generated line and appending attacker-controlled directives to a root-managed service config file. After the service is applied or restarted, the privileged daemon loads the injected directives - on the confirmed Monit path this was demonstrated to achieve root command execution, while the Dnsmasq path injects arbitrary dnsmasq directives (shell execution not confirmed there). A public PoC with a working Python validation script is published in the GHSA advisory, lowering the barrier to reproduction.