VPN-Technologie

OpenVPN 2.7.8 wurde um den 6.–7. Oktober 2026 als Wartungsupdate mit vier Maßnahmen zur Sicherheitshärtung veröffentlicht. Drei tragen CVE-IDs: CVE-2026-84790 (NULL-Bytes in Zertifikats-Subjects), CVE-2026-88964 (vorzeichenloser Underflow in der domain-search-/PUSH_REPLY-Verarbeitung unter Windows und Android für die Versionen 2.7_alpha3 bis 2.7.7) und CVE-2026-84256 (fortgesetzte Härtung des CreateProcess/cmd.exe-Quotings unter Windows). Eine vierte tls-crypt-v2-Änderung, die Clients daran hindert, umhüllte Schlüssel blind erneut zu senden, wenn kein Schlüsselmaterial verfügbar ist, blieb gemäß der Robustheitsrichtlinie des italienischen CRA ohne CVE. Die Veröffentlichung verbessert außerdem die Stabilität von Multi-Client-DCO, einschließlich des Neustarts einer einzelnen Instanz statt eines Absturzes des gesamten Servers, wenn die Installation eines Peer-Schlüssels mit der Entfernung eines Peers in einen Wettlauf gerät. Linux Compatible merkt an, dass die Veröffentlichung von Gert Doering nach etwa 22 Commits über 40 Dateien von 11 Mitwirkenden getaggt wurde und auf der architektonischen Überarbeitung von 2.7.0 im Februar aufsetzt. Betreiber von Multi-Client-Servern oder kernelbeschleunigtem DCO sollten 2.7.8 als Wartungsrelease für Verfügbarkeit und Sicherheit und nicht als Feature-Drop behandeln. Teams für Zertifikatswerkzeuge müssen Subject-Zeichenketten auf eingebettete NULL-Bytes inventarisieren, bevor OpenSSL-Flotten aktualisiert werden, weil zuvor akzeptierte Zertifikate plötzlich bei Handshake-Prüfungen scheitern können. Windows-Administratoren sollten Skripte, die im Umfeld von OpenVPN über CreateProcess eine Shell starten, nach der fortgesetzten Quoting-Härtung einem Regressionstest unterziehen.

Wenn Sie Community-OpenVPN-2.7.x-Clients unter Windows/Android oder Multi-Client-DCO-Server betreiben, planen Sie 2.7.8 ein und testen Sie Zertifikatsinventuren erneut auf eingebettete NULL-Bytes. Halten Sie Paketversionen und Advisory-URLs im Änderungsticket fest, bevor Sie den Vorgang schließen.

Quelle: Linux Compatible

Die CVE-2026-88964-Seite des OpenVPN-Community-Wikis besagt, dass ein Integer-Underflow remote authentifizierten Servern ermöglicht, über präparierte Domain-Search-Optionen einen Denial of Service oder eine Speicheroffenlegung zu verursachen, nennt Cole Munz als Melder, verlinkt das private GitHub-Issue OpenVPN/openvpn-private-issues#178 und verweist Betreiber auf den ReleaseHistory-Eintrag zu openvpn-2.7.8 vom 7. Oktober 2026. Das Wiki verlinkt außerdem den Community-ReleaseHistory-Anker für openvpn-2.7.8, veröffentlicht am 7. Oktober 2026, sowie den privaten GitHub-Issue-Pfad, der während der koordinierten Offenlegung genutzt wurde. Leser sollten PUSH_REPLY-DNS-Suchdomänen als sensibles Optionsmaterial behandeln: Nur vertrauenswürdige Server dürfen sie pushen, und die About-Bildschirme der Clients sollten nach dem Upgrade erfasst werden, um nachzuweisen, dass 2.7.8 oder neuer auf Windows- und Android-Endpunkten im zuvor betroffenen 2.7.x-Zeitfenster läuft.

Behandeln Sie PUSH_REPLY-DNS-Suchoptionen nur von vertrauenswürdigen Servern und bestätigen Sie, dass die About-Bildschirme der Clients nach dem Upgrade 2.7.8+ anzeigen. Halten Sie Paketversionen und Advisory-URLs im Änderungsticket fest, bevor Sie den Vorgang schließen.

