OpenSSL referme une faille DTLS qui renvoie des octets du tas en clair

17 août 2026. Laurent Gaffie, chercheur chez Secorizon, signale à OpenSSL une anomalie dans la logique de retransmission de DTLS. 29 septembre 2026. Le projet publie des correctifs et documente CVE-2026-84782, une lecture hors limites (CWE-125) que la CISA note CVSS 8.2. 29 septembre 2026. Ubuntu et Debian publient leurs paquets corrigés le jour même. Pourquoi c’est important : DTLS est le TLS du trafic UDP — il protège les canaux de données WebRTC et la négociation des clés des appels chiffrés. Une faille qui fuit des octets de mémoire vers l’interlocuteur compromet la confidentialité du canal censé la garantir.

La faille : un renvoi qui repart du mauvais endroit

DTLS découpe un message de handshake volumineux en fragments qui tiennent chacun dans un datagramme UDP. Si le transport ne peut pas accepter de données sur le moment, l’écriture peut se suspendre en plein milieu d’un message (l’état WANT_WRITE), puis reprendre plus tard. Pendant cette suspension, le timer de retransmission peut se déclencher de façon indépendante et renvoyer un message plus ancien, déjà considéré comme envoyé.

C’est là que le code était faux. Avant le correctif, la retransmission réutilisait la position du message suspendu au lieu de repartir du début du message à renvoyer. Le message retransmis partait avec une étiquette erronée, et son corps était constitué d’octets résiduels du message plus grand, toujours en vol. La lecture pouvait alors dépasser la fin du tampon.

Deux conséquences, selon OpenSSL : le message mal étiqueté peut renvoyer de la mémoire du tas en clair comme donnée de handshake, ou — si la lecture atteint une zone mémoire non mappée — faire planter le programme. Le premier effet fuit la confidentialité, le second offre un déni de service. La CISA a synthétisé l’impact en un vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H : confidentialité faible, disponibilité élevée, exploitation non observée à la publication.

Le défaut n’est pas limité au client ni au serveur : OpenSSL a testé son correctif dans les deux rôles.

Une faille discrète, une exposition large

DTLS n’est pas le protocole que tout le monde croit connaître. Il chiffre le trafic UDP là où TCP et TLS classiques ne s’appliquent pas : les canaux de données WebRTC, la mise en place des clés des appels vocaux chiffrés, certains VPN. Une application n’est exposée que si elle utilise OpenSSL pour DTLS — mais c’est plus fréquent qu’on ne le pense, car OpenSSL est souvent compilé statiquement ou embarqué dans des images de conteneurs, des firmwares et des applications de bureau.

La nuance des distributions illustre le décalage de gravité. Ubuntu a résumé l’impact à « un comportement de handshake incorrect ou un déni de service », sans mentionner la fuite de mémoire. OpenSSL est plus précis : le message mal étiqueté transporte des octets du tas « en clair ». Ce n’est pas un Heartbleed — la fuite n’est pas pilotable à volonté par l’attaquant — mais elle dépend d’un concours de circonstances de synchronisation, ce qui la rend à la fois difficile à exploiter et difficile à écarter.

Le point mérite d’être souligné parce qu’il change la posture. Heartbleed, en 2014, laissait l’attaquant demander de la mémoire à volonté ; ici, la fuite est un effet de bord d’un renvoi mal positionné. Un défenseur ne peut pas se dire « pas d’exploit public, donc pas d’urgence » : la confidentialité est compromise par construction, pas par une preuve de concept.

Les versions qui corrigent, et celles qui ne corrigent rien

Le correctif est simple à appliquer si vous êtes sur une branche supportée.

• OpenSSL 4.0 → 4.0.3 — téléchargement public, support jusqu’au 14 mai 2027
• OpenSSL 3.6 → 3.6.5 — public, jusqu’au 1er novembre 2026
• OpenSSL 3.5 → 3.5.9 — public, LTS jusqu’au 8 avril 2030
• OpenSSL 3.4 → 3.4.8 — public, jusqu’au 22 octobre 2026

Les branches plus anciennes sont le vrai sujet. OpenSSL 3.0, 1.1.1 et 1.0.2 reçoivent des correctifs — 3.0.23, 1.1.1zj, 1.0.2zs — mais uniquement pour les clients du support premium. Le support public de 3.0 s’est arrêté le 7 septembre 2026, trois semaines avant cette faille. Les branches 3.1, 3.2 et 3.3 n’ont pas été examinées.

OpenSSL ne propose aucun contournement pour qui ne peut pas mettre à jour. Vérifiez votre version, puis celle de tout ce qui dépend de la bibliothèque :

openssl version
# 4.0.x  -> >= 4.0.3   |   3.6.x -> >= 3.6.5
# 3.5.x  -> >= 3.5.9   |   3.4.x -> >= 3.4.8

Ubuntu a corrigé le 29 septembre dans ses propres paquets, qui conservent des numéros de version plus anciens : 26.04 LTS (libssl3t64 3.5.5-1ubuntu3.6), 24.04 LTS (libssl3t64 3.0.13-0ubuntu3.16) et 22.04 LTS (libssl3 3.0.2-0ubuntu1.30), avec un redémarrage requis. Debian a publié DSA-6531-1 pour Debian 13 (paquet 3.5.7-1~deb13u3).

Ce qu’un SRE doit faire maintenant

La priorité n’est pas de patcher un serveur, c’est de repérer toutes les copies d’OpenSSL que vous exécutez sans le savoir.

• Recensez les binaires embarqués. Une image de conteneur qui compile OpenSSL en statique ne sera pas corrigée par le paquet de l’hôte. trivy, grype ou docker scout doivent remonter CVE-2026-84782 si vos bases de vulnérabilités sont à jour.
• Traitez les branches mortes comme un risque, pas comme un héritage. Un serveur en OpenSSL 3.0 sans contrat premium ne recevra pas ce correctif. Migrez vers 3.5 LTS plutôt que de bricoler une recompilation.
• Ne vous arrêtez pas à la version du paquet système. Le libssl de l’hôte peut être à jour pendant qu’une application Python, Node ou Go embarquée tourne sur une copie vulnérable. Le bundling statique est le point aveugle classique.
• Surveillez la retransmission DTLS si vous l’exposez. Un pic d’erreurs de handshake ou de crashs d’un service WebRTC mérite un regard, même sans preuve d’exploitation.

Le point de vigilance, c’est que la fuite est silencieuse. Un renvoi qui expose seize octets du tas ne déclenche aucune alerte ; il faut la mise à jour pour refermer le canal, pas la détection pour l’observer.

Verdict

Si vous utilisez OpenSSL 3.4, 3.5, 3.6 ou 4.0, mettez à jour immédiatement — le correctif est public, testé dans les deux rôles, et la gravité High impose, selon la propre politique d’OpenSSL, une application « dès que possible ». Si vous êtes resté sur 3.0, 1.1.1 ou 1.0.2 sans support premium, vous êtes de fait hors correctif : planifiez la migration vers 3.5 LTS comme un chantier de sécurité, pas une corvée de maintenance. Si vous exploitez des services WebRTC ou de téléphonie chiffrée, traitez CVE-2026-84782 comme une fuite de confidentialité potentielle et forcez la mise à jour de toute la chaîne, jusqu’aux images de conteneurs.

Références

• The Hacker News — OpenSSL Fixes High-Severity DTLS Flaw That Can Leak Heap Memory Unencrypted
• NVD — CVE-2026-84782
• OpenSSL — Security advisories