One shouldn't construct shell commands from untrusted user input in the first place unless they know exactly what they're doing and is aware of all the pitfalls. It's the worst possible tool to be using if the aim is to avoid security issues with minimal effort. Debating about this particular curl quirk distracts from the bigger issue IMO.

Then the people assuming random things without doing research are to blame, not curl.

Apportioning blame doesn't get rid of bugs; misuse resistant APIs do.

Reading docs ("research") is essential part of engineering.

Lets ask the question reversed: How did people know in the first place what kind of string they need to give to --proxy-header?

> Reading docs ("research") is essential part of engineering.

Sure, but so is safety engineering. Making mechanisms more obvious to use correctly or fail safe if used incorrectly improves outcomes when flawed human beings use them. It also makes them more pleasant to use in general.

Besides, look at the man page in question. It's talking about this in terms of encoding niceties and doesn't even spell out the possibility of deliberate, let alone malicious multiline values:

"curl makes sure that each header you add/replace is sent with the proper end-of-line marker, you should thus not add that as a part of the header content: do not add newlines or carriage returns, they only mess things up for you."

That's inducing a wrong/incomplete mental model of how this parameter works.

> doesn't even spell out the possibility of deliberate, ... multiline values

It does for me, as any kind of extra newlines results in a multi-line string.

> ... malicious ...

Like Daniel said, garbage in, garbage out. If you pass user inputs to curl, one should check what curl does with these values and take proper care.

> do not add newlines or carriage returns, they only mess things up for you

I disagree, but I would say that curl might as well add this as a validation check than a documentation warning.

This is explained in the ticket:

  One of the reasons we still allow that is that this "feature" was used quite deliberately by users in the past and I have hesitated to change that for the risk that it will break some users use cases.

Yes, I'm not sure if I agree with this or not. Those users don't have to upgrade. But obviously I'm not maintaining a key tool for the world. It's just my opinion.