ae1597c312
Daniel Stenberg
2026-01-02
Subject
VULN-DISCLOSURE-POLICY.md: CRLF in data
Binary
No binary (build failed)
Architecture & Compiler Flags
—
Build Log
(log yok)
Commit Diff GitHub →
docs/VULN-DISCLOSURE-POLICY.md+15 -0
| @@ -354,6 +354,21 @@ using the protocols or options that require the use of those algorithms. | |
| When servers upgrade to use secure alternatives, curl users should use those | |
| options/protocols. | |
| + | ## CRLF in data |
| + | |
| + | curl makes barely any claims of *cleaning* input or rejecting invalid data. A |
| + | user that uses a curl feature can send in *creative* sequences that include |
| + | carriage-return (CR) or line-feed (LF) characters. |
| + | |
| + | Therefore, we reject the idea of *CRLF injection* as a security problem. It is |
| + | a *feature* that users can send creative byte sequences. If users do not want |
| + | to send such octets, they are in control and should avoid sending such bytes |
| + | to curl. |
| + | |
| + | For example, a user might pass in a username that looks like |
| + | `Mr[CR][LF]Smith`. It may cause some minor havoc in the protocol handling, |
| + | depending on what protocol is used. |
| + | |
| # curl major incident response | |
| Vulnerability disclosure manages the full life cycle of a vulnerability | |