theopaid/cve-2026-67183-unauthenticated-memory-leak-leads-to-memory-exhaustion-tinyweb-Avis de sécurité : fuite de mémoire non authentifiée conduisant à l'épuisement de la mémoire (TinyWeb)
Identifiant CVE attribué : CVE-2026-67183
TinyWeb alloue plusieurs objets lors de l'analyse de chaque requête et ne les libère jamais. Les structures de requête et d'en-têtes n'ont pas de destructeurs, et rien ne les supprime après l'envoi de la réponse. La mémoire du worker croît à chaque requête et ne redescend jamais, de sorte qu'un flux régulier de requêtes ordinaires fait sortir le worker de la mémoire disponible.
TnyWeb/0.0.8e48f15d (2018-11-20), où ces structures et l'analyseur ont été introduits, jusqu'à a381da2 (2023-11-22, dernier sur master).CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:NUn attaquant distant non authentifié qui peut atteindre le port TCP d'écoute du serveur (9090 dans la configuration fournie) et envoyer des requêtes à un débit soutenu modeste. Aucun identifiant ni interaction de l'utilisateur n'est requis. Les requêtes peuvent être bien formées ; aucune charge utile spéciale n'est nécessaire.
Pour chaque requête, HttpParser::execute() alloue un Url, un HttpHeaders, et un HttpHeader par ligne d'en-tête :
// src/tiny_http/http_parser.cc:1692
request->url = new Url;
// src/tiny_http/http_parser.cc:1709
request->headers = new HttpHeaders;
// src/tiny_http/http_parser.cc:1033-1040
HttpHeader* header = new HttpHeader;
return_val = parseHeader(stream, offset, len, header);
...
result->generals.push_back(header); // stored in a raw-pointer list
HttpRequest et HttpHeaders sont de simples structures sans destructeur, donc détruire un HttpRequest ne libère aucun de ces éléments :
// src/tiny_http/http_parser.h:442
typedef struct HttpRequest {
...
Url* url;
HttpHeaders* headers;
HttpBody* body;
} HttpRequest;
// src/tiny_http/http_parser.h:279-304
typedef struct HttpHeaders {
...
std::list<HttpHeader*> generals; // raw pointers, never deleted
...
} HttpHeaders;
WebProtocol conserve la requête dans un std::shared_ptr<HttpRequest> (src/tiny_http/http_protocol.h:49). Lorsque la requête suivante le remplace, le ~HttpRequest par défaut s'exécute et provoque la fuite de url, headers, body, ainsi que de chaque HttpHeader dans generals. Le seul delete request du code se trouve dans getDataFromProxy() (src/tiny_http/http_protocol.cc:194), une fonction que le chemin de traitement des requêtes n'appelle jamais. Les tampons de réponse par requête issus du pool mémoire contribuent à cette croissance.
Démarrez le serveur avec la configuration fournie (écoute sur le port 9090). Notez l'identifiant du processus (PID) d'un worker.
Enregistrez la mémoire résidente du worker :
grep VmRSS /proc/<worker_pid>/status
for i in $(seq 1 2000); do
curl -s -o /dev/null http://TARGET:9090/
done
VmRSS. Il a augmenté et ne redescend pas ensuite. Une exécution représentative :VmRSS before: 3704 kB
after 500 requests: 4788 kB
after 1000 requests: 22068 kB
after 1500 requests: 41652 kB
after 2000 requests: 59956 kB
La croissance est monotone, d'environ 20 à 28 kB par requête, sans palier. La répétition du lot poursuit l'escalade jusqu'à ce que le worker soit tué pour manque de mémoire.
Un attaquant non authentifié peut épuiser la mémoire d'un worker avec un flux soutenu de requêtes et provoquer une condition de manque de mémoire, entraînant un déni de service. Le trafic ordinaire fuit également avec le temps, de sorte que cette condition peut survenir sans attaquant.
Donnez à HttpRequest et HttpHeaders des destructeurs qui libèrent url, headers, body, et chaque HttpHeader dans generals, ou conservez-les dans des pointeurs intelligents (smart pointers) afin qu'ils soient libérés automatiquement. Libérez également les tampons du pool mémoire par requête une fois que la réponse a été envoyée.