De onderhoudsrelease 2.7.8 van OpenVPN (openbare discussie gedateerd 7 oktober 2026) bundelt drie CVE-getagde fixes plus een tls-crypt-v2-robuustheidswijziging die bewust geen CVE-ID draagt. Deze beveiligingsnotitie verbindt de primaire advisories, zodat operators Windows- en Android-clients, certificaattooling en multi-client DCO-servers kunnen prioriteren zonder marketingblogs als enige bron van waarheid te behandelen.

Encrypt-then-MAC authenticated encryption construction diagram
Bron: Wikimedia Commons (RokerHRO) — Geauthenticeerde versleuteling EtM

Primaire bronnen

CVE-2026-88964 — underflow bij domain search

De communitywiki stelt dat een integer-underflow in OpenVPN op Windows en Android het voor op afstand geauthenticeerde servers mogelijk maakt denial of service of geheugendisclosure te veroorzaken via gemanipuleerde domain search-opties in de PUSH_REPLY-verwerking. Dat is een klassieke bugklasse van “vertrouwde peer, vijandige opties”: authenticatie is al geslaagd, maar het parseren van opties vertrouwde de lengte-aritmetiek nog te ver. De impact is denial of service en mogelijke geheugendisclosure, geen claim van vrije remote code execution in de openbare wikitekst. De fix wordt meegeleverd in 2.7.8.

Verdedigers moeten aannemen dat elke client die zich nog op 2.7.7 of eerder in het getroffen venster bevindt, blootgesteld blijft bij verbinding met een vijandig-maar-geauthenticeerd eindpunt, inclusief gecompromitteerde enterprise-concentrators en slecht gecontroleerde labservers. De voorwaarde is makkelijk verkeerd te begrijpen: dit is geen ongeauthenticeerde vreemde die pakketten op een willekeurige client afvuurt. Het vereist dat de client de peer al voldoende vertrouwt om authenticatie te voltooien en PUSH_REPLY-opties te accepteren. Gecompromitteerde concentrators, kwaadaardige testlabs en verkeerd uitgegeven profielen blijven realistische paden. Blaas het advies niet op tot een narratief over ongeauthenticeerde remote code execution dat de OpenVPN-wiki niet claimt.

CVE-2026-84790 — NULL-bytes in certificaatsubjecten

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

Linux Compatible meldt dat certificaten met ingesloten NULL-bytes in subject-strings nu worden geweigerd. OpenSSL-builds liepen eerder het risico op parsers die stoppen bij de eerste NULL-byte; mbedTLS-builds wezen dergelijke certificaten al af. Vivek Parikh van BreachX meldde het probleem; Max Fillinger implementeerde de fix. Operationele impact: gearchiveerde of kwaadaardig vervaardigde certificaten die ooit “werkten” op OpenSSL kunnen na de upgrade falen. Teams voor certificaattooling moeten inventarissen scannen vóór een massa-uitrol en plotselinge handshake-fouten na 2.7.8 behandelen als een signaal van certificaathygiëne in plaats van een willekeurige netwerkstoring.

Die weigering kan ook legacy-tooling breken die per ongeluk NUL-tekens insluit tijdens het genereren van subject-strings. De breuk is wenselijk vanuit het oogpunt van parser-veiligheid, maar change-windows hebben een inventarisatiestap nodig. Koppel de OpenVPN-upgrade aan controles van certificaattekst of enterprise-PKI-rapporten die niet-afdrukbare bytes in subjects markeren voordat de uitrol als voltooid wordt verklaard.

CVE-2026-84256 — Windows CreateProcess-quoting

Versie 2.7.8 zet de hardening voort rond Windows command-line quoting, zodat tekens die speciaal zijn voor cmd.exe geen variabele-expansie kunnen triggeren binnen aangehaalde argumenten. Lev Stipakov implementeerde het werk; Darren Carreras meldde het. Hetzelfde CVE-nummer werd deels aangepakt in 2.7.7, dus 2.7.8 is een tweede ronde op hetzelfde pad in plaats van een niet-gerelateerde Windows-bug. Scripts die OpenVPN op Windows via een shell aanroepen, verdienen regressietests na de upgrade, vooral wanneer ze door de gebruiker gecontroleerde profielpaden of helperargumenten via CreateProcess doorgeven.

tls-crypt-v2-robuustheid zonder CVE

