HTTP client proxy tunnel headers not validated for CR/LF

CVE-2026-1502 is a CR/LF injection flaw in CPython's http.client CONNECT-tunneling path. Before the April 2026 fixes, HTTPConnection.set_tunnel() could accept tunnel host or tunnel header values containing carriage-return/line-feed characters, letting malformed data alter the CONNECT request sent to an upstream HTTP proxy. Upstream references show fixes landing in current branches including Python 3.13.13 and 3.14.4, with security backports also queued/applied for 3.10/3.11/3.12 branches; the unfixed development line was effectively pre-3.15.0.

The vendor's MEDIUM 5.7 is technically defensible in a lab, but it is too hot for enterprise patch triage. Real exploitation requires an application to use Python's proxy tunneling feature, pass attacker-influenced values into set_tunnel(), and route through a proxy where modified CONNECT headers actually change behavior. That's a narrow, post-design-mistake chain with tiny exposed population, no KEV listing, no public in-the-wild evidence, and a near-zero EPSS.

Why this verdict

• Attacker position is already constrained: this is not unauthenticated remote-to-RCE; the CNA vector itself says PR:H and UI:P, and real abuse requires control over values fed into set_tunnel().
• Exposure population collapses fast: only apps using Python's CONNECT proxy tunneling are in scope, and only a subset of those let untrusted input reach tunnel host or headers.
• Modern controls should catch adjacent mistakes: secure coding review, SAST, outbound proxy validation, and egress monitoring all reduce exploitability long before this becomes an estate-wide incident.
• Blast radius is narrow: impact is integrity manipulation of a proxied request path, not host takeover, credential dumping, or remote wormability.
• Threat intel is cold: no KEV, no public campaign reporting, no mass-scanning signal, and an EPSS of 0.00024 all push this down.

Why not higher?

To justify MEDIUM or HIGH in a 10,000-host environment, you would want broader reachability, simpler attacker position, or active exploitation evidence. This flaw instead stacks multiple prerequisites: specific stdlib feature use, attacker-controlled input, CONNECT proxying, and favorable proxy-side parsing. That is too much compounding friction for a higher queue position.

Why not lower?

It is not pure non-issue territory because the bug is real, fixed upstream, and can alter request integrity in environments that depend on CONNECT proxies. If you run Python services that broker outbound traffic or let tenants influence proxy destinations or headers, there is a legitimate though narrow abuse case. That keeps it above IGNORE.

1. Audit set_tunnel() usage — Search application code and dependencies for HTTPConnection.set_tunnel( and wrappers around http.client; this identifies the tiny subset of hosts where the CVE is even reachable. For a LOW verdict there is no fixed mitigation deadline, so do this as backlog hygiene during normal engineering cycles.
2. Block control characters at app boundaries — Reject \r and \n in proxy hostnames, CONNECT metadata, and any custom header values before they reach stdlib networking calls. This is the right temporary guard if you cannot patch immediately; for LOW, deploy during normal code-hardening work rather than emergency change windows.
3. Harden outbound proxy policy — Configure egress proxies to reject malformed CONNECT requests and unexpected custom CONNECT headers where possible. That cuts off the downstream interpreter-dependent impact and is useful regardless of runtime version.
4. Log CONNECT anomalies — Turn on or retain outbound proxy logging for malformed CONNECT attempts, repeated 4xx responses, or unexpected header patterns from Python application tiers. This gives you the only realistic detection path if someone probes the edge cases.

Run this on the target host using the same Python interpreter your application uses, or from your software inventory pipeline against each discovered python binary. Invoke it as python3 check_cve_2026_1502.py or C:\Python313\python.exe check_cve_2026_1502.py; no admin rights are required, but you must run the specific interpreter instance you want to assess.

#!/usr/bin/env python3
# CVE-2026-1502 verifier for CPython http.client CONNECT tunnel CR/LF validation
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import inspect
import re
import sys

STATUS_PATCHED = 0
STATUS_VULNERABLE = 1
STATUS_UNKNOWN = 2


def out(msg):
    sys.stdout.write(msg + "\n")


def main():
    try:
        import http.client as hc
    except Exception as e:
        out(f"UNKNOWN: failed to import http.client: {e}")
        return STATUS_UNKNOWN

    ver = sys.version.split()[0]

    try:
        src = inspect.getsource(hc.HTTPConnection._tunnel)
    except Exception as e:
        out(f"UNKNOWN: could not inspect http.client.HTTPConnection._tunnel on Python {ver}: {e}")
        return STATUS_UNKNOWN

    # Heuristic 1: patched code added explicit tunnel-host validation and header name/value validation.
    checks = [
        "_contains_disallowed_url_pchar_re.search(self._tunnel_host)",
        "_is_legal_header_name",
        "_is_illegal_header_value",
        "Invalid header name",
        "Invalid header value",
        "Tunnel host can't contain control characters",
    ]

    found = [c for c in checks if c in src]

    # Heuristic 2: behavior test. Vulnerable versions typically accept CR/LF into tunnel headers until send time.
    behavior_result = None
    try:
        conn = hc.HTTPConnection("example.com")
        conn.set_tunnel("example.org", headers={"X-Test": "ok\r\nInjected: yes"})
        # If we got here without ValueError, that's a strong vulnerable signal.
        behavior_result = "accepted_bad_header"
    except ValueError:
        behavior_result = "rejected_bad_header"
    except TypeError:
        behavior_result = "rejected_bad_header"
    except Exception:
        # Unexpected exception; source-based result will decide.
        behavior_result = "indeterminate"

    if len(found) >= 4 and behavior_result == "rejected_bad_header":
        out(f"PATCHED: Python {ver} contains tunnel host/header validation consistent with CVE-2026-1502 fix")
        return STATUS_PATCHED

    if len(found) <= 1 and behavior_result == "accepted_bad_header":
        out(f"VULNERABLE: Python {ver} accepted CR/LF in set_tunnel() header data and lacks fix markers")
        return STATUS_VULNERABLE

    # Mixed case: report what we saw so operators can decide.
    out(
        "UNKNOWN: inconclusive result for Python {} (fix markers found: {}; behavior: {})".format(
            ver, len(found), behavior_result
        )
    )
    return STATUS_UNKNOWN


if __name__ == "__main__":
    sys.exit(main())

Sources

1. Python security announcement
2. Upstream issue gh-146211
3. Upstream fix commit 05ed7ce
4. NVD record for CVE-2026-1502
5. Python 3.13.13 release page
6. Python 3.14.4 release page
7. CISA Known Exploited Vulnerabilities catalog
8. FreeBSD VuXML entry