1. A patch for curl is pending--see the bugs page for curl on sourceforge. The patch is to replace the bogo-random string with a harder to guess one (generated by openssl cryptographic prng).
2. I wouldn't completely call this a curl bug, but curl's behavior was suboptimal and the patch will help.
3 As a general principle, input "sanitzation" is doomed to failure and it's better to keep the control and data paths of a program completely separate, so that data doesn't need to be "sanitized" (it can stay dirty). For example, don't try to escape special input characters before splicing them into an sql query. Use prepared queries instead, so that the input data never touches the query parser. Little Bobby Tables will thank you.
4. If you absolutely can't avoid passing user data through some interpretation layer, it's best to encode it so that it can't possibly be parsed as controlling something. I've sometimes used hexadecimal encoding for this since it's simple and not much can go wrong. It does require controlling both sides of the communication so that the other side can decode, i.e. it might not have been applicable to this particular attack (though it would have stopped it because of the high likelihood of non-hex chars in the curl-generated separator string). Using base64 sounds more efficient than hex but I've seen it hit various problems. But it requires some control over both sides of the transaction