From: Daniel Stenberg <daniel@haxx.se>
Date: Fri, 2 Jan 2026 09:54:47 +0000 (+0100)
Subject: VULN-DISCLOSURE-POLICY.md: CRLF in data
X-Git-Tag: curl-8_18_0~36
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=ae1597c312d7614ac7a8be627fff0961c8e26e3c;p=thirdparty%2Fcurl.git

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 bb2b67756c..4ffa1ecb2a 100644
--- 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