F5 Breach: Nation-State Access to BIG-IP Source Code, One Year On

On 15 October 2025, F5 disclosed that a nation-state actor had long-term access to its BIG-IP development environment and stole source code and details of unpatched flaws. Anyone running BIG-IP, BIG-IQ, F5OS or BIG-IP Next should be on a currently supported, fully patched release, with management interfaces off the internet and logs going to a SIEM.

A year on, the story is back in the news after F5's out-of-band NGINX fixes of 19 October 2026. It is a good moment to check that the clean-up held, because the risk F5 and CISA described does not expire on a deadline. This post covers what was accessed, what F5, CISA and the UK NCSC told customers to do, why a vendor breach of this kind raises risk for every customer, and what helps.

A note on dates: some recent summaries describe this as an October 2026 disclosure. F5's SEC filing, F5's security notice and CISA's directive are all dated 15 October 2025. This post uses those primary dates.

What happened

F5's Form 8-K, filed under Item 1.05 for material cybersecurity incidents, says F5 learned on 9 August 2025 that a "highly sophisticated nation-state threat actor" had gained access to certain company systems. The actor had long-term, persistent access to the BIG-IP product development environment and the engineering knowledge management platform, and downloaded files from them.

According to the filing, those files included portions of BIG-IP source code and information about undisclosed BIG-IP vulnerabilities F5 was working on. Some knowledge management files held configuration or implementation information for a small percentage of customers. F5's CISO later wrote that this was mainly internal notes about customer interactions.

The US Department of Justice decided on 12 September 2025 that a delay in public disclosure was warranted, which SEC rules allow on national security grounds. F5 filed on 15 October and published its security notice (K000154696) and its October quarterly security notification (K000156572) the same day. CISA issued Emergency Directive 26-01 that morning, and the UK NCSC published its own alert.

Timeline

What F5 says was and was not accessed

This table covers only what F5 itself stated.

The supply chain line matters most for customers. F5 says no one changed the code that ships to you. The risk is different: someone outside F5 now holds the code and F5's own notes on weaknesses, and can study both at leisure.

Attribution and dwell time: what is reported, not confirmed

F5 has not named a country or group. Several outlets have reported more, all from unnamed sources:

• Country. SecurityWeek, citing Bloomberg, reported that F5 believes China is responsible, though F5 has not said so publicly.
• Dwell time. Bloomberg reported, citing people briefed by F5, that the intruders got in from late 2023 and that F5 told customers they had been inside for at least 12 months. Bloomberg also reported that the first access came through internet-exposed F5 software. F5 declined to comment.
• Tooling. Bloomberg reported use of the BRICKSTORM backdoor. Google's Mandiant has tied BRICKSTORM to a China-nexus espionage cluster it tracks as UNC5221. Palo Alto Networks Unit 42's threat brief on the F5 breach does not name a group.

Treat these as reporting, not findings. For defenders the point is the same: assume a patient actor with time to read the code.

Why a vendor breach of source code and vulnerability data raises risk for every customer

Most breaches put the breached company's data at risk. This one changes the odds for everyone who runs the product, and the reasons are worth spelling out.

The attacker's research time shrinks. Finding a new bug in a closed appliance normally means reverse engineering firmware. With source code, an attacker can read the logic directly and review the parts that handle untrusted input. CISA's directive warns that the stolen material could help the actor find zero-day flaws and build targeted exploits.

The patch gap opens early. A vendor's internal list of flaws it is still fixing is the most valuable list there is. Anyone holding it can work on those flaws before the fix ships. Unit 42 noted that the theft was found in early August 2025 and fixes shipped mid-October, so a window of about two months existed in principle. That is an inference about possibility, not a report of exploitation.

Exposure is large and concentrated. BIG-IP sits at the network edge, often handling TLS, authentication and access policy. Unit 42 reported over 600,000 hosts behind internet-exposed BIG-IP instances, and later revised its wording on exposure; other published counts differ. Either way, one product family at the edge of so many networks is a concentrated target.

