Document CRLF handling for `http.server`

[aydinnyunus]

Bug report

Bug description:

Vulnerability Description

The send_header method in Lib/http/server.py writes headers directly to the output stream without checking for line breaks. When user-controlled input is passed to send_header, an attacker can inject CRLF sequences (\r\n) to terminate the current header and inject new headers or manipulate the response.

Vulnerable Code:

def send_header(self, keyword, value):
 """Send a MIME header to the headers buffer."""
 if self.request_version != 'HTTP/0.9':
 if not hasattr(self, '_headers_buffer'):
 self._headers_buffer = []
 self._headers_buffer.append(
 ("%s: %s\r\n" % (keyword, value)).encode('latin-1', 'strict'))
 # No validation for \r or \n characters!

---

Attack Scenarios

Scenario 1: Set-Cookie Injection (Session Fixation)

Vulnerable Application:

from http.server import BaseHTTPRequestHandler, HTTPServer
from urllib.parse import parse_qs, urlparse

class VulnerableHandler(BaseHTTPRequestHandler):
 def do_GET(self):
 query = parse_qs(urlparse(self.path).query)
 custom_val = query.get('val', [''])[0]
 
 self.send_response(200)
 # VULNERABLE: Direct injection into header
 self.send_header('X-Custom', custom_val)
 self.end_headers()
 self.wfile.write(b"Hello World")

Attack URL:

http://localhost:8000/?val=test%0d%0aSet-Cookie:%20pwned=true

Result:

HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.x
Date: ...
X-Custom: test
Set-Cookie: pwned=true

Impact: Attacker can inject session cookies, leading to session fixation attacks.

---

Scenario 2: Location Header Injection (Malicious Redirect)

Attack URL:

http://localhost:8000/?val=test%0d%0ALocation:%20http://evil.com/

Result:

HTTP/1.0 200 OK
Server: BaseHTTP/0.6 Python/3.x
Date: ...
X-Custom: test
Location: http://evil.com/

Impact:

• Users are redirected to malicious websites
• Phishing attacks
• Open redirect vulnerabilities
• Cache poisoning (if cached responses include the injected Location header)

Verified Test Results:

✓ LOCATION HEADER INJECTION CONFIRMED!
 Injected Location: http://evil.com/
✓ MALICIOUS REDIRECT CONFIRMED!
 Browser would redirect to: http://evil.com/
✓ MALICIOUS REDIRECT SUCCESSFUL!

---

Attack Vector

• Type: Remote
• Prerequisites:
  • Application uses http.server.BaseHTTPRequestHandler
  • User input is reflected in HTTP headers via send_header()
  • Common patterns: query parameters, user-agent reflection, custom headers
• Complexity: Low - Simple URL manipulation
• Authentication: Not required

---

Impact

1. Session Fixation: Inject Set-Cookie headers to control user sessions
2. Malicious Redirects: Inject Location headers to redirect users to attacker-controlled sites
3. Cache Poisoning: Inject headers that affect cached responses
4. Cross-Site Scripting (XSS): Inject headers that enable XSS attacks
5. Web Cache Deception: Manipulate cache behavior via injected headers

CPython versions tested on:

CPython main branch

Operating systems tested on:

macOS

Linked PRs

• gh-142533: Prevent CRLF injection in HTTP headers #142605
• gh-142533: Document CRLF injection vulnerability in http.server and wsgiref modules #143395
• [3.14] gh-142533: Document CRLF injection vulnerabilities in http.server doc (GH-143395) #148020
• [3.13] gh-142533: Document CRLF injection vulnerabilities in http.server doc (GH-143395) #148021

[tadejmagajna]

Thank you for reporting, the bug makes sense. Goes without saying both keyword and value are vulnerable.

I would like to work on this if that's okay.

[picnixz]

http.server is not meant to be used in production, I honestly don't consider this a vulnerability worth the change. If the validation is small, we could consider it but there is a huge warning saying that we are aware of those vulns (or if it's not mentioned, we just update the docs).

[aydinnyunus]

There’s a warning advising against using it in production, but I haven’t found any specific explanation about whether CRLF injection vulnerabilities are taken into account.

The relevant section is here: https://docs.python.org/3/library/http.server.html#security-considerations

[picnixz]

Yes, so we have two possibilities:

• Make the validation. But honestly, I don't want the code to become more and more complex. The module is not meant for advanced use, and usually only for local testing. Now, if the validation algorithm is not too big, we can add it. What matters is that we don't overcomplicate code for which there are better replacements on PyPI.
• Update the docs. That's minimal effort on our side, and at least we would mention this. I know that there are CRLF vulns in wsgiref for instance that were reported (and maybe fixed I don't remember now) so maybe people do expect to have the same minimal guards for whatever server we provide.

[aydinnyunus]

I think the fix is straightforward. A simple validation check should be enough. I also reviewed the wsgiref implementation and didn't see any existing safeguard for this. We can apply the same fix to both components without much complexity. What do you think?

if '\r' in value or '\n' in value:
 raise ValueError("Header value contains invalid characters (CR or LF)")

[tadejmagajna]

The suggestion to apply fixes for both wsgiref and http.server makes sense.
Taking into account the above suggestion to keep changes minimal, I implemented the change in the linked PR.

Also adjusted the ValueError message slightly for consistency with other wsgiref exceptions.