Bandit CVE-2026-39807

Exploitation requires that Bandit is accessible over plaintext HTTP (not TLS-terminated) and the attacker either (a) controls a network path to the server (transparent proxy, compromised ISP, or rogue WiFi), (b) can send direct TCP connections to Bandit's plaintext port, or (c) can induce a client to connect through a network the attacker controls. No authentication is required; the attack succeeds against default Bandit configuration with no special settings needed. Downstream exploitation of the false scheme value depends on application code: if the app does not check conn.scheme for security decisions, the vulnerability has no effect; if it does (e.g., Plug.SSL middleware, custom cookie logic, CSRF token gating), the impact manifests. The core issue is that Bandit's behavior is correct only when running behind a TLS-terminating proxy that strips client-supplied scheme headers; direct internet exposure without such a proxy leaves the server vulnerable.

CVSS 6.3 with AV:N (network-accessible) and AC:L (low complexity) indicates broad attack surface, but the AT:P (passive attack) modifier signals that exploitation requires the attacker to intercept or control a network path. Real-world risk depends critically on deployment context: (1) In transparent proxies, CDNs, or load balancers where the attacker can inject or manipulate HTTP headers destined for Bandit, exploitation is trivial and requires no additional user interaction or authentication. (2) If Bandit is directly internet-facing without a proxy layer, the attacker must establish a direct TCP connection to the plaintext HTTP port and inject a malicious scheme-realistic over compromised networks or via DNS rebinding but less common in typical deployments. The impact is not remote code execution but security property violations (VC:L/VI:L indicating low confidentiality and integrity impact per CVSS 4.0 scale), yet the downstream effects are significant: authentication bypass via cookie theft, CSRF token bypass, and audit log spoofing. The absence of active exploitation signals (no KEV status, no public POC referenced in input) suggests this is a recently disclosed or low-prevalence issue, but the straightforward attack vector and clear proof-of-concept in the source code commit mean exploitation tooling could appear quickly. Organizations running Bandit behind untrustworthy proxies or on public internet-facing infrastructure should prioritize patching; those with TLS-terminating reverse proxies in front may have lower immediate risk but should still apply the fix to prevent security assumption violations.

An attacker on a network path between a client and a Bandit server (e.g., rogue WiFi, compromised ISP, or CDN) intercepts HTTP traffic destined for plaintext Bandit port 80. The attacker injects or modifies the HTTP/1.1 request to use absolute-form with an https:// scheme (GET https://victim.com/login HTTP/1.1) or sets the HTTP/2 :scheme pseudo-header to https. Bandit's determine_scheme/2 function returns scheme='https', and the Plug connection is marked as secure. If the application relies on Plug.SSL's conn.scheme check to gate HTTPS-only features, the redirect is skipped; if cookies are issued with secure: true, they are transmitted over unencrypted TCP and logged by packet sniffers; if a CSRF token is only issued over 'https', it may be issued over plaintext. The attacker can then harvest sensitive cookies, forge requests without valid CSRF tokens, or perform account takeover.