VPN-technologie

OpenVPN 2.7.8 is rond 6–7 oktober 2026 uitgebracht als onderhoudsupdate met vier beveiligingsverstevigingen. Drie dragen CVE-ID's: CVE-2026-84790 (NULL-bytes in certificaatsubjects), CVE-2026-88964 (unsigned underflow in de domain-search-/PUSH_REPLY-afhandeling op Windows en Android voor versies 2.7_alpha3 tot en met 2.7.7) en CVE-2026-84256 (voortgezette quoting-versteviging van Windows CreateProcess/cmd.exe). Een vierde tls-crypt-v2-wijziging die voorkomt dat clients wrapped keys blindelings opnieuw verzenden wanneer er geen sleutelmateriaal beschikbaar is, bleef zonder CVE onder het Italiaanse CRA-robustheidsbeleid. De release verbetert ook de multi-client-DCO-stabiliteit, waaronder het herstarten van één instantie in plaats van de hele server te laten crashen wanneer het installeren van een peersleutel een race condition heeft met het verwijderen van een peer. Linux Compatible merkt op dat de release is getagd door Gert Doering na ongeveer 22 commits in 40 bestanden van 11 bijdragers, voortbouwend op de architecturale overhaul van 2.7.0 uit februari. Beheerders die multi-clientservers of kernelversnelde DCO draaien, moeten 2.7.8 behandelen als een onderhoudsrelease voor beschikbaarheid en beveiliging, niet als een feature drop. Teams voor certificaattooling moeten subjectstrings inventariseren op ingesloten NULL-bytes voordat OpenSSL-vloten upgraden, omdat eerder geaccepteerde certificaten plotseling kunnen falen bij handshakecontroles. Windows-beheerders moeten scripts die via CreateProcess rond OpenVPN een shell starten, na de voortgezette quoting-versteviging regression-testen.

Als u community-OpenVPN 2.7.x-clients op Windows/Android of multi-client-DCO-servers draait, plan 2.7.8 in en test certificateninventarissen opnieuw op ingesloten NULL-bytes. Noteer pakketversies en advisory-URL's in het wijzigingsticket voordat u het item sluit.

Bron: Linux Compatible

De CVE-2026-88964-pagina van de OpenVPN-communitywiki stelt dat een integer underflow het voor externe geauthenticeerde servers mogelijk maakt denial of service of geheugendisclosure te veroorzaken via gemanipuleerde domain search-opties, noemt Cole Munz als melder, linkt naar GitHub private issue OpenVPN/openvpn-private-issues#178 en verwijst beheerders naar het ReleaseHistory-item van openvpn-2.7.8 gedateerd 7 oktober 2026. De wiki linkt ook naar het community-ReleaseHistory-anker voor openvpn-2.7.8, uitgebracht op 7 oktober 2026, en het pad van de private GitHub-issue dat tijdens gecoördineerde disclosure is gebruikt. Lezers moeten PUSH_REPLY-DNS-zoekdomeinen behandelen als gevoelig optiemateriaal: alleen vertrouwde servers mogen ze pushen, en About-schermen van clients moeten na de upgrade worden vastgelegd om te bewijzen dat 2.7.8 of nieuwer draait op Windows- en Android-eindpunten in het eerder getroffen 2.7.x-venster.

Accepteer PUSH_REPLY-DNS-zoekopties alleen van vertrouwde servers en bevestig dat About-schermen van clients na de upgrade 2.7.8+ tonen. Noteer pakketversies en advisory-URL's in het wijzigingsticket voordat u het item sluit.

Bron: OpenVPN community wiki

Internetbeveiliging

Op 5 oktober 2026 beschreef een discussie op de Linux kernel mailing list over een WireGuard-noisepatch een foutmodus waarbij WireGuard een oud handshake-antwoord kan accepteren nadat een nieuwere initiatie is gestart, waarbij oude sleutels opnieuw worden geïnstalleerd en transporttellers en replay-status worden gereset. Dat zou nonce-hergebruik, replay en pakketvervalsing mogelijk maken en de garanties voor vertrouwelijkheid en integriteit doorbreken. De voorgestelde fix vergelijkt ephemeral secrets onder de write lock om antwoorden voor vervangen initiaties te weigeren; Jason A. Donenfeld betwijfelde de exacte flow in een reactie in dezelfde thread. De thread benadrukt dat het accepteren van een verouderd handshake-antwoord nadat een nieuwere initiatie is begonnen, oudere sleutels opnieuw kan installeren en de replay-status kan resetten. Dat is een zorg voor vertrouwelijkheid en integriteit bij in-kernel WireGuard-peers, onderscheiden van userspace-VPN-apps van merken. Distributies moeten worden gevolgd op stable backports; neem niet aan dat een mailinglistpatch al aanwezig is in elk kernelpakket dat uw vloot draait.

Kernel- en distributieconsumenten van WireGuard moeten stable backports van patches voor weigering van handshake-antwoorden volgen en niet aannemen dat userspace-VPN-apps alleen in-kernel-WireGuard-peers dekken. Noteer pakketversies en advisory-URL's in het wijzigingsticket voordat u het item sluit.

Bron: LKML / IU archive