Edge devices are hard to watch. You usually cannot run your normal endpoint agent on an appliance, and logs often stay on the box. CISA warned that successful exploitation could expose embedded credentials and API keys and enable lateral movement. F5's own follow-up included a partnership to bring endpoint detection to BIG-IP, which shows how limited appliance visibility usually is.

Customer configuration notes are reconnaissance. Notes on how a specific network is built help an attacker plan, even for a small share of customers. F5's CEO later said the most common feedback from those customers was that "that data is not sensitive."

Old bugs get new value. In late March 2026, F5 reclassified CVE-2025-53521 in BIG-IP APM. It was first published in October 2025 as a denial of service rated CVSS 7.5. After "new information," F5 rated it as remote code execution at 9.8, and CISA added it to the KEV catalog after exploitation was reported. CSO Online reported that systems running the October 2025 fixed releases were already protected. No public source we found links this CVE to the stolen data, and we do not suggest a link. The lesson is narrower: teams that deferred a "moderate" appliance fix in October 2025 carried real risk until March 2026 without knowing it.

For a wider look at why edge appliances keep showing up in incident reports, see our edge device zero-days roundup.

What F5, CISA and the NCSC told customers to do

The three sets of guidance overlap heavily. Here they are side by side.

F5's CISO listed BIG-IP 17.5.1.3, 17.1.3, 16.1.6.1 and 15.1.10.8 as the fixed releases from October 2025. Those are a floor. F5 has published further quarterly notifications since, so check the latest one before choosing a target version.

ED 26-01 binds US federal civilian agencies only, but works as a checklist for anyone. SecurityWeek summarised the deadline as 31 October; the directive sets 22 October for the listed products and 31 October for the rest.

What to do now

If you completed the 2025 work, use this list to confirm it held. If you did not, start at step 1.

1. Find every F5 instance. Include hardware, Virtual Edition in each cloud account, BIG-IQ, F5OS platforms and BIG-IP Next for Kubernetes. Reconcile your CMDB, cloud inventories and network scans; cloud and lab instances are the usual gaps.

2. Record versions. On each BIG-IP, from an admin shell:

   tmsh show sys version
   tmsh show sys software status
   tmsh show sys hardware
   

   Compare the version with the fixed releases in F5's latest quarterly security notification. Any branch past end of software development needs a migration plan, not a hotfix.

3. Check management exposure from outside. From a host outside your network, test whether the management address answers on its admin ports. Use only addresses you own.

   nmap -Pn -p 22,443,8443 <your-mgmt-public-ip>
   curl -sk -o /dev/null -w "%{http_code}\n" https://<your-mgmt-public-ip>/
   

   Then check what the box itself allows:

   tmsh list sys httpd allow
   tmsh list sys sshd allow
   tmsh list net self all-properties | grep -A3 allow-service
   

   An allow list of All or a self IP with broad allow-service settings means the admin interface may be reachable from more places than you think. If it was ever exposed to the internet, both F5 and the NCSC say to run a compromise assessment.

4. Patch, and verify what you install. Download from F5 only, check the published checksums, and remember that F5 rotated its image signing keys in October 2025. F5's notice on the rotation warns that newer releases may not verify some older F5-signed objects, so read it before upgrading older F5OS platforms.

5. Send logs off the box. Configure remote syslog and SIEM streaming, then confirm events arrive:

   tmsh list sys syslog remote-servers
   

   Alert on admin logins, failed authentication, new local users and configuration changes. F5's support articles on remote logging and on auditing logins describe the settings.

6. Review accounts and secrets on the device. List local users and remove any you cannot explain:

   tmsh list auth user
   

   Rotate admin passwords and any credentials or API keys stored in the configuration, such as those for monitors, LDAP binds or external services. CISA's warning that exploitation could expose embedded credentials and API keys is why.

7. Run the hunt. Ask F5 support for the threat hunting guide and indicators through a MyF5 case. Use iHealth's automated hardening checks on a current qkview.

8. Ask F5 whether your configuration data was in scope. F5 said it would contact affected customers directly. If you are unsure whether you heard, ask your account team and record the answer.

