Das Wartungsrelease 2.7.8 von OpenVPN (öffentliche Diskussion vom 7. Oktober 2026) bündelt drei CVE-markierte Korrekturen plus eine Robustheitsänderung für tls-crypt-v2, die bewusst keine CVE-ID trägt. Dieser Sicherheitshinweis verknüpft die wichtigsten Advisories, damit Betreiber Windows- und Android-Clients, Zertifikatswerkzeuge und Multi-Client-DCO-Server priorisieren können, ohne Marketing-Blogs als einzige Wahrheitsquelle zu behandeln.

Encrypt-then-MAC authenticated encryption construction diagram
Quelle: Wikimedia Commons (RokerHRO) — Authentifizierte Verschlüsselung EtM

Primärquellen

CVE-2026-88964 — Domain-Search-Unterlauf

Das Community-Wiki stellt fest, dass ein Integer-Unterlauf in OpenVPN unter Windows und Android remote authentifizierten Servern ermöglicht, über präparierte Domain-Search-Optionen in der PUSH_REPLY-Verarbeitung eine Dienstverweigerung oder eine Speicheroffenlegung herbeizuführen. Das ist eine klassische Fehlerklasse „vertrauenswürdiger Peer, feindliche Optionen“: Die Authentifizierung war bereits erfolgreich, dennoch vertraute die Optionsauswertung der Längenarithmetik noch zu weit. Die Auswirkung ist Dienstverweigerung und mögliche Speicheroffenlegung, keine Behauptung einer freien Remote-Codeausführung im öffentlichen Wiki-Text. Der Fix wird in 2.7.8 ausgeliefert.

Verteidiger sollten davon ausgehen, dass jeder Client, der im betroffenen Zeitraum noch auf 2.7.7 oder früher steht, beim Verbinden mit einem feindlichen, aber authentifizierten Endpunkt exponiert bleibt, einschließlich kompromittierter Unternehmens-Konzentratoren und schlecht kontrollierter Laborserver. Die Vorbedingung wird leicht missverstanden: Es handelt sich nicht um einen nicht authentifizierten Fremden, der Pakete auf einen beliebigen Client sprüht. Es setzt voraus, dass der Client dem Peer bereits genug vertraut, um die Authentifizierung abzuschließen und PUSH_REPLY-Optionen anzunehmen. Kompromittierte Konzentratoren, bösartige Testlabore und falsch ausgestellte Profile bleiben realistische Wege. Blähen Sie die Advisory nicht zu einer Erzählung über nicht authentifizierte Remote-Codeausführung auf, die das OpenVPN-Wiki nicht behauptet.

CVE-2026-84790 — NULL-Bytes in Zertifikatssubjekten

Padlock symbol representing encrypted network traffic
Quelle: Wikimedia Commons — Padlock.svg

Linux Compatible berichtet, dass Zertifikate mit eingebetteten NULL-Bytes in Subject-Zeichenketten nun abgelehnt werden. OpenSSL-Builds riskierten zuvor Parser, die am ersten NULL-Byte anhalten; mbedTLS-Builds haben solche Zertifikate bereits abgelehnt. Vivek Parikh von BreachX hat das Problem gemeldet; Max Fillinger hat die Korrektur umgesetzt. Operative Auswirkung: Archivierte oder böswillig erstellte Zertifikate, die unter OpenSSL einst „funktionierten“, können nach dem Upgrade fehlschlagen. Teams für Zertifikatswerkzeuge sollten Bestände vor einer Massenausrollung scannen und plötzliche Handshake-Fehler nach 2.7.8 als Signal für Zertifikatshygiene behandeln, nicht als zufällige Netzwerkstörung.

Diese Ablehnung kann auch Legacy-Werkzeuge beeinträchtigen, die beim Erzeugen von Subject-Zeichenketten versehentlich NUL-Zeichen eingebettet haben. Der Bruch ist aus Parser-Sicherheitssicht wünschenswert, aber Änderungsfenster benötigen einen Inventarisierungsschritt. Kombinieren Sie das OpenVPN-Upgrade mit Prüfungen der Zertifikatstexte oder Enterprise-PKI-Berichten, die nicht druckbare Bytes in Subjects kennzeichnen, bevor Sie die Ausrollung für abgeschlossen erklären.

CVE-2026-84256 — Windows-CreateProcess-Quoting

Version 2.7.8 setzt die Härtung rund um das Windows-Befehlszeilen-Quoting fort, damit für cmd.exe besondere Zeichen innerhalb in Anführungszeichen gesetzter Argumente keine Variablenexpansion auslösen können. Lev Stipakov hat die Arbeit umgesetzt; Darren Carreras hat sie gemeldet. Dieselbe CVE-Nummer wurde in 2.7.7 teilweise behandelt, daher ist 2.7.8 ein zweiter Durchgang auf demselben Pfad und kein unzusammenhängender Windows-Fehler. Skripte, die unter Windows rund um OpenVPN eine Shell aufrufen, verdienen nach dem Upgrade Regressionstests, insbesondere wenn sie benutzergesteuerte Profilpfade oder Hilfsargumente über CreateProcess übergeben.

tls-crypt-v2-Robustheit ohne CVE

