https://blog.hive.red/en/tags/response-splitting/ Recent content in Response Splitting on Red Hive Hugo en-us info@hive.red (Red Hive) info@hive.red (Red Hive) <a href="https://creativecommons.org/licenses/by-nc/4.0/" target="_blank" rel="noopener">CC BY-NC 4.0</a> Fri, 14 Aug 2026 00:00:00 +0000 https://blog.hive.red/en/posts/reversedesync/ Fri, 14 Aug 2026 00:00:00 +0000info@hive.red (Red Hive) https://blog.hive.red/en/posts/reversedesync/ <h2 id="tldr">TL;DR</h2> <p>After reading the research by <a href="https://portswigger.net/research/crlf-powered-desync-attacks">Tom Stacey (@t0xodile) and Tobia Righi (@m4st3rspl1nt3r)</a> on <em>CRLF-Powered Desync Attacks</em>, I wanted to dive deeper into a specific aspect: <strong>Reverse Desyncs</strong> (Response Splitting).</p> <p>I wanted to find out if they were still possible, even if just in a lab environment, what technology stack would allow it, and whether such a configuration is plausible in the wild. I empirically tested how various HTTP clients handle stacked responses and discovered that <strong><code>httpx</code></strong> (the most widely used HTTP client in Python) follows the RFC to the letter, thus lacking the &ldquo;over-read&rdquo; mitigation that protects browsers, <code>curl</code>, and other libraries.</p>