<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Request Smuggling on Nalar</title>
    <link>https://nalar.dev/tags/request-smuggling/</link>
    <description>Recent content in Request Smuggling on Nalar</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 16 Sep 2026 00:00:00 +0700</lastBuildDate>
    <atom:link href="https://nalar.dev/tags/request-smuggling/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>HTTP Request Smuggling Starts When Intermediaries Disagree on Message Boundaries</title>
      <link>https://nalar.dev/http-request-smuggling-starts-when-intermediaries-disagree-on-message-boundaries/</link>
      <pubDate>Wed, 16 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/http-request-smuggling-starts-when-intermediaries-disagree-on-message-boundaries/</guid>
      <description>&lt;p&gt;A reverse proxy accepts an HTTP/1.1 request, decides where its body ends, and forwards traffic to an application server over a persistent connection. If the application server reaches a different boundary from the same framing information, the two components stop agreeing about which bytes belong to which request. Bytes treated as body data by one component can become the start of a new request for the other.&lt;/p&gt;&#xA;&lt;p&gt;That disagreement is the core condition behind HTTP request smuggling. The defect is not simply a malformed header, a proxy, or connection reuse in isolation. It is a parser differential across a chain in which multiple recipients interpret request framing and at least one connection carries subsequent traffic.&lt;/p&gt;</description>
    </item>
    <item>
      <title>HTTP Request Smuggling Starts at Message-Boundary Disagreement</title>
      <link>https://nalar.dev/http-request-smuggling-starts-at-message-boundary-disagreement/</link>
      <pubDate>Tue, 15 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/http-request-smuggling-starts-at-message-boundary-disagreement/</guid>
      <description>&lt;h1 id=&#34;http-request-smuggling-starts-at-message-boundary-disagreement&#34;&gt;HTTP Request Smuggling Starts at Message-Boundary Disagreement&lt;/h1&gt;&#xA;&lt;p&gt;A reverse proxy can validate an HTTP request, forward it to an application server, and still leave both systems with different views of where that request ends. The bytes do not need to change in transit. The security failure appears when two parsers assign different boundaries to the same stream.&lt;/p&gt;&#xA;&lt;p&gt;That disagreement is the core of HTTP request smuggling. One component consumes a prefix as a complete request while another treats additional bytes as part of that request, or as the beginning of a following one. On a reused backend connection, the leftover bytes can alter the interpretation of traffic that arrives later.&lt;/p&gt;</description>
    </item>
    <item>
      <title>HTTP Request Smuggling Exploits Parser Disagreement</title>
      <link>https://nalar.dev/http-request-smuggling-exploits-parser-disagreement/</link>
      <pubDate>Mon, 14 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/http-request-smuggling-exploits-parser-disagreement/</guid>
      <description>&lt;h1 id=&#34;http-request-smuggling-exploits-parser-disagreement&#34;&gt;HTTP Request Smuggling Exploits Parser Disagreement&lt;/h1&gt;&#xA;&lt;p&gt;A reverse proxy and an application server can each parse the same byte stream according to rules that appear reasonable in isolation. Trouble starts when they reach different answers about where one request ends. Bytes treated as the tail of a request by the front end can become the start of another request at the back end, shifting the interpretation of traffic that follows on a reused connection.&lt;/p&gt;</description>
    </item>
    <item>
      <title>HTTP Request Boundaries Must Survive Every Parser</title>
      <link>https://nalar.dev/http-request-boundaries-must-survive-every-parser/</link>
      <pubDate>Sat, 12 Sep 2026 00:00:00 +0700</pubDate>
      <guid>https://nalar.dev/http-request-boundaries-must-survive-every-parser/</guid>
      <description>&lt;p&gt;A reverse proxy can reject a request as malformed and still leave a dangerous assumption intact: that every other HTTP parser in the path would have found the same message boundary. Modern web stacks routinely place a CDN, load balancer, gateway, service proxy, framework server, and application logic between a client and the code that handles a request. A single connection can therefore pass through several independent implementations of HTTP framing.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
