OpenSSL heeft op 29 september updates gepubliceerd voor een OpenSSL DTLS-kwetsbaarheid die heap memory kan uitlekken aan de andere kant van een DTLS-verbinding. In andere situaties kan dezelfde fout bovendien een crash veroorzaken. De impact zit daarmee zowel in vertrouwelijkheid als in beschikbaarheid, afhankelijk van hoe je toepassing DTLS gebruikt.
De kwetsbaarheid is geregistreerd als CVE-2026-84782. Alleen software die OpenSSL gebruikt voor DTLS valt onder het probleem; wie TLS alleen op TCP gebruikt, zit niet automatisch in hetzelfde risico.
Wat is DTLS en waarom is dit lastig om te omzeilen?
DTLS is de TLS-variant die is ontworpen voor UDP-verkeer. Omdat UDP geen betrouwbare, geordende levering garandeert, werkt DTLS met een handshake-proces dat berichten opnieuw kan versturen als er geen antwoord komt binnen een timer.
In deze handshake kunnen berichten bovendien worden opgesplitst in fragmenten die passen binnen de grenzen van één UDP-datagram. Dat betekent dat verzending soms tijdelijk kan worden gepauzeerd terwijl een groter handshake-bericht nog niet volledig is verstuurd—en later wordt hervat.
De kern van de OpenSSL DTLS-kwetsbaarheid (CVE-2026-84782)
De fout ontstaat in een scenario waarin een resend (herverzending) start terwijl een groter handshake-bericht nog “half onderweg” is. OpenSSL beschrijft dat de eerder verlate handshake-positie in de buffer dan wordt gebruikt, in plaats van opnieuw vanaf het begin van het bericht te verzenden dat eigenlijk opnieuw moet worden gestuurd.
Het resultaat: het herverzonden bericht krijgt een verkeerd label en bevat in het body-gedeelte restbytes van het grotere bericht. Daardoor kan bij het lezen van dit fout gelabelde bericht heap memory worden meegenomen richting de andere kant, en in sommige gevallen zelfs leiden tot het aanspreken van niet-gemapte geheugenlocaties.
OpenSSL geeft aan dat de verkeerd gelabelde boodschap heap memory kan transporteren als onversleutelde handshake-data. Als de verwerking doorloopt tot ongemapt geheugen, volgt een crash.
Welke gevolgen heeft dit: lek, crash of beide?
OpenSSL beoordeelt de kwetsbaarheid als High—één stap onder Critical. Daarbij is het belangrijk om te beseffen dat de precieze uitkomst afhankelijk is van de timing en de staat van de handshake tijdens de herverzending.
- Confidentiality (vertrouwelijkheid): heap memory kan aan de andere partij worden doorgegeven als onderdeel van handshake-data die niet naar behoren klopt.
- Availability (beschikbaarheid): als het systeem een niet-gemapte geheugenlocatie raakt, kan de applicatie crashen.
Een externe beoordeling vanuit CISA noemde in de context van CVSS een score van 8,2/10. CISA onderscheidde impact: Low voor vertrouwelijkheid en High voor beschikbaarheid, en vermeldde dat exploitatie op dat moment nog niet bekend was. OpenSSL benadrukt overigens dat hun eigen prioritering niet puur op CVSS-score is gebaseerd.
Voor wie geldt dit precies?
De fout is niet beperkt tot één rol in een DTLS-verbinding. OpenSSL geeft aan dat de fix is getest voor zowel DTLS clients als DTLS servers.
Software is alleen blootgesteld als ze OpenSSL gebruikt voor DTLS. DTLS wordt bijvoorbeeld toegepast om WebRTC data channels te beveiligen en om encryptiesleutels op te zetten voor internetgesprekken.
OpenSSL heeft niet publiek gemaakt of een aanvaller dit probleem altijd kan triggeren door op het juiste moment herverzendingen af te dwingen, en er zijn bij de publicatie ook geen gerapporteerde aanvallen die de kwetsbaarheid actief misbruiken.
Welke OpenSSL-versies zijn kwetsbaar en welke zijn gefixt?
OpenSSL noemt de volgende fixed versies voor CVE-2026-84782:
- OpenSSL 4.0.3
- OpenSSL 3.6.5
- OpenSSL 3.5.9
- OpenSSL 3.4.8
Alle releases van de betreffende takken vóór deze versies blijven kwetsbaar. Let op: OpenSSL vermeldt dat voor oudere branches (3.0, 1.1.1 en 1.0.2) de fixes alleen beschikbaar zijn voor klanten met premium support.
Daarnaast stopte OpenSSL met publieke security fixes voor OpenSSL 3.0 op 7 september. Dat betekent dat voor veel organisaties het tijdpad voor updaten praktisch gezien nog urgenter wordt.
Ubuntu en reboot na update
Ubuntu bracht fixes uit in pakketten met eigen versienummers. OpenSSL adviseert in die context om updates te installeren en daarna ook daadwerkelijk opnieuw op te starten zodat alle wijzigingen doorwerken.
- Ubuntu 26.04 LTS: libssl3t64 3.5.5-1ubuntu3.6
- Ubuntu 24.04 LTS: libssl3t64 3.0.13-0ubuntu3.16
- Ubuntu 22.04 LTS: libssl3 3.0.2-0ubuntu1.30
Debian heeft de fix opgenomen in Debian 13. Het security tracker van Debian noemde Debian 12 op het moment van publicatie nog als kwetsbaar.
Wat kunnen gebruikers van OpenSSL 3.0 doen?
OpenSSL stelt dat de laatste publieke 3.0-release 3.0.22 was op 25 augustus. Versie 3.0.23 is volgens OpenSSL de eerste security release waarin niet alle updates publiek zijn gemaakt.
Voor Ubuntu 22.04 en 24.04, waar OpenSSL 3.0 wordt gebruikt, zou de fix al aanwezig zijn in de eerder genoemde pakketten. Voor partijen die OpenSSL 3.0 zelf bouwen of een ingebouwde kopie in hun applicatie meenemen, meldt OpenSSL dat er geen publieke fix beschikbaar is.
Als alternatief raadt OpenSSL aan om te upgraden naar een nieuwere branch, zoals 4.0 of de long-term support release 3.5. Een andere optie is een betaald supportcontract voor lopende security fix-toegang voorbij de publieke einddatum.
Geen bekende workaround: update is de beste route
OpenSSL vermeldt geen echte workaround voor situaties waarin je niet kunt updaten. Dat is een belangrijk signaal: als je toepassing OpenSSL DTLS gebruikt, is mitigatie voornamelijk een zaak van patchen en testen.
Ubuntu’s beveiligingsmeldingen geven aan dat een aanvaller mogelijk incorrect handshake behavior kan veroorzaken of een denial of service kan uitlokken. In die melding wordt niet expliciet gerefereerd aan geheugendatalekken, maar OpenSSL’s eigen beschrijving maakt duidelijk dat de fout juist kan leiden tot heap memory die aan de andere kant zichtbaar wordt.
Snelle aanpak voor security teams
Om de risico’s van de OpenSSL DTLS-kwetsbaarheid snel te beperken, helpt een pragmatische aanpak. Denk aan de volgende stappen:
- Inventariseer DTLS-gebruik: check welke services OpenSSL gebruiken voor DTLS (denk aan WebRTC, VPN-achtige datakanalen of eigen UDP-handshakes).
- Map versies naar je runtime: niet alleen “wat staat op de server”, maar ook wat daadwerkelijk door applicaties wordt geladen of ingebouwd.
- Werk naar de fixed versies: volg de OpenSSL-tak die past bij jouw omgeving (bijvoorbeeld 4.0.3 of 3.6.5).
- Test handshake-timing: omdat de fout timing-afhankelijk is, is het verstandig om DTLS-connectiviteit in een testomgeving te valideren.
- Plan een reboot waar nodig: met name bij OS-pakketten zoals Ubuntu, waar OpenSSL aangeeft dat een restart nodig is voor volledige doorwerking.
Als je ook andere TLS/SSL-componenten beheert, loont het om tegelijk te kijken naar openstaande security issues in gerelateerde libraries. Bijvoorbeeld: eerder publiceerden we een uitleg over Bron: https://thehackernews.com/2026/09/openssl-fixes-high-severity-dtls-flaw.html
