F5 Breach: BIG-IP Source Code Stolen — What It Means for the Wider Internet

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

 

  1. Accelerated exploit development: Stolen code and vulnerability notes can speed up zero-day discovery and weaponization.
  2. Targeted attacks: Any stolen configuration data may enable highly tailored exploitation attempts.
  3. Supply-chain concerns: Even without build-system tampering, the scale of access raises long-term risk questions.
  4. 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