CRLF injection into privileged service configuration in OPNsense Core

OPNsense is a FreeBSD based firewall and routing platform. Prior to 26.1.11 and 26.4.1p1, authenticated Web UI or API users with delegated access to affected settings can submit CR or LF characters in fields expected to contain one line, causing generated privileged service configuration files to contain additional attacker-controlled directives or policy lines. The confirmed Dnsmasq path includes dhcp_boot.filename, dhcp_boot.servername, dhcp_boot.address, and dhcp_options.value, which are rendered into /usr/local/etc/dnsmasq.conf; access through page-services-dnsforwarder covers api/dnsmasq/*. Related affected fields span OpenVPN, DHCPv6, Unbound, IPsec, NTP, PPP or MPD, Monit, firewall, sudo, WebGUI, and System General configuration. Applying or restarting the affected service can alter behavior beyond the delegated setting, create service-side files, cross RBAC boundaries, or cause denial of service. Line injection through Monit mail password and adjacent Monit text fields into /usr/local/etc/monitrc demonstrated root command execution. Arbitrary shell command execution was not confirmed for the Dnsmasq path. This issue is fixed in versions 26.1.11 and 26.4.1p1.

• OPNsense Core, 26.1 branch: affected before 26.1.11, corresponding to versions through 26.1.10 according to the CNA advisory. Fixed in 26.1.11.
• OPNsense Core, 26.4 branch: the CNA advisory identifies versions through 26.4.1 as affected. Fixed in 26.4.1p1.
• Confirmed fields include the Dnsmasq DHCP boot and DHCP option paths. The advisory also lists related fields in OpenVPN, DHCPv6, Unbound, IPsec, NTP, PPP or MPD, Monit, firewall, sudo, WebGUI, and System General configuration.
• The status of release branches or parallel versions not covered by these boundaries is not established here.

The flaw exists because several input fields are modeled as ordinary text even though they are later written directly into line-oriented configuration files. When a user places CR or LF characters in a value expected to contain one line, the value can terminate the intended configuration line and create additional attacker-controlled directives or policy lines in a privileged service configuration.

In the confirmed Dnsmasq path, dhcp_boot.filename, dhcp_boot.servername, dhcp_boot.address, and dhcp_options.value are rendered into /usr/local/etc/dnsmasq.conf. The relevant access includes the page-services-dnsforwarder ACL and APIs under api/dnsmasq/*. The template writes these values directly after Dnsmasq directives, while the fields do not receive sufficient single-line validation before storage.

The attack requires an authenticated Web UI or API account with delegated permission to configure an affected component, plus the ability to apply or restart the service so that the generated configuration is loaded. The same pattern is documented for OpenVPN, DHCPv6, Unbound, IPsec, NTP, PPP or MPD, Monit, firewall, sudo, WebGUI, and System General configuration, but the exact result depends on each service's syntax and behavior. Arbitrary shell execution was not confirmed for the Dnsmasq path; the Monit path demonstrated command execution with root privileges.

The vulnerability is reachable through the management Web UI or API, so exposure depends on access to the OPNsense management plane. The attacker must already have an authenticated account with delegated access to affected settings. No separate victim interaction is described; the authenticated user performs the configuration change and, depending on the service, applies or restarts it.

The operation is described as low complexity because ordinary text input is accepted and then inserted into generated configuration files. The advisory documents dynamic validation in a local virtual machine, including the Dnsmasq path and service-side file creation. The supplied record and consulted advisory do not establish an active campaign or a public exploit; this should not be interpreted as proof that exploitation has not occurred.

This is an authenticated configuration injection flaw in which user-controlled data is written to privileged service configuration files without being constrained to a single line. The technical result can be changed service behavior, file creation within the service's writable context, service startup failure, or policy changes beyond the delegated authorization boundary.

• For Dnsmasq, confirmed consequences include injecting additional directives into /usr/local/etc/dnsmasq.conf, creating a service-side file, and potentially affecting availability if invalid or conflicting directives are inserted.
• For Monit, injection through the mail password and adjacent text fields into /usr/local/etc/monitrc demonstrated command execution with root privileges.
• Other components may produce different outcomes depending on the accepted directive syntax and service privileges; the Dnsmasq result should not be assumed for every path.
• Arbitrary shell execution was not confirmed for the Dnsmasq path. The record also does not establish a specific data disclosure scenario.

• A user with limited delegated Web UI or API permissions may influence privileged backend configuration beyond the intended authorization scope, weakening OPNsense RBAC boundaries.
• Injected directives or policy lines can change DNS, DHCP, VPN, firewall, sudo, WebGUI, or monitoring behavior, depending on the affected component and the syntax accepted by its service.
• Invalid or conflicting configuration can prevent a service from starting or cause it to stop providing functionality, producing network or management disruption.
• The Dnsmasq path demonstrated creation of a file in a location writable by the service startup or runtime context. The Monit path demonstrated command execution with root privileges.
• The record does not establish a specific data disclosure scenario; the confirmed consequences center on configuration integrity, privilege boundaries, and service availability.

1. Upgrade OPNsense Core to the confirmed fix for the deployed branch: 26.1.11 for the 26.1 branch, or 26.4.1p1 for the 26.4 branch.
2. If upgrading is not immediately possible, temporarily restrict Web UI and API permissions for Dnsmasq and the other configuration areas identified by the advisory. Prioritize delegated or operator accounts that can apply or restart services. This reduces exposure but does not replace the fix.
3. Review and remove unexpected multi-line values from fields rendered into service configuration files. Do not limit the review to Dnsmasq because the issue has multiple configuration paths.
4. After upgrading, regenerate the relevant configurations and verify that the affected services start normally. The advisory describes the corrective approach as rejecting CR and LF in fields intended to be single-line, adding validation that matches the daemon grammar, and using a model-level single-line field type.
5. Review configuration changes and service apply or restart activity from the period when an affected release was deployed. If unexpected directives or policy lines are found, treat the event as a configuration-integrity incident and investigate the account that made the change.

• Inventory systems running OPNsense Core and determine whether they use the affected 26.1 or 26.4 release branch.
• Review groups and roles with permission to configure Dnsmasq, especially access corresponding to page-services-dnsforwarder, together with permissions for OpenVPN, DHCPv6, Unbound, IPsec, NTP, PPP or MPD, Monit, firewall, sudo, WebGUI, and System General settings.
• Inspect generated service configuration files for unexpected directives, policy lines, or multi-line values, including /usr/local/etc/dnsmasq.conf, /usr/local/etc/monitrc, /var/etc/dhcp6c.conf, /var/etc/ntpd.conf, /var/etc/mpd_*.conf, /usr/local/etc/swanctl/swanctl.conf, /usr/local/etc/strongswan.conf, generated php.ini files, and the other configuration sinks identified by the advisory.
• Correlate configuration changes with service apply or restart activity where suitable audit records exist. Treat this as an additional precaution, not as a confirmed indicator.
• No specific IOC is established for this issue. The absence of an unexpected configuration line or log event does not prove that the system was not exploited.