{“lastseen”:”2026-04-18T20:27:59″,”description”:”## Summary:\\nlibcurl automatically learns RTSP `Session:` headers from server responses and stores them in `data-\\u003eset.str[STRING_RTSP_SESSION_ID]` in `lib\/rtsp.c:1015-1033`. On later RTSP requests using the same easy handle, `rtsp_do()` reads that easy-handle-scoped value at `lib\/rtsp.c:373` and unconditionally emits `Session: %s` into the next request at `lib\/rtsp.c:513-515`, without any host, port, or origin boundary check. Because the value lives in `data-\\u003eset` \/ `struct UserDefined` rather than request-scoped state (`lib\/urldata.h:878-883`, `lib\/urldata.h:1143`, `lib\/urldata.h:1405-1406`), it survives across subsequent RTSP requests to different hosts until manually cleared with `CURLOPT_RTSP_SESSION_ID = NULL` (`lib\/setopt.c:2346-2351`) or the easy handle is destroyed (`lib\/url.c:156-164`). In the attached PoC, request 1 to a victim RTSP server learns `Session: VICTIM-SESSION-123456`, request 2 to an attacker RTSP server on the same easy handle leaks that value, and a fresh handle can then replay the leaked session back to the victim with `PLAY` successfully accepted. A new-easy-handle control and a manual-clear control both suppress the leak. I reproduced this on curl 8.19.0 \/ libcurl 8.19.0 on x86_64 Linux and attached a zip with the PoC, logs, and a line-level root-cause note.\\n\\n## Affected version\\nReproduced on:\\n`curl 8.19.0 (x86_64-pc-linux-gnu) libcurl\/8.19.0 OpenSSL\/3.5.5 zlib\/1.3.1 brotli\/1.2.0 zstd\/1.5.7 libidn2\/2.3.8 libpsl\/0.21.5 libssh2\/1.11.1 nghttp2\/1.68.1 ngtcp2\/1.21.0 nghttp3\/1.15.0 librtmp\/2.3 mit-krb5\/1.22.1 OpenLDAP\/2.6.10`\\nPlatform:\\n`Linux x86_64`\\n\\n## Steps To Reproduce:\\n1. Start the local RTSP harness from the attached PoC directory:\\n `python3 -u rtsp_session_leak_server.py`\\n2. Run the attached PoC:\\n `python3 poc_rtsp_session_leak.py`\\n3. Observe the base case in the client output:\\n – request 1: `SETUP rtsp:\/\/127.0.0.1:18201\/media` returns `Session: VICTIM-SESSION-123456`\\n – request 2: `OPTIONS rtsp:\/\/127.0.0.1:18202\/evil` on the same easy handle sends `Session: VICTIM-SESSION-123456`\\n4. Observe the controls:\\n – with a new easy handle for the attacker request, no `Session:` header is sent\\n – after clearing `CURLOPT_RTSP_SESSION_ID` on the reused handle, no `Session:` header is sent\\n5. Observe the replay control:\\n – a fresh handle sending `PLAY` to the victim without a session gets `RTSP\/1.0 454 Session Not Found`\\n – a fresh handle sending `PLAY` to the victim with the leaked `Session: VICTIM-SESSION-123456` gets `RTSP\/1.0 200 OK`\\n6. Observe the attached sink-side server log:\\n – attacker receives `{\\”role\\”:\\”attacker\\”,\\”method\\”:\\”OPTIONS\\”,\\”session\\”:\\”VICTIM-SESSION-123456\\”,…}`\\n – victim then receives `{\\”role\\”:\\”victim\\”,\\”method\\”:\\”PLAY\\”,\\”session\\”:\\”VICTIM-SESSION-123456\\”,\\”session_ok\\”:true,…}`\\n\\n## Line-Level Root Cause\\n- The RTSP session identifier is automatically learned from server responses and stored on the easy handle.\\n – `lib\/rtsp.c:1015-1033` parses the `Session:` header from RTSP responses.\\n – If `data-\\u003eset.str[STRING_RTSP_SESSION_ID]` is not already set, `lib\/rtsp.c:1031` stores the received value there.\\n – `STRING_RTSP_SESSION_ID` is defined in `lib\/urldata.h:955`.\\n- That storage is easy-handle scoped, not request scoped.\\n – The `UserDefined` structure in `lib\/urldata.h:878-883` is documented as data set once and reused across independent connections.\\n – `data-\\u003eset` is the easy handle\u2019s `struct UserDefined` in `lib\/urldata.h:1405-1406`.\\n – The backing string array is `lib\/urldata.h:1143`: `char *str[STRING_LAST];`\\n- The stored `Session:` value is then automatically attached to later RTSP requests.\\n – `lib\/rtsp.c:373` loads `p_session_id = data-\\u003eset.str[STRING_RTSP_SESSION_ID];`\\n – `lib\/rtsp.c:513-515` emits `Session: %s` whenever that value is present.\\n – There is no host, port, or origin boundary check between the read at line 373 and the emitted header at line 514.\\n- The state is not automatically cleared when the RTSP target changes.\\n – The explicit setter\/clear path is `lib\/setopt.c:2346-2351` via `CURLOPT_RTSP_SESSION_ID`, so applications can clear it manually by setting it to `NULL`, but libcurl does not clear it automatically when switching to a different RTSP host.\\n – The public getter in `lib\/getinfo.c:159-161` reads the same field, confirming that the \u201cmost recent\u201d RTSP session ID is stored on the handle.\\n – Generic cleanup only happens when the easy handle is destroyed in `lib\/url.c:156-164`, where `Curl_freeset()` frees `data-\\u003eset.str[i]`.\\n – In this tree, references to `STRING_RTSP_SESSION_ID` only appear in the manual setter, getter, RTSP response parse\/store path, and RTSP request auto-attach path. There is no pretransfer, host-change, or per-request reset path that clears the field when the RTSP URL changes to a different host or port.\\n\\n## Impact\\n\\n## Summary:\\nAn attacker-controlled RTSP server contacted later on the same easy handle can receive a `Session:` token that was learned from a different RTSP server. In the attached PoC, that leaked token is replayable: a fresh handle can send `PLAY` back to the victim with the leaked session ID and the victim accepts it, while the same request without the session is rejected with `454 Session Not Found`. This turns the issue from a cross-host RTSP session leak into replayable session control mix-up on reused easy handles.”,”published”:”2026-04-17T14:41:41″,”modified”:”2026-04-18T19:37:36″,”type”:”hackerone”,”title”:”curl: libcurl reuses a learned RTSP Session header across different hosts on the same easy handle, enabling cross-host session leak and replay”,”source”:””,”references”:””,”id”:”H1:3680234″,”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\/3680234″,”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”:”2026-04-18T20:27:59″,”description”:”## Summary:\\nlibcurl automatically learns RTSP `Session:` headers from server responses and stores them in `data-\\u003eset.str[STRING_RTSP_SESSION_ID]` in `lib\/rtsp.c:1015-1033`. On later RTSP requests using the same easy…<\/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-47874","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