CVE-2026-70616: boringproxy DoS Vulnerability

CVE-2026-70616 Overview

CVE-2026-70616 is a resource exhaustion vulnerability in boringproxy through version 0.10.0. Any authenticated user can permanently exhaust server file descriptors, goroutines, and memory by sending requests to the GET /loading endpoint with attacker-supplied id query parameter values. The handler performs no map-lookup validity check and receives on a nil channel that blocks forever. With no timeout, no context cancellation, and no server-side reclamation, each malicious request permanently holds one goroutine, one file descriptor, and roughly 50 kB of memory.

Critical Impact
Once the server's file descriptor limit is reached, listener Accept calls fail and all tunnel traffic forwarding halts for every user.

Affected Products

boringproxy through version 0.10.0

Discovery Timeline

2026-08-05 - CVE-2026-70616 published to NVD
2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-70616

Vulnerability Analysis

The flaw is classified under [CWE-833] (Deadlock) and manifests in the GET /loading request handler. When boringproxy receives a request with an id query parameter, the handler looks up the identifier in an internal map without verifying that the key exists. When the lookup returns a zero value, the handler proceeds to receive on a nil channel. In Go, a receive on a nil channel blocks the goroutine forever.

Because boringproxy configures no HTTP server timeouts, the request never terminates. The goroutine, its associated file descriptor, and approximately 50 kB of stack and heap memory remain allocated indefinitely. Each additional malicious request compounds the exhaustion until the operating system file descriptor limit is exhausted.

Root Cause

The root cause is a combination of missing input validation and unbounded resource lifetime. The handler assumes the client-supplied id corresponds to a valid pending job and does not check the map return value. The server also lacks ReadTimeout, WriteTimeout, and IdleTimeout settings on its http.Server, so blocked goroutines are never reaped.

Attack Vector

An authenticated attacker sends repeated GET /loading?id=<attacker-value> requests over the network. Because privileges required are low and no user interaction is needed, any tenant on a shared boringproxy instance can trigger the condition. The attack requires only enough requests to exceed the process file descriptor limit, at which point new tunnel connections stop being accepted for all users. See the VulnCheck Advisory on Resource Exhaustion and the GitHub README on the DoS Vulnerability for the researcher's technical walkthrough.

Detection Methods for CVE-2026-70616

Indicators of Compromise

Repeated GET /loading requests carrying unusual or randomized id query parameter values from a single authenticated principal.
Steady, monotonic growth in the boringproxy process file descriptor count and goroutine count without a corresponding rise in legitimate tunnel activity.
Listener Accept errors in boringproxy logs indicating file descriptor exhaustion.

Detection Strategies

Instrument boringproxy with Go runtime metrics (runtime.NumGoroutine, open file descriptor counts) and alert on sustained upward trends.
Parse web access logs for high-rate requests to /loading with distinct id values that never resolve to a subsequent tunnel connection.
Correlate authenticated session identifiers with per-user request volume to isolate abusive accounts.

Monitoring Recommendations

Track ulimit -n headroom on hosts running boringproxy and alert when utilization exceeds 70 percent.
Log and rate-limit at a reverse proxy in front of boringproxy to bound requests per authenticated user.
Monitor tunnel establishment success rates as a downstream health signal for early exhaustion detection.

How to Mitigate CVE-2026-70616

Immediate Actions Required

Restrict access to the boringproxy control plane to trusted authenticated users only, and revoke credentials for any account not required for tunnel operation.
Place boringproxy behind a reverse proxy that enforces per-user request rate limits and connection timeouts.
Configure operating system file descriptor limits high enough to survive short bursts while alerting on approach to the ceiling.

Patch Information

No vendor patch is referenced in the advisory data at the time of publication. Track the upstream boringproxy repository issue tracker via the researcher's disclosure and the VulnCheck Advisory for fix availability past version 0.10.0.

Workarounds

Front boringproxy with an HTTP proxy such as nginx or Caddy that sets aggressive proxy_read_timeout and client_body_timeout values for the /loading path.
Enforce per-source rate limiting on /loading to cap the number of concurrent long-lived requests any single authenticated user can create.
Periodically restart the boringproxy process on a schedule to reclaim leaked goroutines and file descriptors until an upstream fix ships.

bash

# Example nginx configuration to bound /loading request lifetime and rate
location /loading {
    proxy_pass http://127.0.0.1:8080;
    proxy_read_timeout 10s;
    proxy_send_timeout 10s;
    client_body_timeout 10s;
    limit_req zone=loading_zone burst=5 nodelay;
}

# Define the rate limit zone in the http block
# limit_req_zone $binary_remote_addr zone=loading_zone:10m rate=5r/m;