A single malformed HTTP/2 stream can gorge your load balancer's memory until the traffic engine keels over
CVE-2026-59762 is a CWE-770 resource-exhaustion flaw in the HTTP/2 request handling path of F5 BIG-IP's Traffic Management Microkernel (TMM). When a virtual server has an HTTP/2 profile attached, an unauthenticated remote attacker can send *undisclosed* request patterns that cause memory allocation without upper bounds. TMM either restarts under duress or becomes unresponsive, dropping every flow behind that VIP. Affected trains: BIG-IP 17.1.0–17.1.3.3, 17.5.0–17.5.1.7, 21.0.0–21.0.0.2, 21.1.0, plus BIG-IP Next for Kubernetes 2.0.0–2.3.1 and Next SPK/CNF. Fixed in 17.1.3.4, 17.5.1.8, 21.0.0.3, 21.1.0.1 and Next 2.2.3 / 2.3.2.
F5's HIGH (7.5) rating is *appropriate and we're leaving it there*. The vector AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:H correctly captures unauth network reach with pure availability impact. It's tempting to downgrade because there's no confidentiality or integrity loss — but BIG-IP data-plane VIPs are, by design, exposed to the internet, HTTP/2 is enabled on the majority of modern web VIPs, and a TMM restart is a full data-plane outage for every app riding that appliance. That's not a nuisance; that's your public web tier going dark on demand.
4 steps from start to impact.
Locate an HTTP/2-enabled BIG-IP VIP
h2). BIG-IP's TLS stack, TMM version banners in error pages, and F5 iRule quirks make identification trivial. Tools: nmap --script http2-info, curl --http2 -v, testssl.sh.- Internet-reachable BIG-IP VIP
- HTTP/2 profile attached to the virtual server
- TLS ALPN advertising
h2
- Internal-only VIPs are not reachable from the internet
- Some deployments still terminate HTTP/1.1 only on legacy VIPs
BIG-IP + alpn:h2 enumerate exposed instances at scale; no scanner needed pre-attack.Send crafted HTTP/2 request stream
x/net/http2 clients.- Established HTTP/2 session (post-TLS ALPN negotiation)
- Knowledge of the specific request pattern (currently undisclosed by F5)
- No public PoC as of the disclosure date
- Some fronting CDNs (Cloudflare, Akamai) will normalize HTTP/2 before it reaches the BIG-IP
Memory pressure builds inside TMM
tmsh show sys memory and tmctl -d blade tmm/procstat reflect the climb.- Sustained request rate
- TMM under normal traffic load already consuming baseline memory
- Very large hardware appliances (i15000, VELOS) have more memory headroom
- Rate-limiting virtual server profiles reduce request throughput
sysStatMemoryUsed trending, iHealth QKView analytics, and Prometheus BIG-IP exporter all surface the climb — if you're actually watching them.TMM restart or hang — data plane outage
- Attacker maintains request pressure through failover events
- HA pair with active/standby buys minutes, not immunity
- Chassis-level redundancy (vCMP + multiple blades) is more resilient
/var/log/ltm restart messages, and monitor-driven pool member marked-down events all fire — post-outage.The supporting signals.
| In-the-wild exploitation | None observed as of 2026-07-20. F5 credits *Okta Red Team* with coordinated disclosure — private discovery, no honeypot hits. |
|---|---|
| Public PoC | No public PoC at disclosure. Related HTTP/2 DoS families (Rapid Reset CVE-2023-44487, MadeYouReset, CERT VU#885548) offer templates; expect reproduction within weeks. |
| EPSS | 0.328% (relatively low percentile). Reflects lack of public exploit code, not lack of exposure. |
| CISA KEV | Not listed as of 2026-07-20. |
| CVSS 3.1 | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H = 7.5 HIGH. CVSS 4.0 rescored to 8.7 HIGH by F5. |
| Affected versions | BIG-IP 17.1.0–17.1.3.3, 17.5.0–17.5.1.7, 21.0.0–21.0.0.2, 21.1.0; BIG-IP Next for Kubernetes 2.0.0–2.3.1; Next SPK/CNF (see K000162231). |
| Fixed versions | 17.1.3.4, 17.5.1.8, 21.0.0.3, 21.1.0.1; Next K8s 2.2.3 / 2.3.2. |
| Exposure population | Shodan surfaces >150k internet-reachable BIG-IP mgmt/data-plane fingerprints; HTTP/2 is enabled on the majority of modern web VIPs. Real exposed population is *substantial*. |
| Disclosure | 2026-07-15 in F5 Quarterly Security Notification (K000159076); article K000162231. |
| Reporter | Okta Red Team, per F5 acknowledgements. |
noisgate verdict.
The single decisive factor is role multiplier — this is an unauthenticated availability bug in a network-edge appliance whose entire job is to sit on the internet, and HTTP/2 is enabled on the majority of modern VIPs, so realistic exposure is high. It stays at HIGH rather than climbing to CRITICAL because impact is bounded to availability — no code execution, no data disclosure, no lateral pivot.
Why this verdict
- Unauthenticated + network-reachable: vector
AV:N/PR:N/UI:Nwith zero friction on prerequisites — the affected surface is the same TCP:443 the appliance is designed to expose. - Role multiplier — network edge appliance: BIG-IP LTM/ADC canonically sits at the perimeter fronting business-critical apps. A TMM crash is not a single-host outage; it's a fleet-of-apps outage. This alone floors the verdict at HIGH.
- Blast radius ceiling — availability only:
C:N/I:N/A:Hmeans no code exec, no data theft, no persistence, no lateral movement. That is the reason the verdict does *not* climb to CRITICAL despite the edge-role multiplier. - Exposure population is high, not niche: HTTP/2 profiles are the modern default for web VIPs; unlike management-plane bugs, this hits the data plane every BIG-IP is provisioned to serve.
- No KEV, no public PoC, low EPSS (0.3%) — for now: with Okta Red Team as the finder and F5's disclosure released, weaponization is a question of weeks, not months. Don't confuse *quiet* with *safe*.
Why not higher?
CRITICAL is reserved for chains that end in code execution, data compromise, or takeover. This is pure availability impact bounded by TMM restart — the appliance recovers, HA failover buys time, and no credentials or data leave the box. The role-multiplier floor for a network edge appliance with availability-only impact is HIGH, not CRITICAL.
Why not lower?
Downgrading to MEDIUM would require either an authentication requirement, a niche affected surface, or meaningful deployment friction — none apply. Unauth internet-reachable DoS against the perimeter appliance protecting your revenue-generating apps is not a MEDIUM in any risk framework worth using.
What to do — in priority order.
- Disable HTTP/2 on non-essential virtual servers — Detach the
http2profile from any VIP that doesn't strictly require it — clients will fall back to HTTP/1.1 via ALPN. This eliminates the vulnerable code path entirely. Deploy within 30 days per noisgate mitigation SLA for HIGH. - Front BIG-IP VIPs with a CDN or upstream L7 proxy — Cloudflare, Akamai, Fastly, or an upstream nginx will terminate and normalize HTTP/2 before frames reach BIG-IP TMM. The malicious pattern is absorbed at the CDN edge. Feasible for public web VIPs within 30 days.
- Apply strict connection and request-rate limits — Use BIG-IP AFM/LTM
Rate Limitingprofiles and connection profiles capping concurrent HTTP/2 streams per client IP. This slows exhaustion and buys detection time. Deploy within 30 days. - Alert aggressively on TMM memory and restart events — SNMP
sysStatMemoryUsed+/var/log/ltmTMM restart syslog to your SIEM with page-out on threshold. You need to know *during* the attack, not after the outage post-mortem. Deploy within 7 days. - Verify HA pair health and failover behavior — Confirm active/standby is genuinely active/standby, not active/degraded. A flapping HA pair under repeated TMM crashes is worse than a single unit. Validate within 30 days.
- WAF signatures (ASM/Advanced WAF policies): F5 has not published the specific request pattern, so no signature exists — and generic HTTP/2 anomaly rules routinely false-positive on modern browsers.
- IP allowlists on the data plane: these are public-facing VIPs by design; you can't allowlist the internet.
- Restricting management plane access: this is a data-plane bug on TMM. Locking down TMOS/iControl won't help.
- Reducing TMM memory allocation: shrinks the amount of memory the attacker has to fill — trigger fires *faster*, not slower.
Crowdsourced verification payload.
Run on an auditor workstation with network reach to the BIG-IP management interface, or SSH directly to the BIG-IP as an admin-role user. Invoke as ./check_cve_2026_59762.sh <bigip-mgmt-host-or-localhost>. Requires either SSH key/password for the BIG-IP or local shell on the appliance.
#!/usr/bin/env bash
# CVE-2026-59762 — F5 BIG-IP HTTP/2 memory exhaustion checker
# Usage: ./check_cve_2026_59762.sh <bigip-host-or-localhost>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
TARGET="${1:-localhost}"
run() {
if [ "$TARGET" = "localhost" ]; then
bash -c "$1" 2>/dev/null
else
ssh -o StrictHostKeyChecking=no -o ConnectTimeout=10 "admin@${TARGET}" "$1" 2>/dev/null
fi
}
VER=$(run "tmsh show sys version | grep -A1 'Main Package' | awk '/Version/ {print \$2}'")
if [ -z "$VER" ]; then
echo "UNKNOWN: could not retrieve BIG-IP version from $TARGET"
exit 2
fi
echo "BIG-IP version detected: $VER"
# Fixed versions per F5 K000162231
vuln=0
case "$VER" in
17.1.*)
# fixed in 17.1.3.4
printf '%s\n17.1.3.4\n' "$VER" | sort -V -C && vuln=0 || vuln=1 ;;
17.5.*)
printf '%s\n17.5.1.8\n' "$VER" | sort -V -C && vuln=0 || vuln=1 ;;
21.0.*)
printf '%s\n21.0.0.3\n' "$VER" | sort -V -C && vuln=0 || vuln=1 ;;
21.1.*)
printf '%s\n21.1.0.1\n' "$VER" | sort -V -C && vuln=0 || vuln=1 ;;
*)
echo "UNKNOWN: version $VER not in known-affected trains — verify manually against K000162231"
exit 2 ;;
esac
# Check whether any virtual server actually has an http2 profile attached
H2_VIPS=$(run "tmsh list ltm virtual one-line | grep -c 'profiles.*http2'")
H2_VIPS=${H2_VIPS:-0}
echo "Virtual servers with HTTP/2 profile: $H2_VIPS"
if [ "$vuln" -eq 1 ] && [ "$H2_VIPS" -gt 0 ]; then
echo "VULNERABLE: version $VER is affected AND $H2_VIPS VIP(s) use http2"
exit 1
elif [ "$vuln" -eq 1 ] && [ "$H2_VIPS" -eq 0 ]; then
echo "VULNERABLE (code present) but no VIP currently exposes HTTP/2 — still patch"
exit 1
else
echo "PATCHED: version $VER is at or above the fixed release for its train"
exit 0
fi
If you remember one thing.
Sources
- NVD — CVE-2026-59762
- F5 K000162231 — BIG-IP HTTP/2 vulnerability CVE-2026-59762
- F5 K000159076 — Quarterly Security Notification (July 2026)
- CERT/CC VU#885548 — HTTP/2 stalled flow-control DoS
- CSA Singapore — Multiple Vulnerabilities in F5 NGINX, BIG-IP and BIG-IQ
- F5 DevCentral — HTTP/2 bomb attack analysis
- ThreatINT — CVE-2026-59762
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.