OPNsense core DHCP configuration command injection enables root code execution

OPNsense is a FreeBSD based firewall and routing platform. Prior to 26.1.8, unsanitized user input is passed to the DHCP configuration of the configured interface, which is processed by a shell script, allowing remote code execution as root on the underlying operating system. This vulnerability is fixed in 26.1.8.

• OPNsense core: versions before 26.1.8 are affected; the vendor advisory specifically lists versions <= 26.1.7.
• Patched release: 26.1.8 is identified as patched. The supplied evidence does not separately confirm the status of parallel branches or releases outside this boundary.

OPNsense core builds DHCP configuration for an interface from user-supplied data in src/etc/inc/interfaces.inc without adequately neutralizing the hostname value. The relevant path requires a user with page-interfaces privileges and an interface configured to use IPv4 DHCP. The dhcphostname value is written into dhclient.<device>.conf, after which dhclient invokes /usr/local/opnsense/scripts/interfaces/dhclient-script. The advisory states that crafted input can reach the media environment variable, which is then used with ifconfig in an eval statement without sanitization, creating the CWE-88 argument-injection condition. When configuration changes are applied or the interface makes a later DHCP request, such as after a restart, dhclient processes the configuration and code can execute as root on the firewall. The available evidence confirms the IPv4 DHCP configuration path and does not establish exposure in unrelated configuration paths.

The vulnerability is reachable through the OPNsense network administration interface. An attacker needs an authenticated account with page-interfaces privileges; no additional user interaction is required after the change is submitted, and the supplied assessment describes low attack complexity. Applying an interface change or a subsequent DHCP request can trigger the vulnerable processing. No public exploit is recorded in the supplied record, and the record does not establish confirmed real-world exploitation; that absence of information is not proof that exploitation has not occurred.

Successful exploitation results in remote code execution as root on the OPNsense firewall host. That privilege may allow changes to firewall policy, routing, DHCP, and operating-system services, creating confidentiality, integrity, and availability consequences for the device. Because a firewall commonly sits at a network boundary, control of the device could increase the impact on dependent traffic flows and systems, although the specific downstream scope is not established by the advisory. The evidence does not show that every OPNsense deployment or every DHCP configuration has the same exposure; the documented IPv4 DHCP path is the confirmed scope.

• Successful exploitation can compromise the firewall host with root privileges, affecting the integrity of network configuration and services running on the device.
• An attacker may be able to alter firewall policy, routing, or DHCP behavior, potentially causing outages or diverting network traffic. These are possible consequences of root-level access, not individually confirmed actions in the advisory.
• Data and credentials accessible to the firewall operating system may also be exposed, depending on the deployment configuration.
• The advisory does not identify a specific victim, campaign, or breach, so the actual business impact depends on the firewall's network role and administrative scope.

1. Upgrade OPNsense core to 26.1.8. This is the vendor-confirmed patched release and the most effective action.
2. If an immediate upgrade is not possible, restrict administration interface access and page-interfaces privileges to trusted accounts, and limit the network sources that can reach the interface. This is temporary risk reduction, not a substitute for the fix.
3. Review IPv4 DHCP interfaces and any hostname or advanced DHCP values changed while the system was in the affected branch.
4. After updating, verify the running version and perform the normal configuration validation for the change process to confirm that the system is using the patched component.

• Inventory OPNsense systems and compare the running core version with the vendor's fixed release.
• Identify interfaces using IPv4 DHCP, especially those that allow DHCP hostname configuration or advanced DHCP settings.
• Inspect generated configuration files such as /var/etc/dhclient.<device>.conf for content that differs from approved configuration; absence of suspicious content does not prove that a system is safe.
• Review available audit trails for accounts with page-interfaces privileges, DHCP configuration changes, and the times those changes were applied.
• As a precaution, monitor activity involving dhclient and /usr/local/opnsense/scripts/interfaces/dhclient-script. This is generic defensive monitoring, not a vendor-confirmed indicator of compromise.