This is far from uncommon. Back in DEFCON 2017 Orange Tsai gave a talk about inconsistencies in different URL parsing libraries in different languages. The opening example was a single URL that had a different hostname when parsed by urllib, urllib2, and requests. He also demoed examples of using unusual characters like spaces and newlines to talk to Redis or SMTP while pretending to be HTTP.<p>Slides: <a href="https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Orange-Tsai-A-New-Era-of-SSRF-Exploiting-URL-Parser%20in-Trending-Programming-Languages-UPDATED.pdf" rel="nofollow">https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20pre...</a>
Python urllib3 maintainer here. urllib3 made a change to be more RFC-compliant in December, and which fixed this issue, but that change has not been released yet. We are in the process of looking into that.<p>I have verified that Requests, which uses us, appears to have its own handling, back at least to requests 2.0 (released in 2013) that prevents this when used directly as an abstraction layer on top of urllib3.
The link should probably be changed to the actual bug: <a href="https://bugs.python.org/issue36276" rel="nofollow">https://bugs.python.org/issue36276</a>
Python 3 urllib and other stdlib protocol modules also use `splitlines` which splits on various unicode "newlines". Could that also be exploitable somehow? <a href="https://discuss.python.org/t/changing-str-splitlines-to-match-file-readlines/174" rel="nofollow">https://discuss.python.org/t/changing-str-splitlines-to-matc...</a>
Key takeaway: don't expect a library to do the safe thing; always sanitize all your input. (If your language supports taint mode, enabling it can prevent these bugs)
Does anyone know if this also affects the Requests library? Does it use these under the hood, or is it all httplib? (I'm pretty sure that's the case)
seems like an ad for coocoor<p>actual CVE entry: <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9740" rel="nofollow">http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9740</a>