CVE-2025-54805 Overview
CVE-2025-54805 is a memory leak vulnerability [CWE-401] affecting F5 BIG-IP Next products. When an iRule is configured on a virtual server through the declarative API, re-instantiation triggers a flawed cleanup process. This cleanup fails to release memory correctly, causing Traffic Management Microkernel (TMM) memory utilization to grow over time. Sustained exploitation can exhaust TMM resources and degrade traffic processing availability.
The issue affects F5 BIG-IP Next Cloud-Native Network Functions, BIG-IP Next for Kubernetes, and BIG-IP Next Service Proxy for Kubernetes. Software versions past End of Technical Support (EoTS) were not evaluated by the vendor.
Critical Impact
Repeated iRule re-instantiation via the declarative API drives TMM memory growth, potentially causing denial of service on load-balanced traffic paths.
Affected Products
- F5 BIG-IP Next Cloud-Native Network Functions
- F5 BIG-IP Next for Kubernetes 2.0.0
- F5 BIG-IP Next Service Proxy for Kubernetes
Discovery Timeline
- 2025-10-15 - CVE-2025-54805 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-54805
Vulnerability Analysis
The vulnerability resides in the cleanup path executed when an iRule is re-instantiated on a virtual server. F5 BIG-IP Next exposes a declarative API for configuration, which allows administrators to define virtual servers and their iRule bindings. When configuration changes trigger re-instantiation, the TMM does not fully release memory allocated for the previous iRule state.
Each re-instantiation cycle leaks memory that accumulates within the TMM process. Because TMM handles all L4-L7 traffic forwarding, sustained growth pressures the data plane. In containerized deployments like BIG-IP Next for Kubernetes, this can trigger pod restarts or degrade tenant traffic handling.
The attack requires authenticated access with low privileges and depends on the presence of iRule-enabled virtual servers configured via the declarative API. Confidentiality and integrity are not impacted; availability of the TMM is the primary concern.
Root Cause
The root cause is a missing release of allocated resources after their effective lifetime [CWE-401]. The cleanup routine invoked during iRule re-instantiation fails to free all TMM-side allocations associated with the prior iRule instance.
Attack Vector
An authenticated user with permission to modify declarative API configuration can repeatedly trigger iRule re-instantiation on a virtual server. Each cycle contributes to TMM memory growth, ultimately leading to resource exhaustion.
No verified public exploit or proof-of-concept is available. See the F5 Technical Article K000151596 for vendor-supplied technical details.
Detection Methods for CVE-2025-54805
Indicators of Compromise
- Steady, unexplained growth in TMM process memory utilization on BIG-IP Next data plane pods or instances.
- Repeated declarative API POST or PATCH operations targeting virtual server iRule configurations from the same principal.
- TMM pod restarts or OOM-kill events in Kubernetes environments hosting BIG-IP Next workloads.
Detection Strategies
- Baseline TMM memory consumption per virtual server and alert on sustained upward trends that do not correlate with traffic volume.
- Correlate declarative API configuration change events with subsequent TMM memory delta measurements.
- Track iRule re-instantiation frequency per virtual server; flag anomalies exceeding operational norms.
Monitoring Recommendations
- Ingest F5 BIG-IP Next control-plane and TMM telemetry into a centralized analytics pipeline for longitudinal review.
- Enable Kubernetes resource metrics (memory working set, RSS) for BIG-IP Next pods and alert on threshold breaches.
- Audit declarative API usage and restrict write access to a limited set of automation identities.
How to Mitigate CVE-2025-54805
Immediate Actions Required
- Review F5 Technical Article K000151596 and identify affected BIG-IP Next deployments in your environment.
- Restrict declarative API write permissions to trusted automation accounts to reduce exposure to abusive re-instantiation.
- Schedule proactive restarts or failovers of TMM instances showing abnormal memory growth until patched.
Patch Information
Refer to the F5 Technical Article K000151596 for fixed version information and upgrade guidance. Versions past End of Technical Support were not evaluated and should be upgraded to a supported release before applying fixes.
Workarounds
- Minimize the frequency of iRule re-instantiation via declarative API by consolidating configuration changes.
- Enforce role-based access control on the declarative API so only required identities can modify virtual server iRule bindings.
- Implement TMM memory monitoring with automated remediation workflows to restart affected instances before exhaustion.
# Example: audit F5 BIG-IP Next declarative API changes affecting iRules
# Query recent configuration events and filter iRule-related mutations
kubectl logs -n f5-bigip-next deploy/controller \
| grep -E 'declarative|iRule|virtualServer' \
| tail -n 200
# Example: monitor TMM pod memory utilization
kubectl top pod -n f5-bigip-next -l app=tmm --sort-by=memory
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.