Tijdens tls-crypt-v2-handshakes kon OpenVPN proberen een gewrapte clientsleutel toe te voegen, zelfs wanneer er geen sleutelmateriaal beschikbaar was, en daarbij een resend-verzoek van een peer te ver vertrouwen. De wijziging in 2.7.8 stopt dat blinde vertrouwen. Volgens de richtlijnen van Italy’s Computer Resilience Agency, zoals doorgegeven door Linux Compatible, werd “malicious server can stop the client from working properly” behandeld als degradatie van de robuustheid in plaats van een CVE voor vertrouwelijkheid of integriteit. Operators moeten het toch installeren: availability-aanvallen tegen VPN-clients zijn operationeel duur, zelfs wanneer ze geen CVE-uiterlijk hebben, en change-managementsystemen moeten hardening zonder CVE expliciet bijhouden.

De ontbrekende identifier illustreert een bredere les voor VPN-beveiligingsprogramma’s. Beleid dat CVE-ID’s weglaat voor zuivere availability-problemen tegen al geauthenticeerde peers, verbergt een deel van 2.7.8 tenzij operators expliciete robuustheidsitems registreren. De write-up van Linux Compatible van 7 October 2026 is nuttige secundaire context, maar changetickets moeten nog steeds de OpenVPN ReleaseHistory- en CVE-wikipagina’s als primair bewijs linken.

Aangrenzend availability-werk dat operators niet mogen negeren

Naast de CVE-lijst wijzigt 2.7.8 het gedrag van multi-client en data-channel offload. Per-client routes worden verwijderd op het werkelijke exit-moment in plaats van tijdens vertraagde multi-instance cleanup, waarmee een race wordt opgelost die systemen zonder routes kon achterlaten. Een toegewijde netlink-socket scheidt synchroon werk van asynchrone meldingen. Wanneer een peer- of sleuteloperatie faalt nadat de peer al uit de kernel is verdwenen, herstart OpenVPN een enkele instance in plaats van de hele server te beëindigen. Die availability- en correctheidsfixes zijn minstens zo belangrijk als de CVE’s voor grote servers onder reconnect-stormen, en ze werden deels gemeld door het Access Server-team van OpenVPN Inc. volgens Linux Compatible.

Wat dit niet is

  • Geen WireGuard-advisory. Aparte WireGuard-discussies van October 2026, waaronder LKML handshake-response-patches en Zephyr keepalive-authenticatie CVE-2026-13735, horen in hun eigen notities thuis.
  • Geen marketing uit leveranciers-releasenotes voor een commercieel consumenten-VPN-merk.
  • Geen toestemming om onvertrouwde servers te draaien om de bugklasse van geauthenticeerde servers “te testen”.

In oktober 2026 waren er ook WireGuard-gerelateerde discussies die operators kunnen verwarren met OpenVPN-patches. De LKML-handshake-response-thread en NVD’s CVE-2026-13735 Zephyr-keepalive-issue zijn echt, maar ze patchen OpenVPN 2.7.8 niet, en OpenVPN 2.7.8 verhelpt ze niet. Houd inventarissen gesplitst per binary: community OpenVPN, in-kernel WireGuard, userspace WireGuard, Zephyr-stacks en propriëtaire mobiele VPN-apps. Het mengen van die ontwikkelingslijnen in één “VPN CVE”-spreadsheet is hoe teams de Windows- en Android-OpenVPN-clients missen die CVE-2026-88964 daadwerkelijk noemt.

Checklist voor verdedigers

  1. Inventariseer Windows- en Android-OpenVPN-clients in het 2.7.x-venster en push 2.7.8 of nieuwer.
  2. Scan certificaatstores op ingesloten NULL-bytes voordat OpenSSL-vloten worden geüpgraded.
  3. Oefen DCO- en multi-client-herstarts op een staging-node om wijzigingen in het instance-restart-gedrag op te vangen.
  4. Houd tls-crypt-v2-deployments op gepatchte builds, ook wanneer een fix geen CVE-ID heeft.
  5. Citeer primaire advisories in change tickets in plaats van alleen secundaire blogs.
  6. Scheid OpenVPN-clienttickets van WireGuard-kernel- en Zephyr-tickets.

Kortom: behandel OpenVPN 2.7.8 als een beveiligings- en beschikbaarheidsbundel voor control-channel-parsing, certificaathygiëne, Windows-process quoting en data-channel-offload-stabiliteit op grote servers. Verifieer vervolgens met uw eigen package hashes en staging labs voordat u de CVE-cluster als gesloten verklaart.