Maybe this one, which kind of violates the principle of least surprise (but not a security risk)

> When curl is invoked, it (unless --disable is used) checks for a default config file and uses it if found, even when --config is used. The default config file is checked for in the following places in this order:

> When there is a remote attacker already present in the server, curl cannot protect its operations against mischief.

Does that mean that if I wanted to fetch an URL from a malicious server and write the response to stdout, but the server managed to trick curl into saving it to a file with server-controlled filename, despite the commandline options, that would not be a vulnerability in curl?

> When using curl to perform transfers with protocols that are insecure [...]

I'm thinking of less advanced /knowledgeable users. Should they be knowing which protocols are secure? Maybe a few examples, like telnet & http vs. ssh & https?

Also, are insecure protocols synonymous with unencrypted, or are there insecure encrypted protocols that have other flaws, like bad choice of weak/broken ciphers? Assuming insecure protocols could select them automatically without error.