CVE-2026-58390: OPNsense: Stored XSS to root RCE via OpenVPN client common_name in status views
OPNsense is a FreeBSD based firewall and routing platform. Prior to version 26.1.11, the OpenVPN connection-status dashboard widget in src/opnsense/www/js/widgets/OpenVPNClients.js and the connection-status view place a client commonname into data-common-name attributes without quote-safe encoding. Exploitation requires an OpenVPN server configured with username-as-common-name and RADIUS or LDAP authentication, plus the ability to provision or self-register a valid backend username containing a double quote; deployments where the same administrator controls both the identity backend and firewall do not cross a separate trust boundary. An authenticated client using that username can close the attribute and add an event handler, while the local user database is not affected because its username validator rejects quotes. Script executes in an administrator's session when the administrator opens the dashboard or connection-status page and the injected event is triggered; the demonstrated payload used pointer movement over the client row rather than unconditional page-load execution. The advisory demonstrates that the script can read config.xml, invoke privileged APIs, reset the root password, and obtain root command execution. This issue is fixed in version 26.1.11.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
OPNsenseto a version that resolves this vulnerability.Fixed in 26.1.11
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Exposure requires an OpenVPN server configured to use username-as-common-name with RADIUS or LDAP authentication. The attacker must be able to provision or self-register a valid backend username containing a double quote; local OPNsense user accounts are not affected because their username validator rejects quotes.
What interaction is required for exploitation?
A client must authenticate to OpenVPN using the crafted username, and an administrator must open the dashboard or connection-status page. The demonstrated payload also required pointer movement over the affected client row rather than executing automatically at page load.
What is the practical impact if exploitation succeeds?
The injected script runs in the administrator's session. The advisory demonstrates access to config.xml, invocation of privileged APIs, and reset of the root password, resulting in root-level compromise.
Are environments managed by the same administrator for both the identity backend and firewall affected across a trust boundary?
No separate trust boundary exists where the same administrator controls both the identity backend and the firewall. The described cross-boundary risk applies when a party able to create backend usernames is distinct from the firewall administrator.