---
id: "CVE-2026-111103"
kind: "vulnerability"
aliases: ["CVE-2026-111103"]
title: "Bandit: HTTP/2 stream error lets clients exceed concurrency limits"
severity: "high"
cvss: 8.2
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["bandit", "elixir", "package", "phoenix", "self-hosted"]
not_affected_if: ["bandit-1.14.0-or-later", "bandit-below-1.9.0", "http1-only"]
published_at: "2026-10-26T14:16:27+00:00"
first_seen_at: "2026-10-26T14:30:36+00:00"
updated_at: "2026-10-26T14:32:22+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111103", "first_seen_at": "2026-10-26T14:30:36+00:00"}]
---

# Bandit: HTTP/2 stream error lets clients exceed concurrency limits

Bandit's HTTP/2 handler rolls back connection state when a frame raises a stream error mid-chunk, so streams opened earlier in the same TCP write escape the concurrent-stream, request and rapid-reset limits. An unauthenticated remote client can therefore run far more Plug requests at once than the configured maximum, enabling resource exhaustion.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Run `mix deps | grep bandit` or check `mix.lock` for the bandit version in use
- Confirm whether the app serves HTTP/2 over Bandit (HTTP/2 enabled in the endpoint options)

## Fix

- Upgrade bandit to `1.14.0` or later
- Until upgraded, disable HTTP/2 on the Bandit endpoint if it is not needed

## Timeline

- 2026-10-26T14:30:36+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-111103

## From the sources

Improper Cleanup on Thrown Exception vulnerability in the HTTP/2 handler of mtrudel bandit allows an unauthenticated remote attacker to bypass per-connection resource limits via a single TCP write that carries several frames, one of which raises a stream error.

When a frame raises StreamError partway through a chunk, Bandit.HTTP2.Handler.handle_data/3 sends RST_STREAM and continues with the connection state from before the chunk, dropping the rest of it. Streams opened by earlier frames in the chunk keep running their Plug calls, but the stream counts, last_stream_id, the rapid-reset timestamps, the HPACK decoder state and the buffer roll back, so max_concurrent_streams, max_requests and the rapid-reset limiter never see those streams. A client that sends one HEADERS frame more than max_concurrent_streams in each write has the extra refused and the others forgotten: with a limit of 10, five such writes run 50 Plug calls at once.

This issue affects bandit: from 1.9.0 before 1.14.0.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_