CVE Alert: CVE-2025-58120 – F5 – BIG-IP Next SPK

Risk verdict

High-severity remote DoS risk if HTTP/2 Ingress traffic triggers TMM termination; exploitation not indicated as active at this time.

Why this matters

The vulnerability enables unauthenticated network-borne traffic to disrupt Traffic Management Microkernel, risking service availability across BIG-IP Next SPK/CNF/Kubernetes deployments. For edge and cloud deployments, an attacker could degrade or outage critical traffic management, affecting downstream apps and SLAs.

Most likely attack path

Exploitation would be network-based with no user interaction and no privileges required. A precondition is HTTP/2 Ingress being enabled; once triggered by undisclosed traffic, TMM may terminate, causing service disruption. Lateral movement is unlikely; impact is primarily availability, though repeated failures could leverage cascading outages in multi-tier architectures.

Who is most exposed

Organizations running BIG-IP Next in edge, data-center, or Kubernetes ingress environments with HTTP/2 Ingress enabled are most at risk. Common exposure patterns include public-facing load balancers and Ingress controllers that terminate or proxy HTTP/2 traffic.

Detection ideas

• Unexplained TMM crash/termination logs and core dumps.
• Sudden spikes in 5xx errors or traffic management restarts corresponding to HTTP/2 ingress activity.
• Unusual HTTP/2 traffic patterns or malformed frames directed at the Ingress path.
• Frequent automated restarts of the Traffic Management service.
• Correlated network outages or degraded service during peak load.

Mitigation and prioritisation

• Patch upgrade: apply vendor-released fixes to the affected BIG-IP Next versions; follow vendor guidance for supported releases.
• Configuration: audit and, if feasible, disable HTTP/2 Ingress where not required; enforce strict ingress traffic controls.
• Compensating controls: enable WAF/ratelimiting on ingress, monitor for anomalous traffic surges, and implement network ACLs to limit exposure.
• Change-management: test changes in staging, validate DoS resilience, schedule deployment in maintenance windows, verify TMM stability post-patch.
• Prioritisation note: treat as high-priority for affected deployments, given high availability impact, even if exploitation isn’t currently active (no KEV/EPSS flag).