This could potentially allow attackers to redirect users to malicious websites or resources, leading to phishing attacks or the exploitation of sensitive information.

Keep in mind the big warning at the top of https://docs.python.org/3/library/http.server.html :

Warning: http.server is not recommended for production. It only implements basic security checks.

Keep in mind the big warning at the top of https://docs.python.org/3/library/http.server.html :

That said, I think this probably falls under the category of "basic security checks." I've tentatively added all the version labels, but I'm also fine with backporting this to only 3.13 as a bugfix.

http.server is really meant to be used for serving files locally, and/or in a testing envionrment, or in an environment that students need to attack for whatever reasons. I won't consider this a security issue personally and I wouldn't bother indicating this as well.

Making it so to avoid open redirect vulnerabilities is honestly too much for this module. cc @gpshead

Craft a payload containing /\\oast.me/%2e%2e%2f..

I think the double backslash was only intended for the shell command line. The argument passed to Curl and the HTTP protocol only get a single backslash.

The following production may be conceptually easier to understand:

$ mkdir '\oast.me'  # Directory causes Python to redirect
$ curl -I --location -vs -o /dev/null 'http://127.0.0.1:8080/\oast.me'
. . .
> HEAD /\oast.me HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
* HTTP 1.0, assume close after body
< HTTP/1.0 301 Moved Permanently
< Server: SimpleHTTP/0.6 Python/3.12.9
< Date: Fri, 25 Apr 2025 00:26:32 GMT
< Location: /\oast.me/
< Content-Length: 0
<
* Closing connection 0
* Issue another request to this URL: 'http://127.0.0.1:8080/\oast.me/'
. . .
> HEAD /\oast.me/ HTTP/1.0
> Host: 127.0.0.1:8080
> User-Agent: curl/7.68.0
> Accept: */*

Location header includes /\oast.me/%2e%2e%2f/. It redirects to http://oast.me/..%2f/.

To redirect to a different host, the client would have to interpret the backslash like a second forward slash. None of the versions of Curl I tried did this. I did find the Chrome browser interpreted the redirect as to the host //oast.me, but I did not find a way for Chrome to make an initial HTTP request with the backslash.

The problem is that the Python server accepts a backslash character in the request, handles it like an unreserved URL character, and includes the backslash in the URL its response. However a backslash is not allowed in URLs according to RFC 3986. It is plausible that a client could interpret the backslash differently like Chrome did.

This is a case of garbage in, garbage out. Ideally a server would send a valid HTTP response, such as a 400 Bad Request error, or with the backslash encoded as %5C.