VULN-DISCLOSURE-POLICY.md: CRLF in data

we reject the idea of *CRLF injection* by the user itself as a general
security problem

Closes #20157

diff --git a/docs/VULN-DISCLOSURE-POLICY.md b/docs/VULN-DISCLOSURE-POLICY.md
index bb2b67756c323d9704ee6e0890b3d3dd387e8714..4ffa1ecb2adaa94b2ccb1d99570b4b7d8cfe8cb7 100644 (file)
--- a/docs/VULN-DISCLOSURE-POLICY.md
+++ b/docs/VULN-DISCLOSURE-POLICY.md
@@ -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