Het NVD-record voor CVE-2026-13735 beschrijft een bug in de WireGuard-implementatie van Zephyr RTOS: keepaliveberichten (16-byte lege plaintext plus Poly1305-tag) werden geaccepteerd vóór decryptie, zodat de Poly1305-tag nooit werd geverifieerd. Een aanvaller die een cleartext receiver index kende of via brute force achterhaalde, kon keepalive-statussignalen nabootsen zonder sessiesleutels. De fix dwingt 16-byte payloads door decryptie en anti-replaycontroles. De impact beperkt zich tot de integriteit van statussignalen, niet tot plaintextinjectie of sessieovername. De NVD-beschrijving verduidelijkt dat vervalste keepalives na de fix de Poly1305-verificatie niet doorstaan en als authenticatiefouten worden geteld. In het pad vóór de fix wordt geen plaintext ontsleuteld of geïnjecteerd, en endpoints en liveness-timers werden niet bijgewerkt door de vroege return, zodat trafficinjectie en sessieovername buiten de scope van dit specifieke defect vallen. Productbeveiligingsteams moeten desondanks patchen, omdat nagebootste VPN-connected-signalen managementvlakken en operators kunnen misleiden.

Embedded/IoT-producten die Zephyr WireGuard meeleveren, moeten de authenticated-keepalive-fix overnemen en deze CVE niet gelijkstellen aan Linux kernel WireGuard. Noteer pakketversies en advisory-URL's in het changeticket voordat het item wordt afgesloten.

Bron: NVD — CVE-2026-13735

Regelgeving

De toelichting van Linux Compatible bij 2.7.8 merkt op dat de richtlijnen van de Italiaanse Computer Resilience Agency (CRA) werden aangehaald als reden waarom een tls-crypt-v2-fix voor clientverstoring geen CVE kreeg: een kwaadaardige server die een client belette correct te functioneren, werd geclassificeerd als degradatie van de robuustheid in plaats van een falen van vertrouwelijkheid of integriteit. Die beleidskeuze neemt de operationele noodzaak om te patchen niet weg, maar verandert wel hoe compliance-ticketsystemen de wijziging kunnen labelen. Beveiligingsprogramma’s die alleen tickets openen wanneer er een CVE-ID bestaat, missen deze klasse van wijzigingen tenzij review van release notes deel uitmaakt van het intakeproces. Documenteer de CRA-rationale in de tickettekst en eis nog steeds stagingverificatie voor tls-crypt-v2-clients na 2.7.8, omdat beschikbaarheidsfouten tegen geauthenticeerde peers duur blijven tijdens incidentrespons.

Beveiligingsprogramma’s moeten non-CVE-robuustheidsfixes in VPN-clients bijhouden wanneer beleidslijnen in CRA-stijl identificatoren weglaten. Leg pakketversies en advisory-URL’s vast in het change-ticket voordat het item wordt gesloten.

Bron: Linux Compatible

Forums

De openbare CVE-wiki-entry van OpenVPN voor 88964 bevat kruisverwijzingen naar het pad van de private GitHub-issuetracker OpenVPN/openvpn-private-issues#178 en het community-ReleaseHistory-anker voor 2.7.8, wat het patroon van het project illustreert om namen van melders en private-issuenummers naast release notes te publiceren in plaats van stille patches. Beginnen bij door het project beheerde beveiligingsaankondigingspagina’s verkleint het risico om onvolledige secundaire samenvattingen na te jagen. Controleer namen van melders, private-issueverwijzingen en ReleaseHistory-ankers kruislings voordat vulnerability-tickets als gemitigeerd worden gesloten.

Bij het triëren van VPN-CVE’s, begin bij de eigen beveiligingsaankondigingswiki van het project en ReleaseHistory-ankers vóór secundaire aggregators. Leg pakketversies en advisory-URL’s vast in het change-ticket voordat het item wordt gesloten.

Bron: OpenVPN community wiki

Leveranciers

Linux Compatible meldt dat het Access Server-team van OpenVPN Inc. de iroute-racebug heeft ingediend die in 2.7.8 is opgelost, waarbij per-client-routes werden verwijderd tijdens vertraagde multi-instance-opschoning in plaats van op het werkelijke moment van client-exit, met het risico dat systemen zonder routes achterblijven bij reconnect-races. Hetzelfde artikel merkt op dat externe onderzoeksgroepen zoals BreachX (certificaat-NULL-byte-rapport) de 2.7.x-beveiligingscadans voeden. Staging moet reconnect-storms omvatten die route-installatie en -verwijdering oefenen terwijl clients flappen. Als routes onder belasting verdwijnen na de upgrade, leg netlink- en instance-logs vast voordat je verder uitrolt. De betrokkenheid van BreachX bij het certificaat-NULL-byte-rapport illustreert ook waarom externe onderzoekspijplijnen van belang zijn voor de 2.7.x-cadans van OpenVPN.

Access Server en grote DCO-operators moeten het route-opschoningsgedrag op staging valideren na 2.7.8 vóór productiegolven. Leg pakketversies en advisory-URL’s vast in het change-ticket voordat het item wordt gesloten.

Bron: Linux Compatible