F5 BIG-IP and BIG-IP Next HTTP/2 memory growth can cause denial of service

When an HTTP/2 profile is configured on a virtual server, undisclosed requests can cause an increase in memory resource utilization.

Impact: System performance can degrade until the TMM process is either forced to restart or is manually restarted. This vulnerability allows a remote, unauthenticated attacker to cause a degradation of service that can lead to a denial-of-service (DoS) on the BIG-IP system. There is no control plane exposure; this is a data plane issue only.

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

The record marks the following deployments as affected with default_status set to unknown:

• F5 BIG-IP, module All Modules: 21.1.0 with lessThan: 21.1.0.1; 21.0.0 with lessThan: 21.0.0.3; 17.5.0 with lessThan: 17.5.1.8; 17.1.0 with lessThan: 17.1.3.4.
• F5 BIG-IP Next for Kubernetes, component TMM: 2.3.0 with lessThan: 2.3.2; 2.0.0 with lessThan: 2.2.3.
• F5 BIG-IP Next SPK, component TMM: 1.9.0 with lessThan: *; 1.7.0 with lessThan: 1.7.18.
• F5 BIG-IP Next CNF, component TMM: 2.3.0 with lessThan: 2.3.2; 2.0.0 with lessThan: 2.2.3; 1.1.0 with lessThan: 1.4.3.

Software that has reached End of Technical Support, or EoTS, was not evaluated. The status of EoTS branches is therefore not established by this record.

F5 BIG-IP, BIG-IP Next for Kubernetes, BIG-IP Next SPK, and BIG-IP Next CNF contain a resource-management flaw when a virtual server is configured with an HTTP/2 profile. Undisclosed requests can increase memory resource utilization. This is classified as CWE-770, where resources may be allocated without adequate limits or throttling.

• The request must reach a service using a virtual server with an HTTP/2 profile.
• For BIG-IP, the affected scope is recorded as All Modules; for the BIG-IP Next products, the named component is TMM.
• Increasing memory use can degrade system performance until the TMM process is forced to restart or manually restarted.

The public record does not disclose the request sequence, the memory-allocation path, or the implementation detail that causes the growth. The available description limits the exposure to the data plane and does not identify control-plane exposure.

The vulnerability is remotely reachable over the network by an attacker who does not need authentication or user interaction. The supplied attack properties indicate low attack complexity, but the specific request type required is not disclosed.

The supplied record marks public_exploit as false. The known_exploited field is empty, so the evidence does not establish that exploitation has never occurred. A CISA ADP assessment present in the consulted data records exploitation as none at its recorded assessment time, but that assessment does not replace review of internal telemetry.

• HTTP/2 requests handled by a virtual server with the relevant configuration can increase memory utilization in the data plane.
• The stated technical outcome is degraded system performance until the TMM process is forced to restart or manually restarted.
• An attacker does not need authentication or user interaction; the primary effect is loss of availability that may lead to denial of service on BIG-IP.
• The record does not describe data disclosure, data modification, or control-plane access. The request sequence and the practical limit of memory consumption remain undisclosed.

• Services delivered through virtual servers with HTTP/2 profiles may experience degraded performance or interruption as memory utilization increases.
• The condition may persist until the TMM process is forced to restart or manually restarted, creating operational intervention and traffic-disruption risk.
• The described consequence is an availability failure and possible denial of service on the BIG-IP system; the record does not describe confidentiality or integrity impact.
• The available description states that there is no control-plane exposure, so the supplied evidence does not indicate administrative-plane compromise or management-plane access.

1. Apply the branch-specific BIG-IP updates: move 21.1.0 to 21.1.0.1, 21.0.0 to 21.0.0.3, 17.5.0 to 17.5.1.8, and 17.1.0 to 17.1.3.4.
2. Update BIG-IP Next for Kubernetes: move 2.3.0 to 2.3.2 or move the 2.0.0 branch to 2.2.3, according to the deployed branch.
3. Update BIG-IP Next CNF: move 2.3.0 to 2.3.2, 2.0.0 to 2.2.3, or 1.1.0 to 1.4.3, according to the deployed branch.
4. Update BIG-IP Next SPK: move 1.7.0 to 1.7.18. For the 1.9.0 entry with lessThan: *, the record supplies no specific fixed boundary; obtain F5's corrected-release guidance before treating that branch as remediated.
5. The record states that a patch is available but does not provide a vendor workaround. Do not treat restarting TMM as remediation; it is only a service-recovery action after degradation occurs.
6. After updating, recheck inventory, virtual servers with HTTP/2 profiles, and TMM status on each branch. EoTS versions were not evaluated, so their safety status must not be inferred.

1. Inventory F5 BIG-IP and BIG-IP Next deployments, including the product, release branch, and use of the TMM component.
2. Identify virtual servers configured with an HTTP/2 profile, because this is the condition stated in the vulnerability record.
3. Review memory utilization, performance degradation, and TMM restart or manual-restart activity on systems with the relevant configuration.
4. Compare deployed versions with the affected and remediation boundaries in affected_summary, giving priority to branches whose default status is unknown.

The record provides no IOC, request pattern, log signature, or named event. The absence of matching log evidence does not prove that a system is safe; memory and restart monitoring are precautionary detection measures.