Quelle: OpenVPN-Community-Wiki

Internetsicherheit

Am 5. Oktober 2026 beschrieb eine Diskussion auf der Linux-Kernel-Mailingliste zu einem WireGuard-Noise-Patch einen Fehlermodus, bei dem WireGuard eine alte Handshake-Antwort akzeptieren kann, nachdem eine neuere Initiierung gestartet wurde, wodurch alte Schlüssel neu installiert und Transportzähler sowie der Replay-Zustand zurückgesetzt werden. Das würde Nonce-Wiederverwendung, Replay und Paketfälschung ermöglichen und die Vertraulichkeits- und Integritätsgarantien aufheben. Der vorgeschlagene Fix vergleicht ephemere Geheimnisse unter der Schreibsperre, um Antworten auf ersetzte Initiierungen abzulehnen; Jason A. Donenfeld hinterfragte den genauen Ablauf in einer Antwort im selben Thread. Der Thread betont, dass das Akzeptieren einer veralteten Handshake-Antwort nach Beginn einer neueren Initiierung ältere Schlüssel neu installieren und den Replay-Zustand zurücksetzen kann. Das ist ein Vertraulichkeits- und Integritätsproblem für In-Kernel-WireGuard-Peers, getrennt von Userspace-VPN-Marken-Apps. Distributionen sollten auf stabile Backports überwacht werden; gehen Sie nicht davon aus, dass ein Mailinglisten-Patch bereits in jedem Kernel-Paket Ihrer Flotte enthalten ist.

Kernel- und Distributions-Anwender von WireGuard sollten stabile Backports von Patches zur Ablehnung von Handshake-Antworten beobachten und nicht davon ausgehen, dass Userspace-VPN-Apps allein In-Kernel-WireGuard-Peers abdecken. Halten Sie Paketversionen und Advisory-URLs im Änderungsticket fest, bevor Sie den Vorgang schließen.

Quelle: LKML / IU archive

Der NVD-Eintrag zu CVE-2026-13735 beschreibt einen Implementierungsfehler von WireGuard in Zephyr RTOS: Keepalive-Nachrichten (16 Byte leerer Klartext plus Poly1305-Tag) wurden vor der Entschlüsselung akzeptiert, sodass der Poly1305-Tag nie geprüft wurde. Ein Angreifer, der einen Klartext-Empfängerindex kannte oder per Brute-Force ermittelte, konnte Keepalive-Statussignale ohne Sitzungsschlüssel vortäuschen. Der Fix zwingt 16-Byte-Nutzlasten durch Entschlüsselung und Anti-Replay-Prüfungen. Die Auswirkungen beschränken sich auf die Integrität von Statussignalen, nicht auf Klartextinjektion oder Sitzungsübernahme. Die NVD-Beschreibung stellt klar, dass gefälschte Keepalives nach dem Fix die Poly1305-Prüfung nicht bestehen und als Authentifizierungsfehler gezählt werden. Im Pfad vor dem Fix wird kein Klartext entschlüsselt oder eingeschleust, und Endpunkte sowie Liveness-Timer wurden durch den frühen Rücksprung nicht aktualisiert; Traffic-Injektion und Sitzungsübernahme liegen daher außerhalb des Geltungsbereichs dieses konkreten Fehlers. Produktsicherheitsteams sollten dennoch patchen, weil vorgetäuschte VPN-Connected-Signale Management-Ebenen und Betreiber in die Irre führen können.

Eingebettete/IoT-Produkte, die Zephyr WireGuard ausliefern, sollten den Fix für authentifizierte Keepalives übernehmen und diese CVE nicht mit WireGuard im Linux-Kernel gleichsetzen. Paketversionen und Advisory-URLs vor dem Schließen des Vorgangs im Change-Ticket dokumentieren.

Quelle: NVD — CVE-2026-13735

Regulierung