Während tls-crypt-v2-Handshakes konnte OpenVPN versuchen, einen umhüllten Client-Schlüssel hinzuzufügen, selbst wenn kein Schlüsselmaterial verfügbar war, und einer erneuten Sendeanfrage des Peers zu weit vertrauen. Die Änderung in 2.7.8 beendet dieses blinde Vertrauen. Laut Leitlinien der italienischen Computer Resilience Agency, wie von Linux Compatible weitergegeben, wurde „ein bösartiger Server kann den Client daran hindern, ordnungsgemäß zu funktionieren“ als Robustheitsverschlechterung und nicht als Vertraulichkeits- oder Integritäts-CVE behandelt. Betreiber sollten sie trotzdem einspielen: Verfügbarkeitsangriffe gegen VPN-Clients sind betrieblich teuer, auch wenn ihnen das CVE-Gepräge fehlt, und Change-Management-Systeme sollten Härtungen ohne CVE ausdrücklich nachverfolgen.

Die fehlende Kennung verdeutlicht eine umfassendere Lehre für VPN-Sicherheitsprogramme. Richtlinien, die CVE-IDs bei reinen Verfügbarkeitsproblemen gegenüber bereits authentifizierten Peers weglassen, verbergen einen Teil von 2.7.8, es sei denn, Betreiber erfassen ausdrückliche Robustheitspunkte. Der Bericht von Linux Compatible vom 7. Oktober 2026 ist nützlicher sekundärer Kontext, aber Change-Tickets sollten weiterhin die OpenVPN-ReleaseHistory- und CVE-Wiki-Seiten als primäre Belege verlinken.

Benachbarte Verfügbarkeitsarbeiten, die Betreiber nicht ignorieren sollten

Über die CVE-Liste hinaus ändert 2.7.8 das Multi-Client- und Data-Channel-Offload-Verhalten. Routen pro Client werden zum tatsächlichen Beendigungszeitpunkt entfernt, nicht während der verzögerten Multi-Instanz-Bereinigung, und beheben damit eine Race Condition, die Systeme ohne Routen hinterlassen konnte. Ein eigener Netlink-Socket trennt synchrone Arbeit von asynchronen Benachrichtigungen. Wenn eine Peer- oder Schlüsseloperation fehlschlägt, nachdem der Peer bereits aus dem Kernel verschwunden ist, startet OpenVPN eine einzelne Instanz neu, anstatt den gesamten Server zu beenden. Diese Verfügbarkeits- und Korrektheitskorrekturen sind für große Server unter Wiederverbindungsstürmen ebenso wichtig wie die CVEs und wurden laut Linux Compatible teilweise vom Access Server-Team von OpenVPN Inc. gemeldet.

Was dies nicht ist

  • Kein WireGuard-Advisory. Separate WireGuard-Diskussionen vom Oktober 2026, einschließlich LKML-Handshake-Response-Patches und der Zephyr-Keepalive-Authentifizierung CVE-2026-13735, gehören in eigene Notizen.
  • Kein Marketing in Form von Anbieter-Release-Notes für eine kommerzielle Consumer-VPN-Marke.
  • Keine Erlaubnis, nicht vertrauenswürdige Server zu betreiben, um die Fehlerklasse authentifizierter Server „zu testen“.

Im Oktober 2026 gab es außerdem WireGuard-bezogene Diskussionen, die Betreiber mit OpenVPN-Patches verwechseln können. Der LKML-Thread zur Handshake-Antwort und das Zephyr-Keepalive-Problem CVE-2026-13735 bei NVD sind real, aber sie patchen nicht OpenVPN 2.7.8, und OpenVPN 2.7.8 behebt sie nicht. Halten Sie Inventare nach Binärdatei getrennt: Community-OpenVPN, In-Kernel-WireGuard, Userspace-WireGuard, Zephyr-Stacks und proprietäre mobile VPN-Apps. Das Vermischen dieser Abstammungslinien in einer einzigen „VPN CVE“-Tabelle führt dazu, dass Teams die Windows- und Android-OpenVPN-Clients übersehen, die CVE-2026-88964 tatsächlich nennt.

Checkliste für Verteidiger

  1. Inventarisieren Sie Windows- und Android-OpenVPN-Clients im 2.7.x-Fenster und spielen Sie 2.7.8 oder neuer aus.
  2. Durchsuchen Sie Zertifikatspeicher auf eingebettete NULL-Bytes, bevor OpenSSL-Flotten aktualisiert werden.
  3. Proben Sie DCO- und Multi-Client-Neustarts auf einem Staging-Knoten, um Verhaltensänderungen beim Instanzneustart aufzufangen.
  4. Halten Sie tls-crypt-v2-Deployments auf gepatchten Builds, auch wenn ein Fix keine CVE-ID hat.
  5. Verweisen Sie in Change-Tickets auf primäre Advisories statt allein auf sekundäre Blogs.
  6. Trennen Sie OpenVPN-Client-Tickets von WireGuard-Kernel- und Zephyr-Tickets.

Fazit: Behandeln Sie OpenVPN 2.7.8 als Sicherheits- und Verfügbarkeitspaket für Control-Channel-Parsing, Zertifikatshygiene, Windows-Prozessquoting und die Stabilität des Data-Channel-Offloads auf großen Servern. Verifizieren Sie anschließend mit eigenen Paket-Hashes und Staging-Labs, bevor Sie den CVE-Cluster als geschlossen erklären.