OpenSSL a publié le 29 septembre un avis de sécurité qui recense quatorze vulnérabilités, dont plusieurs de gravité élevée. CVE-2026-84782 est l’une d’elles : un défaut dans la retransmission des messages de handshake DTLS peut, dans certaines conditions, transmettre des fragments de mémoire en clair au pair ou faire planter le processus.
Un décalage dans la retransmission DTLS
DTLS adapte TLS aux communications datagramme, notamment sur UDP. Pendant un handshake, une écriture peut être suspendue si le transport ne peut pas accepter immédiatement tous les fragments. Le mécanisme de retransmission peut alors intervenir pendant que cette écriture attend toujours de reprendre.
OpenSSL explique que la logique fautive réutilisait une position de lecture qui ne correspondait pas au message retransmis. Elle pouvait donc relire des octets après le début attendu du message, y compris des données d’un autre message plus long encore en cours d’écriture. La lecture peut dépasser la mémoire allouée; le processus peut alors divulguer des données ou s’arrêter.
Un scénario lié à l’état du handshake
Le défaut n’est pas décrit comme une simple requête arbitraire envoyée à n’importe quel service OpenSSL. Il suppose une écriture DTLS suspendue puis l’activation du temporisateur de retransmission avant la reprise. L’impact exact dépend donc de l’application, du transport et de la façon dont elle gère les appels d’écriture et de reprise.
L’avis classe le problème comme élevé et décrit une divulgation de heap ou un déni de service. Il ne rapporte pas d’exploitation active. Les équipes doivent toutefois vérifier les produits qui utilisent DTLS et ne pas conclure à l’absence de risque uniquement parce qu’elles n’exposent pas un serveur HTTPS classique.
Branches et versions corrigées
OpenSSL liste comme vulnérables les versions antérieures aux correctifs dans les branches 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 et 1.0.2. Les versions correctrices indiquées sont 4.0.3, 3.6.5, 3.5.9, 3.4.8, 3.0.23, 1.1.1zj et 1.0.2zs. L’avis précise que les branches 3.1, 3.2 et 3.3, hors support, n’ont pas été analysées.
Les branches 3.0, 1.1.1 et 1.0.2 sont hors du canal public de mises à jour OpenSSL ; les correctifs amont correspondants sont réservés aux clients du support premium. Une distribution peut toutefois fournir son propre correctif rétroporté, même si le numéro de version affiché semble ancien. Vérifiez l’avis de sécurité de votre système ou du fournisseur du produit avant de conclure qu’une installation reste vulnérable ou de remplacer vous-même une bibliothèque.
Ce que les équipes peuvent vérifier
Inventoriez les dépendances OpenSSL, y compris les copies embarquées dans les applications et équipements. Confirmez si DTLS est activé ou utilisé par un service, puis appliquez la version ou le paquet corrigé fourni par le responsable du produit. Sur les systèmes gérés, vérifiez la présence réelle du correctif après déploiement. Pour comparer les étapes de mise à jour et de contrôle après correctif sur d’autres produits, consultez notre analyse de la faille Microsoft Exchange et celle des vulnérabilités MikroTik RouterOS.
Le lien avec Soclyde
Soclyde ne corrige pas OpenSSL et ne sécurise pas les applications qui l’intègrent. Pour structurer les mises à jour, consultez notre guide de cybersécurité et de suivi NIS2. La faille porte sur une bibliothèque de communications ; le coffre de mots de passe répond à un autre besoin, celui de conserver des secrets de compte uniques plutôt que de les réutiliser entre services. Retrouvez aussi notre audit de sécurité des gestionnaires de mots de passe et le guide pour créer des mots de passe forts et uniques.
À retenir
CVE-2026-84782 est un défaut précis du mécanisme de retransmission DTLS, avec un risque de divulgation mémoire ou d’arrêt dans certaines conditions de handshake. Recensez les versions directes et embarquées, puis appliquez les correctifs de l’éditeur concerné. Pour un autre exemple de suivi des correctifs sur un équipement réseau, consultez notre analyse des vulnérabilités MikroTik RouterOS.
