F5 Breach: BIG-IP Source Code Stolen — What It Means for the Wider Internet
Overview
F5, the company behind the widely used BIG-IP load balancer and the owner of NGINX, has confirmed a major security breach that led to the theft of portions of its BIG-IP source code. The incident also involved the loss of internal vulnerability data — information about security flaws that had not yet been disclosed or patched.
While F5 states that its NGINX and Distributed Cloud product lines were not affected, this breach underscores the growing risks within the global software supply chain, especially when core network infrastructure providers are targeted.
What Happened
- Portions of the BIG-IP source code were exfiltrated.
- Attackers accessed internal engineering systems containing details about unpatched vulnerabilities.
- A limited amount of customer configuration data was also stolen.
- There is currently no evidence that F5’s build pipelines or public product releases were tampered with.
F5 attributes the breach to a “highly sophisticated nation-state threat actor.” External analysts were engaged to validate containment efforts.
Why This Matters
- Accelerated exploit development: Stolen code and vulnerability notes can speed up zero-day discovery and weaponization.
- Targeted attacks: Any stolen configuration data may enable highly tailored exploitation attempts.
- Supply-chain concerns: Even without build-system tampering, the scale of access raises long-term risk questions.
- Ripple effects: Managed service providers and downstream users may face indirect exposure.
Relationship Between F5 and NGINX
F5 acquired NGINX, Inc. in 2019 and integrates the company’s technology into its portfolio. Open-source NGINX remains publicly available and community-maintained, while NGINX Plus is the commercial edition. As of this writing, there is no evidence that either the open-source or commercial NGINX code was compromised; organizations using NGINX Plus should still monitor for advisories.
Recent CVEs to Watch
Five notable issues disclosed on 15 Oct 2025. Each CVE links to BaseFortify’s annotated report.
| CVE | Product / Area | Impact (1-liner) | CVSS |
|---|---|---|---|
| CVE-2025-60016 | BIG-IP (TMM / SSL Brainpool DH) | Crafted SSL traffic can crash TMM when ECC Brainpool DH curves are used. | 8.7 |
| CVE-2025-59481 | iControl REST / tmsh |
Authenticated admin may execute higher-privileged system commands (boundary crossing). | 8.5 |
| CVE-2025-54755 | TMUI (Config Utility) | Directory traversal lets an authenticated user access unintended files. | 6.9 |
| CVE-2025-61958 | BIG-IP / iHealth command (Appliance mode) | Authenticated admin can bypass tmsh restrictions and drop to bash (priv-esc). |
8.5 |
| CVE-2025-58120 | BIG-IP Next (HTTP/2 Ingress) | Undisclosed HTTP/2 traffic can terminate TMM (DoS). | 8.7 |
What Organizations Should Do Now
Quick, copy-paste checks to identify exposure and versions, then harden quickly.
1) Identify if you’re fronted by BIG-IP (from any Linux/macOS host)
# Look for F5/BIG-IP clues in headers or cookies
curl -skI https://your-site.example | grep -Ei 'big.?ip|f5|x-f5|bigipserver'
# Check page body for F5 strings (can reveal WAF or ASM)
curl -sk https://your-site.example | grep -Ei 'F5|BIG-?IP' | head
2) If you administer BIG-IP, get the exact version on-box (SSH to the device)
# Show running software version and build
tmsh show sys version
# List installed images and which is active
tmsh list sys software status
# List licensed/provisioned modules (helps map which advisories apply)
tmsh show sys provision
3) Ensure the management/TMUI is not internet-exposed (run this from outside)
# Common BIG-IP mgmt/TMUI ports to check: 443 (TMUI), 22 (SSH), sometimes 8443
nmap -Pn -p 22,443,8443 <PUBLIC_IP_CANDIDATE>
# If 443 responds and looks like TMUI, treat as critical exposure.
# Quick tell (not foolproof): server title mentioning "Configuration Utility"
curl -sk https://<PUBLIC_IP_CANDIDATE>/tmui/login.jsp | head -n 20
4) Inventory NGINX (open-source or Plus) versions on Linux servers
# Direct binary check
nginx -v 2>&1
# Show build details (modules, OpenSSL, etc.)
nginx -V 2>&1
# Package inventory
# Debian/Ubuntu:
dpkg -l | grep -E '^ii\s+nginx'
# RHEL/Rocky/Alma:
rpm -q nginx
# Docker/Kubernetes:
docker ps --format '{{.Names}}\t{{.Image}}' | grep -i nginx || true
# Check container’s nginx version:
docker exec <nginx-container-name> nginx -v 2>&1
5) Compare to repo “candidate latest” (quick sanity check)
# Debian/Ubuntu:
sudo apt update && apt policy nginx | sed -n '1,10p'
# RHEL/Rocky/Alma:
yum info nginx | sed -n '1,20p' # or: dnf info nginx
6) Harden quickly
- Disable public management access (use a VPN/jump host).
- Rotate admin creds/API tokens tied to BIG-IP and automation.
- Apply the newest vendor fixes (BIG-IP software/firmware; NGINX Plus where applicable).
- Turn on extra logging and watch for anomalous traffic to/from BIG-IP devices.
BaseFortify tip: Add your device/software inventory to BaseFortify so we can flag new CVEs tied to F5/NGINX as they publish.
A Broader Lesson
This breach is another reminder that security at the infrastructure layer — even among trusted global vendors — is not guaranteed. Nation-state groups increasingly target the software supply chain to gain access to the networks of others downstream.
If you’d like proactive alerts mapped to your real environment, you can register for BaseFortify (free) at https://basefortify.eu/register. For SMBs, relying on automated monitoring and vulnerability intelligence platforms such as BaseFortify.eu can help detect early warnings before attackers exploit such events.
Sources
- F5 Security Advisory – October 2025
- CSO Online: Source code and vulnerability info stolen from F5 Networks
- SecurityWeek: F5 blames nation-state hackers for theft of source code and vulnerability data
- Tenable Blog: FAQ on the August 2025 F5 security incident