9. Put the patch cadence in writing. CISA asks agencies to apply new F5 updates within a week of release. Whatever your number, write it down, assign an owner and track it.

What would have helped

Nothing a customer did could have stopped an intrusion inside F5. What customers control is how much a vendor breach costs them.

Practices any team can use

• An inventory you can trust in an hour. CISA's first required action was a full inventory. Teams with a live inventory of appliances, versions and owners started patching the same day. Teams without one spent the first days searching cloud accounts.
• Management planes off the internet, enforced. Put admin interfaces on a dedicated management network reachable only through a jump host. ED 26-01 even let agencies with jump-box-only management stay on their regular update schedule. Test exposure from outside on a schedule, not once.
• Logs that leave the device. If an appliance is compromised, logs stored on it are the first thing to go. Bloomberg's sources described an actor that waited out log retention, which argues for retaining edge logs longer than a year.
• A patch lane for edge devices. Appliance updates often wait for a maintenance window months away. Agree in advance that vendor emergency guidance or a KEV listing moves an edge update to the front of the line, with a tested rollback.
• Supported versions only, and secrets that rotate easily. End-of-support boxes get no fixes, and credentials kept in a vault make step 6 an afternoon's work.
• Vendor incidents on the risk register. Record the vendor, the incident, what they told you, what you did and when you will check again.
• Your own source code and vulnerability notes treated as crown jewels. If you ship software, restrict access to unfixed vulnerability details, segment engineering systems and watch for bulk downloads from internal wikis. F5's CISO wrote that its controls were "strong in some places and not in others," which is true of most companies.

Where Safeguard fits

Plainly first: Safeguard does not scan F5 appliance firmware, TMOS or F5OS images, or any vendor appliance. It would not have detected this intrusion, found the stolen flaws or patched a BIG-IP. F5's advisories, F5 support and your network team own that work.

Safeguard covers the software you build and ship, which is the other half of the response.

• Know what you run behind the appliance. safeguard scan --dir . scans a repository, safeguard scan --image <name> scans a container image and safeguard scan --sbom <file> analyses an SBOM, with JSON results under ./output. When a component is in the news, the platform shows which projects contain a given component and version. If nginx is installed as a package in your images, it shows up in the image scan, which helps when F5 ships NGINX fixes like those of 19 October 2026.
• Prioritise by exploitation. Findings are matched against vulnerability databases, including CISA KEV and vendor bulletins, and reachability analysis helps separate the findings that matter from the noise.
• Policies and gates. Gates evaluated in the platform can block, warn or require approval when a build carries a known exploited component, so an emergency fix does not wait for someone to notice.
• Fixes with approval. Autonomous remediation can open fix PRs (off by default). The Safeguard CLI's assistant can edit code and run commands with your approval, with /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. safeguard exec runs it in CI. The desktop and phone apps can send work to a computer running the CLI and approve each command.
• Track the vendor. The compliance suite includes Vendors and Risks registers, which is a natural place to record a vendor incident like this one and its follow-up.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. Closed vendor appliance software such as BIG-IP is outside those ecosystems, so it has no bearing on the flaws stolen from F5.

Gold Open Source (gold.safeguard.sh) is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or above, Sigstore-signed, with evidence pages. An artifact loses its badge if it regresses.

Neither replaces an F5 update. The habit they support is the one this incident rewards in your own stack: pull patched, signed components from a curated source and rebuild fast when the advisory lands.

Common mistakes

• Patching only the public-facing boxes. ED 26-01 covered all F5 devices, with a second deadline for the rest. Internal BIG-IPs often hold the most interesting credentials.
• Treating the October 2025 deadline as the end. The stolen code does not expire. CVE-2025-53521 showed a fix from that batch becoming critical five months later.
• Assuming "no supply chain tampering" means no risk. It means the software you received was not altered. It says nothing about flaws an outsider may now find faster.
• Checking exposure from inside the network. A management interface can look locked down from your laptop and still answer from the internet through a forgotten NAT or cloud security group rule.
• Rotating credentials before the hunt. If an attacker is still inside, new passwords can leak too. Hunt and contain, then rotate.
• Upgrading older F5OS without reading the key rotation notice. F5 says some combinations will not install by design.