Der Bericht von Linux Compatible zu 2.7.8 merkt an, dass die Leitlinien der italienischen Computer Resilience Agency (CRA) als Grund dafür angeführt wurden, dass eine Korrektur zur Client-Störung bei tls-crypt-v2 keine CVE erhielt: Ein böswilliger Server, der einen Client am ordnungsgemäßen Funktionieren hindert, wurde als Robustheitsverschlechterung und nicht als Vertraulichkeits- oder Integritätsversagen eingestuft. Diese Richtlinienentscheidung hebt den betrieblichen Patchbedarf nicht auf, ändert aber, wie Compliance-Ticketingsysteme die Änderung kennzeichnen können. Sicherheitsprogramme, die Tickets nur bei vorhandener CVE-ID eröffnen, übersehen diese Änderungsklasse, sofern die Prüfung der Release Notes nicht Teil des Aufnahmeprozesses ist. Dokumentieren Sie die CRA-Begründung im Tickettext und verlangen Sie weiterhin eine Staging-Verifikation für tls-crypt-v2-Clients nach 2.7.8, denn Verfügbarkeitsausfälle gegenüber authentifizierten Peers bleiben in der Incident Response teuer.

Sicherheitsprogramme sollten Robustheitskorrekturen ohne CVE in VPN-Clients nachverfolgen, wenn Richtlinien im CRA-Stil Kennungen weglassen. Erfassen Sie Paketversionen und Advisory-URLs im Änderungsticket, bevor Sie den Vorgang schließen.

Quelle: Linux Compatible

Foren

Der öffentliche CVE-Wiki-Eintrag von OpenVPN zu 88964 verlinkt den privaten GitHub-Issue-Tracker-Pfad OpenVPN/openvpn-private-issues#178 und den Community-ReleaseHistory-Anker für 2.7.8 und veranschaulicht das Muster des Projekts, Meldernamen und Nummern privater Issues neben den Release Notes zu veröffentlichen statt stiller Patches. Der Einstieg über projekteigene Sicherheitsankündigungsseiten verringert das Risiko, unvollständigen sekundären Zusammenfassungen hinterherzujagen. Gegenprüfen Sie Meldernamen, Referenzen privater Issues und ReleaseHistory-Anker, bevor Sie Schwachstellentickets als mitigiert schließen.

Beim Triagieren von VPN-CVEs beginnen Sie beim eigenen Sicherheitsankündigungs-Wiki des Projekts und bei ReleaseHistory-Ankern, bevor Sie sekundäre Aggregatoren heranziehen. Erfassen Sie Paketversionen und Advisory-URLs im Änderungsticket, bevor Sie den Vorgang schließen.

Quelle: OpenVPN-Community-Wiki

Anbieter

Linux Compatible berichtet, dass das Access Server-Team von OpenVPN Inc. den in 2.7.8 behobenen iroute-Race-Bug gemeldet hat, bei dem clientbezogene Routen während einer verzögerten Multi-Instanz-Bereinigung entfernt wurden statt zum tatsächlichen Client-Austrittszeitpunkt, wodurch Systeme bei Reconnect-Races ohne Routen zurückbleiben konnten. Derselbe Artikel merkt an, dass externe Forschungsgruppen wie BreachX (Zertifikat-NULL-byte-Bericht) die Sicherheitskadenz von 2.7.x speisen. Staging sollte Reconnect-Stürme umfassen, die Installation und Entfernung von Routen üben, während Clients flattern. Verschwinden Routen nach dem Upgrade unter Last, erfassen Sie netlink- und Instanzprotokolle, bevor Sie weiter ausrollen. Die Beteiligung von BreachX am Zertifikat-NULL-byte-Bericht veranschaulicht zudem, warum externe Forschungspipelines für die 2.7.x-Kadenz von OpenVPN wichtig sind.

Access Server und große DCO-Betreiber sollten das Routenbereinigungsverhalten nach 2.7.8 im Staging prüfen, bevor Produktionswellen folgen. Erfassen Sie Paketversionen und Advisory-URLs im Änderungsticket, bevor Sie den Vorgang schließen.

Quelle: Linux Compatible