← Back to Feed CACHED · 2026-07-20 08:05:42 · CACHE_KEY CVE-2026-59762
CVE-2026-59762 · CWE-770 · Disclosed 2026-07-15

When an HTTP/2 profile is configured on a virtual server

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

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.

"Unauthenticated DoS against a data-plane HTTP/2 listener on your perimeter — TMM restarts drop every connection behind the VIP."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Locate an HTTP/2-enabled BIG-IP VIP

Attacker fingerprints public-facing services and identifies BIG-IP virtual servers negotiating HTTP/2 via ALPN (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.
Conditions required:
  • Internet-reachable BIG-IP VIP
  • HTTP/2 profile attached to the virtual server
  • TLS ALPN advertising h2
Where this breaks in practice:
  • Internal-only VIPs are not reachable from the internet
  • Some deployments still terminate HTTP/1.1 only on legacy VIPs
Detection/coverage: Shodan/Censys queries for BIG-IP + alpn:h2 enumerate exposed instances at scale; no scanner needed pre-attack.
STEP 02

Send crafted HTTP/2 request stream

Attacker opens an HTTP/2 connection and issues the undisclosed request pattern that triggers unbounded allocation in TMM's HTTP/2 state machine. Public PoCs are not yet published, but recent HTTP/2 primitives (Rapid Reset, MadeYouReset, CONTINUATION floods, stalled flow-control per CERT VU#885548) provide a template. Tools that will trivially weaponize this once details drop: h2load, nghttp2, custom Go x/net/http2 clients.
Conditions required:
  • Established HTTP/2 session (post-TLS ALPN negotiation)
  • Knowledge of the specific request pattern (currently undisclosed by F5)
Where this breaks in practice:
  • No public PoC as of the disclosure date
  • Some fronting CDNs (Cloudflare, Akamai) will normalize HTTP/2 before it reaches the BIG-IP
Detection/coverage: AFM/ASM anomaly detection on HTTP/2 frame rates is inconsistent; most WAF signatures don't cover novel resource-exhaustion patterns.
STEP 03

Memory pressure builds inside TMM

Because there is no upper bound on the allocation, sustained or amplified requests grow TMM's resident set. On multi-tenant chassis and vCMP guests, sibling tenants share TMM memory pools and see cascading pressure. tmsh show sys memory and tmctl -d blade tmm/procstat reflect the climb.
Conditions required:
  • Sustained request rate
  • TMM under normal traffic load already consuming baseline memory
Where this breaks in practice:
  • Very large hardware appliances (i15000, VELOS) have more memory headroom
  • Rate-limiting virtual server profiles reduce request throughput
Detection/coverage: SNMP sysStatMemoryUsed trending, iHealth QKView analytics, and Prometheus BIG-IP exporter all surface the climb — if you're actually watching them.
STEP 04

TMM restart or hang — data plane outage

TMM either self-restarts under memory pressure or becomes unresponsive. On standalone units, this is a full data-plane outage for every VIP on the box. On HA pairs, it typically triggers a failover; then the attacker repeats against the peer, causing flapping. All existing client connections drop.
Conditions required:
  • Attacker maintains request pressure through failover events
Where this breaks in practice:
  • HA pair with active/standby buys minutes, not immunity
  • Chassis-level redundancy (vCMP + multiple blades) is more resilient
Detection/coverage: TMM core dumps, /var/log/ltm restart messages, and monitor-driven pool member marked-down events all fire — post-outage.
03 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone observed as of 2026-07-20. F5 credits *Okta Red Team* with coordinated disclosure — private discovery, no honeypot hits.
Public PoCNo public PoC at disclosure. Related HTTP/2 DoS families (Rapid Reset CVE-2023-44487, MadeYouReset, CERT VU#885548) offer templates; expect reproduction within weeks.
EPSS0.328% (relatively low percentile). Reflects lack of public exploit code, not lack of exposure.
CISA KEVNot listed as of 2026-07-20.
CVSS 3.1CVSS: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 versionsBIG-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 versions17.1.3.4, 17.5.1.8, 21.0.0.3, 21.1.0.1; Next K8s 2.2.3 / 2.3.2.
Exposure populationShodan 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*.
Disclosure2026-07-15 in F5 Quarterly Security Notification (K000159076); article K000162231.
ReporterOkta Red Team, per F5 acknowledgements.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.2/10)

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.

HIGH vendor advisory accuracy and affected version ranges
MEDIUM time-to-weaponization (no public PoC yet, but HTTP/2 DoS primitives are well understood)
HIGH blast radius bounded to availability

Why this verdict

  • Unauthenticated + network-reachable: vector AV:N/PR:N/UI:N with 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:H means 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.

05 · Compensating Control

What to do — in priority order.

  1. Disable HTTP/2 on non-essential virtual servers — Detach the http2 profile 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.
  2. 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.
  3. Apply strict connection and request-rate limits — Use BIG-IP AFM/LTM Rate Limiting profiles and connection profiles capping concurrent HTTP/2 streams per client IP. This slows exhaustion and buys detection time. Deploy within 30 days.
  4. Alert aggressively on TMM memory and restart events — SNMP sysStatMemoryUsed + /var/log/ltm TMM 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.
  5. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: pull an inventory of every BIG-IP VIP with an HTTP/2 profile attached (the verification script does this in one pass) and rank them by internet exposure and business criticality. For any internet-facing VIP, detach HTTP/2 or front with an upstream CDN within 3 days if you're KEV-obsessive, otherwise within the 30-day noisgate mitigation SLA for HIGH. Schedule the actual TMOS upgrade to 17.1.3.4 / 17.5.1.8 / 21.0.0.3 / 21.1.0.1 through your standard change window inside the 180-day noisgate remediation SLA — sooner if a public PoC drops, at which point EPSS will climb and you should collapse the timeline to weeks. There's no data-loss urgency here, but a coordinated DoS against your perimeter load balancer *is* a revenue event.

Sources

  1. NVD — CVE-2026-59762
  2. F5 K000162231 — BIG-IP HTTP/2 vulnerability CVE-2026-59762
  3. F5 K000159076 — Quarterly Security Notification (July 2026)
  4. CERT/CC VU#885548 — HTTP/2 stalled flow-control DoS
  5. CSA Singapore — Multiple Vulnerabilities in F5 NGINX, BIG-IP and BIG-IQ
  6. F5 DevCentral — HTTP/2 bomb attack analysis
  7. ThreatINT — CVE-2026-59762
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.