I'm not sure where is the security issue here. As already noted, one can just put several --proxy-header arguments, so the functionality is equivalent. The onl

I'm not sure where is the security issue here. As already noted, one can just put several --proxy-header arguments, so the functionality is equivalent. The only way this would do something unexpected (and not necessarily dangerous besides breaking the service) would be if the curl command would be used in a scenario like: (1) curl is used by some script to access some API or other URL, (2) a user can configure the script to give a specific value to an header, let's say an authentication token or similar, but the user can't directly alter the curl command (e.g. because they can only change URL and TOKEN with a web interface). Here the user would be able to add an header IF the script is not properly sanitizing the input (so the supposed security issue IMHO would be in the script), but if adding an additional header breaks security, the underlying system has a problem too... In a very far-stretched scenario, one can possibly add two CRLFs and have the rest of the header (if any) considered by the server as data. IF the request is a POST/PUT/... request, and IF the server returns (or allows later access to) the data, and IF the attacker manipulating the supposedly-restricted single-header can see the output of the call (or retrieve the saved data), then we'd have an information disclosure issue. Would it disclose anything sensitive? Not sure, unless there's an auth token or something AFTER the header. And again, I'd rather incriminate the curl caller for not sanitizing the input if this happens.