OpenVPN 2.7.8 korrigiert Zertifikats- und Windows-Probleme
OpenVPN 2.7.8 korrigiert Identitätsprüfungen, Windows-Befehlsargumente und DNS-Suchoptionen. Die Angriffspfade unterscheiden sich; neue Zertifikatsregeln können bestehende Verbindungen beeinträchtigen.
OpenVPN 2.7.8 ist am 7. Oktober 2026 erschienen und korrigiert Sicherheitsprobleme bei Zertifikaten, Windows-Befehlsargumenten und übertragenen DNS-Suchdomänen. Admins sollten heute Version, TLS-Bibliothek und Windows-Skripteinbindung inventarisieren und das Update zeitnah vorbereiten. Besonders relevant sind OpenSSL-basierte Installationen mit zertifikatsabhängiger Identitätsprüfung sowie Windows- und Android-Clients der 2.7-Reihe.
Die Quellen belegen keine aktive Ausnutzung. Ohne auffällige Gegenstellen oder Zertifikate ist ein vorbereitetes Wartungsfenster angemessen; risikoreiche Konfigurationen gehören zuerst geprüft. mbedTLS-Builds lehnten Zertifikate mit eingebetteten Nullbytes bereits ab. Linux-Systeme sind nicht vom Windows-spezifischen Aufrufproblem betroffen. Andere VPN-Produkte sind durch diese Meldung nicht automatisch gefährdet.
Was ist passiert?
Das Projekt veröffentlichte Version 2.7.8 auf GitHub um 14:18 UTC, entsprechend 16:18 Uhr deutscher Sommerzeit. Linuxiac berichtete am selben Tag. Neben drei mit CVE bezeichneten Korrekturen enthält das Release Verbesserungen für Data Channel Offload, kurz DCO, und die Zuverlässigkeit von Mehrbenutzerservern. Die Windows-Korrektur erweitert eine bereits in 2.7.7 behandelte Fehlerklasse.
Zertifikate: Identität statt bloßer Verschlüsselung
CVE-2026-84790 betrifft laut Projekt OpenVPN 2.3.0 bis 2.7.7. Authentifizierte entfernte Nutzer können über präparierte Subject-Felder eines Zertifikats andere Identitäten vortäuschen. Version 2.7.8 verwirft Zertifikate mit eingebetteten Nullbytes als ungültig. Das ist eine Korrektur der Identitätsprüfung, kein Beleg für unauthentifizierte Codeausführung auf jedem VPN-Gateway.
Bei OpenSSL-Builds kann die strengere Prüfung bestehende Verbindungen unterbrechen, wenn solche Zertifikate tatsächlich eingesetzt werden. Die Prüfung der eigenen Zertifikatsausstellung gehört deshalb zur Aktualisierung. Zusätzlich vereinheitlicht das Projekt doppelte Subject-Felder: Bei mehreren Common Names verwendete OpenSSL das letzte Feld, mbedTLS das erste. Künftig folgt auch mbedTLS dem Verhalten von OpenSSL.
Windows und DNS-Optionen getrennt bewerten
Unter CVE-2026-84256 verhindert 2.7.8, dass cmd.exe Variablen innerhalb zitierter Argumente expandiert. Das ältere Hersteller-Advisory beschreibt eine Kombination aus Validierungsskript und einer bösartigen Zertifizierungsstelle und nennt 2.7.7 als damaligen Fix. Die neue Korrektur ist daher als zusätzliche Absicherung derselben CVE einzuordnen. Die dortigen Versionsgrenzen dürfen nicht ungeprüft als vollständige Bewertung dieser Nachbesserung gelten.
CVE-2026-88964 betrifft dagegen Windows und Android mit OpenVPN 2.7_alpha3 bis 2.7.7. Ein authentifizierter bösartiger Server kann laut Projekt durch manipulierte Domain-Suchoptionen einen Integer-Unterlauf auslösen. Als Folgen nennt das Advisory Dienstverweigerung oder Speicheroffenlegung. Das Risiko liegt hier beim verbindenden Client, nicht pauschal beim öffentlich erreichbaren VPN-Server.
Wie kritisch ist das?
Die Angriffspfade unterscheiden sich: Identitätsvortäuschung über Zertifikatsfelder, Windows-Skriptverarbeitung und manipulierte Optionen einer authentifizierten Gegenstelle. Ein gemeinsames Etikett wie „kritische Remote-Lücke für alle“ wäre irreführend. Für die neuen Zertifikats- und DNS-Korrekturen nennen die ausgewerteten Projekttexte keinen CVSS-Wert; ein Gesamtwert für das Release wäre ohnehin nicht sinnvoll.
Die Quellenlage hat eine konkrete Unschärfe: Der GitHub-Release-Text bezeichnet den Unterlauf als CVE-2026-88964, verlinkt aber CVE-2026-84964. Letztere gehört laut CVE-Datensatz zu MongoDB. Hier ist das passende OpenVPN-Advisory maßgeblich. Die neuen CVE-IDs waren beim Abruf über die öffentliche CVE-API noch nicht verfügbar; die technischen Aussagen stammen direkt vom Projekt.
Was sollten Admins jetzt tun?
- Zuerst OpenVPN-Versionen, Paket-Patchstand, Plattformen und verwendete TLS-Bibliothek im Bestand erfassen.
- OpenSSL-Installationen mit zertifikatsabhängiger Benutzerzuordnung priorisieren und ungewöhnliche Subject-Felder prüfen.
- Windows-Validierungsskripte und deren Argumente erfassen; 2.7.7 nicht als Endpunkt der neuen Absicherung behandeln.
- Windows- und Android-Clients der betroffenen 2.7-Versionen sowie ihre VPN-Gegenstellen gezielt prüfen.
- Unterstützte Herstellerpakete bevorzugen und deren Sicherheitsinformationen mit dem Upstream-Release abgleichen.
- Konfiguration und Zertifikate sichern; für VPN-Gateways einen vom Tunnel unabhängigen Administrationszugang vorhalten.
- Nach dem Update neue Verbindungen, Zertifikatszuordnung, DNS-Suchdomänen und benötigte Routen kontrollieren.
- Fehlgeschlagene Handshakes und Verbindungsabbrüche untersuchen, ohne jeden Fehler als Angriff zu interpretieren.
Auch die Verfügbarkeit verbessert sich
DCO entfernt interne Routen nun bereits beim Client-Ausstieg, damit schnelle Wiederverbindungen nicht mit verzögerter Bereinigung kollidieren. Unter Linux werden synchrone Netlink-Aufrufe und asynchrone Meldungen getrennt. Fehler beim Anlegen von Peers oder Schlüsseln sollen unter Linux und Windows nur die betroffene Client-Instanz neu starten, statt den gesamten Server zu beenden. Für Unternehmen mit vielen gleichzeitigen Fernzugängen ist das zusätzlich zum Sicherheitsnutzen betriebsrelevant.
Passende Anleitungen auf S-EDV
- TLS-Zertifikate mit certbot verwalten: Hintergrund zu Zertifikatsbetrieb und Erneuerung. Webserver-Zertifikate ersetzen dabei keine OpenVPN-Benutzerzertifikate.
- Standortvernetzung mit WireGuard und IPsec auf OPNsense: Hintergrund für die getrennte Bewertung anderer VPN-Strecken, kein OpenVPN-Patchverfahren.
