Onze octets. C’est tout ce qu’il faut à un attaquant distant et non authentifié pour saturer la mémoire d’un serveur via OpenSSL. Cette faille porte un nom : HollowByte, mais le problème, c’est qu’elle a été corrigée en silence, sans le moindre CVE pour la signaler.

Onze octets pour geler la mémoire d’un serveur

Tout part de la façon dont OpenSSL lit le tout début d’une négociation TLS. Chaque message de handshake commence par un en-tête de 4 octets, dont 3 servent à déclarer la taille du corps du message à venir. Les versions vulnérables faisaient une confiance aveugle à cette valeur: elles réservaient un tampon de réception de la taille annoncée avant même d’avoir reçu la moindre donnée.

Résultat, un paquet malveillant de seulement 11 octets suffit à déclencher une allocation de mémoire non validée pouvant atteindre 131 Ko. De son côté, le fil d’exécution se met en attente de données qui n’arriveront jamais. Sur le papier, cette technique rappelle la vulnérabilité Slowloris. Mais HollowByte ajoute un effet d’accumulation lié au fonctionnement de la bibliothèque glibc. Quand la connexion de l’attaquant se termine, OpenSSL libère bien le tampon, sauf que glibc ne rend pas immédiatement au système d’exploitation les allocations de petite et moyenne taille : la librairie les conserve pour un éventuel réemploi.

En lançant des vagues de connexions de tailles aléatoires, l’attaquant empêche l’allocateur de recycler ces blocs libérés. Le tas mémoire se fragmente, et la mémoire résidente du serveur ne cesse de grimper. “Même après la déconnexion de l’attaquant, le serveur reste durablement gonflé. La seule façon de récupérer cette mémoire est de terminer le processus”, précise l’équipe Red Team d’Okta, à l’origine de cette découverte.

Dans leur rapport, les chercheurs d’Okta évoquent des tests effectués sur des instances OpenSSL associées à NGINX :

• Sur une machine dotée de 1 Go de RAM, un déni de service a été provoqué sur le serveur par le mécanisme OOM Killer (Out Of Memory) après 547 Mo de mémoire figée et fragmentée.
• Sur un système avec 16 Go de RAM, l’attaque a monopolisée 25 % de la mémoire totale tout en restant sous le plafond de connexions, ce qui rend inefficaces les protections classiques de limitation du nombre de connexions.

Ce problème de sécurité affecte de nombreuses solutions, OpenSSL étant embarqué à peu près partout. Cette faille touche potentiellement les serveurs web (Apache, NGINX), les environnements d’exécution (Node.js, Python, Ruby, PHP) et les bases de données (MySQL, PostgreSQL).

Un correctif sans CVE : c’est un problème

L’équipe d’OpenSSL a fait le nécessaire dans le code pour corriger ce problème de sécurité. Désormais, le tampon est agrandi qu’au fur et à mesure que les octets arrivent réellement sur le fil d’exécution. Le problème, c’est que ce correctif a été intégré discrètement à la version d’OpenSSL, dans la continuité de la version 4.0 présentée dans cet article. Ce patch a ensuite été rétroporté vers les versions , , et . Ces versions datent du 9 juin 2026.

Ce qui est problématique, c’est qu’aucune référence CVE n’a été attribuée à HollowByte. Ainsi, cette faille de sécurité est méconnue des scanners et ne sera donc pas détectée. Comment expliquer cela ? En réalité, OpenSSL a traité le problème comme un simple correctif lié à du hardening, et non comme un problème de sécurité. Résultat, pas de CVE associée.

Pour autant, la release , publiée le 9 juin 2026, est une belle mise à jour de sécurité. En effet, elle corrige 18 CVE (la plus sévère étant un use-after-free dans référencé CVE-2026-45447) et deux régressions, mais aucune de ces vulnérabilités ne correspond à HollowByte. Ce problème de sécurité a été colmaté en silence, bien qu’il y ait une trace discrète via les commits effectués dans le code source. Okta évoque les PR suivantes : 30792, 30793 et 30794.