FAQ

When did F5 disclose the breach?

F5 disclosed it on 15 October 2025 in a Form 8-K and security notice K000154696. It learned of the access on 9 August 2025 and delayed disclosure with the US Justice Department's approval. Summaries dating it to October 2026 are incorrect.

What did the attacker take?

According to F5, files from the BIG-IP development environment and engineering knowledge management platform, including portions of BIG-IP source code, information on undisclosed BIG-IP vulnerabilities, and configuration or implementation information for a small percentage of customers.

Was the software I downloaded from F5 tampered with?

F5 says there is no evidence its source code, build or release pipelines were modified, and that independent reviews by NCC Group and IOActive agreed. F5 also rotated its image signing keys in October 2025, so verify downloads against current checksums and signatures.

Is NGINX affected by the breach?

F5 says it has no evidence that the NGINX source code or development environment was accessed. The NGINX fixes F5 shipped on 19 October 2026 are separate vulnerabilities. Keep NGINX current regardless, as the NCSC advised.

Who was behind it?

F5 says a "highly sophisticated nation-state threat actor" and names no country. Bloomberg and SecurityWeek reported, from unnamed sources, that F5 believes China is responsible, and Bloomberg reported use of the BRICKSTORM backdoor, which Mandiant ties to a cluster it calls UNC5221.

Does CISA's emergency directive apply to my company?

ED 26-01 is binding only on US federal civilian agencies. Its actions (inventory, remove management exposure, patch, retire end-of-support devices, keep patching) are sound for any organisation running F5 products.

Does Safeguard scan F5 appliances?

No. Safeguard does not scan vendor appliance firmware or images. It scans the repositories, container images and SBOMs you own, which is where it helps during a vendor incident like this one.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos show this incident or an F5 appliance. Each shows a real flow for the software you own, which is the work running in parallel while the network team patches BIG-IP.

The first demo is a CLI session that fixes a lodash CVE: it reads the finding and the advisory, asks before each command, edits package.json, runs the install and tests with your approval and pushes nothing. In an F5 week, you would run the same scan against the container images of the applications behind your load balancers, for example to find images with an outdated nginx package, and ask the assistant to bump the base image, approving each command.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. That is how you would scan internal services and images that never leave your network, a common situation for teams whose BIG-IPs front private applications.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: you send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. Emergency directives tend to land outside office hours, and this flow lets an on-call engineer keep the fixes in your own code moving without handing over standing access.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI docs. For the wider pattern across this month's incidents, see October 2026 security incidents and what would have helped, and for how a stolen signing key plays out at a certificate authority, see the eMudhra CA key compromise explained.

Quick check

Sources

• F5, Inc. Form 8-K, filed 15 October 2025 (SEC EDGAR)
• F5 blog: Lessons we are learning from our security incident (22 October 2025)
• CISA Emergency Directive 26-01: Mitigate Vulnerabilities in F5 Devices
• UK NCSC: Confirmed compromise of F5 network
• Palo Alto Networks Unit 42: Nation-State Actor Steals F5 Source Code and Undisclosed Vulnerabilities
• BleepingComputer: Hackers breach F5 to steal undisclosed BIG-IP flaws, source code
• SecurityWeek: F5 hack attack linked to China, BIG-IP flaws patched, governments issue alerts
• Claims Journal (Bloomberg): Hackers had been lurking in cyber firm F5 systems since 2023
• Cybersecurity Dive: F5 expects nation-state hack to curb revenues
• CSO Online: 5-month-old F5 BIG-IP DoS bug becomes critical RCE exploited in the wild
• BleepingComputer: F5 releases out-of-band patches for critical NGINX vulnerabilities (19 October 2026)
• F5 security notice K000154696
• F5 signing certificate and key rotation, October 2025 (K000157005)

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.