{“lastseen”:”2025-10-29T12:25:46″,”description”:”Hello curl security team,\\n\\nFirst, thank you for your incredible work on maintaining such a critical and robust piece of software. We have been conducting a deep-dive source code audit of libcurl and believe we have identified a subtle logical flaw in the curl_url_set API that has security implications.\\n\\n## Summary\\n\\nThe curl_url_set() function in lib\/urlapi.c exhibits inconsistent URL encoding behavior for the CURLUPART_QUERY part. The logic that determines whether to percent-encode the = character is incorrectly tied to the CURLU_APPENDQUERY flag, rather than being based purely on the CURLU_URLENCODE flag.\\n\\nThis causes the exact same input string to be encoded in two different ways depending on whether the query is being replaced or appended, which can lead to HTTP Parameter Pollution (HPP) vulnerabilities in applications that rely on libcurl.\\n\\n## Affected Code\\n\\nlib\/urlapi.c, function curl_url_set(), specifically:\\n\\n1. Line ~1832: equalsencode = appendquery;\\n\\n * This logic incorrectly bases the equalsencode flag on whether an append operation is happening.\\n\\n2. Line ~1868: ((*i == ‘=’) \\u0026\\u0026 equalsencode)\\n\\n * This line later uses equalsencode to decide whether to skip encoding the = character.\\n\\nBecause equalsencode is only true during an append operation, a replace operation (even with CURLU_URLENCODE) will result in equalsencode being false, causing it to incorrectly encode the = character.\\n\\n## Proof of Concept (PoC)\\n\\nIn the interest of full transparency, an AI assistant was utilized to help write and refine the C code for the accompanying Proof of Concept.\\n\\nTo confirm this inconsistent behavior, we wrote the following C program. It tests the exact same input string (\\”a=b\\u0026c=d\\”) under three different scenarios using the curl_url_set API.\\n\\n\\n\\nPoC Code (poc.c):\\n“`\\n\/*\\n * ===================================================================\\n * PoC: Inconsistent URL Query Encoding in curl_url_set (v3.1 Final)\\n * ===================================================================\\n *\\n * – Target: libcurl \/ lib\/urlapi.c \/ curl_url_set()\\n * – Vulnerability: CWE-20: Improper Input Validation\\n * (leading to CWE-436: Interpretation Conflict)\\n *\\n * – Analysis:\\n * We discovered a logical flaw in how curl_url_set() handles URL\\n * encoding for the CURLUPART_QUERY part. The logic that skips\\n * encoding the ‘=’ character (`equalsencode`) is only activated\\n * if the `CURLU_APPENDQUERY` flag is present.\\n *\\n * This PoC demonstrates that the *exact same input* (\\”a=b\\u0026c=d\\”)\\n * is encoded differently based on whether the flag is used for\\n * replacing or appending, which can lead to HTTP Parameter Pollution\\n * vulnerabilities in applications that rely on libcurl.\\n *\\n *\/\\n\\n#include \\u003cstdio.h\\u003e\\n#include \\u003cstring.h\\u003e\\n#include \\u003ccurl\/curl.h\\u003e\\n\\n\/**\\n * @brief Helper function to run a single test case.\\n * @return 0 on success (behavior matches expectation), 1 on failure.\\n *\/\\nint run_test_case(const char *scenario_name,\\n const char *base_url,\\n const char *query_to_set,\\n unsigned int flags,\\n const char *expected_url)\\n{\\n CURLU *u = curl_url();\\n CURLUcode rc;\\n char *result_url = NULL;\\n int test_failed = 0;\\n\\n printf(\\”—[ %s ]—\\\\n\\”, scenario_name);\\n \\n if(!u) {\\n printf(\\” [!] FAILED: curl_url() returned NULL.\\\\n\\”);\\n return 1;\\n }\\n\\n \/\/ Set the base URL so we have a valid host\\n rc = curl_url_set(u, CURLUPART_URL, base_url, 0);\\n if(rc) {\\n printf(\\” [!] FAILED: Base URL set failed: %d\\\\n\\”, rc);\\n curl_url_cleanup(u);\\n return 1;\\n }\\n\\n \/\/ Run the function we are testing\\n rc = curl_url_set(u, CURLUPART_QUERY, query_to_set, flags);\\n if(rc) {\\n printf(\\” [!] FAILED: curl_url_set(QUERY) failed: %d\\\\n\\”, rc);\\n curl_url_cleanup(u);\\n return 1;\\n }\\n\\n \/\/ Get the final URL string\\n rc = curl_url_get(u, CURLUPART_URL, \\u0026result_url, 0);\\n if(rc) {\\n printf(\\” [!] FAILED: curl_url_get(URL) failed: %d\\\\n\\”, rc);\\n curl_url_cleanup(u);\\n return 1;\\n }\\n\\n \/\/ Print results\\n printf(\\” Input Query: \\\\\\”%s\\\\\\”\\\\n\\”, query_to_set);\\n printf(\\” Actual URL: %s\\\\n\\”, result_url);\\n printf(\\” Expected URL: %s\\\\n\\”, expected_url);\\n\\n \/\/ Compare actual vs. expected\\n if(strcmp(result_url, expected_url) != 0) {\\n printf(\\” [!] VERDICT: [ FAIL ]\\\\n\\\\n\\”);\\n test_failed = 1;\\n }\\n else {\\n printf(\\” [+] VERDICT: [ PASS ]\\\\n\\\\n\\”);\\n }\\n\\n curl_free(result_url);\\n curl_url_cleanup(u);\\n return test_failed;\\n}\\n\\nint main(void)\\n{\\n int failures = 0;\\n const char *base = \\”http:\/\/example.com\/api\\”;\\n const char *query = \\”a=b\\u0026c=d\\”;\\n\\n printf(\\”========================================================\\\\n\\”);\\n printf(\\” libcurl Inconsistent Query Encoding PoC\\\\n\\”);\\n printf(\\” Goal: Prove that CURLU_URLENCODE behaves differently\\\\n\\”);\\n printf(\\” depending on CURLU_APPENDQUERY.\\\\n\\”);\\n printf(\\”========================================================\\\\n\\\\n\\”);\\n\\n \/*\\n * This is our control test. No encoding.\\n * We expect \\”a=b\\u0026c=d\\” to be appended as-is.\\n *\/\\nfailures += run_test_case(\\n \\”Test 1: Control (Append, No-Encode)\\”,\\n base,\\n query,\\n CURLU_APPENDQUERY,\\n \\”http:\/\/example.com\/api?a=b\\u0026c=d\\”\\n );\\n\\n \/*\\n * This is Bug Part A. We REPLACE the query and ask for encoding.\\n * Because `equalsencode` is FALSE, it will (incorrectly) encode the ‘=’.\\n *\/\\nfailures += run_test_case(\\n \\”Test 2: Bug Part A (Replace + URL-Encode)\\”,\\n base,\\n query,\\n CURLU_URLENCODE,\\n \\”http:\/\/example.com\/api?a%3db%26c%3dd\\”\\n );\\n\\n \/*\\n * This is Bug Part B. We APPEND the query and ask for encoding.\\n * Because `equalsencode` is TRUE, it will (correctly) skip the first ‘=’.\\n * But this behavior is INCONSISTENT with Test 2.\\n *\/\\nfailures += run_test_case(\\n \\”Test 3: Bug Part B (Append + URL-Encode)\\”,\\n base,\\n query,\\n CURLU_URLENCODE | CURLU_APPENDQUERY,\\n \\”http:\/\/example.com\/api?a=b%26c%3dd\\”\\n );\\n\\n\\n \/* — Final Verdict — *\/\\n printf(\\”========================================================\\\\n\\”);\\n printf(\\” PoC Verdict:\\\\n\\”);\\n printf(\\”========================================================\\\\n\\\\n\\”);\\n if(failures == 0) {\\n printf(\\” [+] VULNERABILITY CONFIRMED!\\\\n\\\\n\\”);\\n printf(\\” Reasoning: All tests passed as expected.\\\\n\\”);\\n printf(\\” Test 2 resulted in: \\\\\\”…a%%3db\\u0026c%%3dd\\\\\\”\\\\n\\”);\\n printf(\\” Test 3 resulted in: \\\\\\”…a=b\\u0026c%%3dd\\\\\\”\\\\n\\”);\\n printf(\\” This proves that curl_url_set() produces two different\\\\n\\”);\\n printf(\\” outputs for the exact same input string (\\\\\\”a=b\\u0026c=d\\\\\\”),\\\\n\\”);\\n printf(\\” based *only* on the presence of the APPEND flag.\\\\n\\”);\\n printf(\\” This is inconsistent behavior that can lead to HPP.\\\\n\\\\n\\”);\\n }\\n else {\\n printf(\\” [!] PoC FAILED.\\\\n\\\\n\\”);\\n printf(\\” Reasoning: One or more tests failed, meaning the observed\\\\n\\”);\\n printf(\\” behavior did not match our analysis (it was %d failures).\\\\n\\”, failures);\\n printf(\\” Check the ‘Actual URL’ vs ‘Expected URL’ above.\\\\n\\”);\\n printf(\\” The logic may have been fixed in this version of libcurl.\\\\n\\\\n\\”);\\n }\\n \\n return 0;\\n}\\n“`\\n\\nCompilation and Output (The Evidence):\\nThis PoC was compiled against libcurl (system version 8.5.0) and confirmed the vulnerability:\\n\\n“`\\n$gcc -o poc poc.c -lcurl\\n$ .\/poc\\n========================================================\\n libcurl Inconsistent Query Encoding PoC\\n Goal: Prove that CURLU_URLENCODE behaves differently\\n depending on CURLU_APPENDQUERY.\\n========================================================\\n\\n—[ Test 1: Control (Append, No-Encode) ]—\\n Input Query: \\”a=b\\u0026c=d\\”\\n Actual URL: http:\/\/example.com\/api?a=b\\u0026c=d\\n Expected URL: http:\/\/example.com\/api?a=b\\u0026c=d\\n [+] VERDICT: [ PASS ]\\n\\n—[ Test 2: Bug Part A (Replace + URL-Encode) ]—\\n Input Query: \\”a=b\\u0026c=d\\”\\n Actual URL: http:\/\/example.com\/api?a%3db%26c%3dd\\n Expected URL: http:\/\/example.com\/api?a%3db%26c%3dd\\n [+] VERDICT: [ PASS ]\\n\\n—[ Test 3: Bug Part B (Append + URL-Encode) ]—\\n Input Query: \\”a=b\\u0026c=d\\”\\n Actual URL: http:\/\/example.com\/api?a=b%26c%3dd\\n Expected URL: http:\/\/example.com\/api?a=b%26c%3dd\\n [+] VERDICT: [ PASS ]\\n\\n========================================================\\n PoC Verdict:\\n========================================================\\n\\n [+] VULNERABILITY CONFIRMED!\\n\\n Reasoning: All tests passed as expected.\\n Test 2 resulted in: \\”…a%3db\\u0026c%3dd\\”\\n Test 3 resulted in: \\”…a=b\\u0026c%3dd\\”\\n This proves that curl_url_set() produces two different\\n outputs for the exact same input string (\\”a=b\\u0026c=d\\”),\\n based *only* on the presence of the APPEND flag.\\n This is inconsistent behavior that can lead to HPP.\\n“`\\n\\n## Remediation\\n\\nThe logic for equalsencode in lib\/urlapi.c (around line 1832) should not be tied to appendquery. The decision to encode = in a query string should be based only on whether CURLU_URLENCODE is set. A simple fix would be to change equalsencode = appendquery; to equalsencode = urlencode; (or similar logic) within the CURLUPART_QUERY case block.\\n\\n## Impact\\n\\nThis inconsistent encoding behavior breaks the API contract and can lead to security vulnerabilities in applications that rely on libcurl.\\n\\nA developer might reasonably expect CURLU_URLENCODE to encode all query parameters consistently. However, if their application logic changes from replacing a query to appending to it, the encoding behavior silently changes.\\n\\n## Attack Scenario (HTTP Parameter Pollution):\\n\\n1. An application builds a request:\\ncurl_url_set(u, CURLUPART_QUERY, \\”user=guest\\”, CURLU_URLENCODE);\\n\\n\\n2. Later, it appends a user-controlled parameter:\\ncurl_url_set(u, CURLUPART_QUERY, \\”callback=http:\/\/attacker.com\\”, CURLU_URLENCODE | CURLU_APPENDQUERY);\\n\\n\\n3. Because of this bug, the application might incorrectly construct a query like: …\\u0026callback=http:\/\/attacker.com instead of the expected …\\u0026callback=http%3A%2F%2Fattacker.com.\\n\\n\\nThis allows an attacker to inject unencoded characters (=, \\u0026, \/, \ud83d\ude42 into query parameters, leading to HTTP Parameter Pollution (HPP), WAF bypasses, and potential SSRF or XSS vulnerabilities, depending on how the server-side application interprets the malformed query string.”,”published”:”2025-10-29T10:51:20″,”modified”:”2025-10-29T12:19:29″,”type”:”hackerone”,”title”:”curl: Logical Flaw in curl_url_set Leads to Inconsistent Query Parameter Encoding”,”source”:””,”references”:””,”id”:”H1:3403880″,”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\/3403880″,”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-10-29T12:25:46″,”description”:”Hello curl security team,\\n\\nFirst, thank you for your incredible work on maintaining such a critical and robust piece of software. We have been conducting a…<\/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-23899","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