Skip to content
hacker_posts

OpenSSL corrige une faille DTLS qui fuit la mémoire (CVE-2026-84782)

OpenSSL corrige CVE-2026-84782, une faille DTLS de sévérité haute qui peut divulguer de la mémoire tas non chiffrée ou faire planter les applications DTLS. Correctifs en 4.0.3, 3.6.5, 3.5.9, 3.4.8.

Publié le 3 min de lecture
cveopensslalertedtls

OpenSSL a publié le 29 septembre une mise à jour de sécurité corrigeant CVE-2026-84782, une faille de sévérité haute dans le mécanisme de retransmission DTLS. Elle peut divulguer de la mémoire tas non chiffrée au pair distant ou faire planter l'application. Le chemin de code concerné est celui du TLS sur datagramme — celui qu'utilisent les VPN, la VoIP et de nombreux produits IoT.

La source primaire est l'avis OpenSSL 20260929.txt ; côté français, l'ANSSI a publié CERTFR-2026-AVI-1241. La faille DTLS a été rapportée par Laurent Gaffie (secorizon.com).

Ce que fait la faille

D'après l'avis, CVE-2026-84782 — « DTLS Retransmits Handshake Messages From a Stale Buffer Offset » — se déclenche quand OpenSSL retransmet un message de handshake DTLS alors que l'envoi d'un message plus volumineux est suspendu. Le mécanisme gère mal cette écriture suspendue et lit au-delà du tampon alloué. Résultat : soit une divulgation de mémoire tas transmise en clair comme données de handshake, soit un dépassement de tampon qui fait planter le processus. SecurityWeek situe la faille à CVSS 8.2.

Versions concernées

  • Affectées : 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1, 1.0.2.
  • Corrigées : 4.0.3, 3.6.5, 3.5.9, 3.4.8. Rétroportages réservés au support premium : 3.0.23, 1.1.1zj, 1.0.2zs.

La même publication corrige une douzaine d'autres problèmes de moindre gravité, pour l'essentiel dans la pile QUIC (dénis de service par allocation mémoire) et quelques correctifs de temps constant sur SM2 et les courbes non-NIST. Seule CVE-2026-84782 est classée « haute ».

État de l'exploitation

Aucune exploitation signalée. OpenSSL n'indique pas si un attaquant peut forcer de façon fiable une retransmission pendant qu'un message est bloqué, et aucune attaque n'est connue à ce jour.

Que faire

  1. Recenser d'abord les usages DTLS. Le risque de divulgation mémoire porte sur le chemin DTLS : priorité aux concentrateurs VPN, aux piles VoIP/SIP et aux équipements embarqués/IoT qui négocient du DTLS.
  2. Passer à la branche corrigée correspondant au déploiement (4.0.3 / 3.6.5 / 3.5.9 / 3.4.8). En 3.0, 1.1.1 ou 1.0.2, les correctifs relèvent du support premium — planifier la migration hors des branches en fin de support.
  3. Reconstruire les binaires et conteneurs à liaison statique qui embarquent OpenSSL : une simple mise à jour du paquet système ne les couvre pas.

Contexte

Les bugs de retransmission DTLS forment une classe récurrente : la logique de réémission sur UDP doit jongler avec un état de handshake partiel et désordonné, et les erreurs d'offset de tampon y ressortent plutôt en divulgation mémoire qu'en plantage propre. Le facteur atténuant reste l'exposition — bien moins de services parlent DTLS que TLS, donc la surface réelle est plus étroite que ne le laisse penser la liste des versions affectées. Ciblez les systèmes qui parlent DTLS et ce cycle de correctifs redevient une opération de routine, quoique large.

Articles liés