F5 BIG-IP Zero-Day (CVE-2026-94127): What Happened and What to Do Right Now

On September 22, 2026, F5 disclosed a critical zero-day vulnerability in its BIG-IP Access Policy Manager that attackers were already exploiting in the wild. Tracked as CVE-2026-94127, it carries a near-maximum CVSS score of 9.8 and lets an unauthenticated attacker run arbitrary code on affected systems.

The same day, CISA added it to its Known Exploited Vulnerabilities catalog, and cybersecurity agencies in Europe and Canada issued their own alerts. Researchers counted more than 14,700 internet-facing systems with BIG-IP APM fingerprints. Here is what the flaw is, whether it affects you, and exactly what to do about it.

What is CVE-2026-94127?

CVE-2026-94127 is a heap-based buffer overflow in F5 BIG-IP APM. In plain terms: by sending specially crafted network traffic to a vulnerable system, an attacker can corrupt memory and execute their own code on the appliance, with no username, no password, and no prior access required.

Three things make it especially dangerous:

• No authentication needed. The attacker needs nothing but network access to the right virtual server.
• It is a data-plane flaw, not a management-plane flaw. Malicious traffic reaches the vulnerable service through normal application virtual servers. Locking down the BIG-IP management interface, the usual first line of defense, does not mitigate this one.
• Appliance mode does not protect you. Devices running in F5’s hardened Appliance mode remain fully exposed.

F5 released emergency hotfixes on September 23, one day after disclosure, and confirmed in its advisory that the vulnerability had already been exploited before the patch existed. That is what makes it a true zero-day.

Who is actually affected?

This is the part most coverage glosses over, and it matters: not every BIG-IP deployment is vulnerable.

The flaw only applies when BIG-IP APM is configured as an OAuth authorization server, meaning a virtual server has both an APM access policy and an OAuth profile with an authorization server profile attached. If your organization uses APM strictly as an OAuth client or resource server, you are not in the blast radius.

The affected software branches are:

• BIG-IP 17.1.0 through 17.1.3
• BIG-IP 17.5.0 through 17.5.1
• BIG-IP 21.1.0

Versions that have reached end of technical support were not assessed, which means their status is unknown, not safe.

F5 also evaluated its other product lines and found them not vulnerable, including BIG-IP Next, BIG-IQ Centralized Management, F5 Distributed Cloud, F5OS, NGINX products, and F5 AI Gateway, so teams running those platforms do not need to take emergency action over this advisory.

So who should care? IT teams and managed service providers running BIG-IP APM in enterprise, government, healthcare, and finance environments. If you are a small business owner, you almost certainly do not run BIG-IP yourself, but the services you rely on might. Vendors, payment processors, and SaaS platforms in your supply chain could be affected, which is worth one email to your IT provider asking whether they have patched.

How bad is the real-world exposure?

The Shadowserver Foundation counted more than 14,700 internet-facing IP addresses with BIG-IP APM fingerprints when the advisory landed. That number needs context: it includes patched systems, unpatched systems, honeypots, and deployments that are not configured as OAuth authorization servers. It is a measure of the attack surface, not a count of victims.

What is confirmed is that exploitation was happening before F5 published its advisory. CISA listed it in its Known Exploited Vulnerabilities catalog as F5 BIG-IP APM Heap-based Buffer Overflow Vulnerability and gave US federal civilian agencies just three days, until September 25, 2026, to remediate, one of the shortest KEV deadlines on record. International agencies including CERT-EU, the Canadian Centre for Cyber Security, and NHS England all issued their own alerts.

It is also worth noting the backdrop. About a year ago, sophisticated hackers stole BIG-IP source code and customer data from F5 itself in a separate breach. F5 has not attributed this zero-day to any specific actor.

What to do right now: a checklist

If you administer BIG-IP systems, treat this as an emergency, not a routine patch cycle:

1. Determine whether you are exposed. Inventory every virtual server running APM and check whether any combines an APM access policy with an OAuth authorization server profile. That specific configuration is the vulnerable one.
2. Apply the emergency hotfix immediately. F5 released engineering hotfixes for all three affected branches: Hotfix-BIGIP-17.1.3.5.0.41.14-ENG for 17.1.x, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG for 17.5.x, and Hotfix-BIGIP-21.1.0.2.0.30.22-ENG for 21.1.0, all available from F5 Downloads. Patch the OAuth authorization server configurations first. The full technical details are in F5 security advisory K000162605 at https://my.f5.com/manage/s/article/K000162605.
3. If you cannot patch yet, apply the iRule mitigation. F5 published an iRule-based workaround through its support portal that screens traffic to the vulnerable virtual server. It is a stopgap, not a fix, but it buys time.
4. Hunt for prior compromise. Because exploitation predates the advisory, check logs for the indicator combination F5 published: repeated OAuth authentication failures in /var/log/apm, followed by suspicious commands, shortly followed by a TMM SIGABRT (abnormal termination). F5 notes that sustained repetition, 10 or more failures in one log, especially from a single IP address, warrants human review. Watch for the telltale /var/log/apm entry: Request UserInfo from Source ID (null) IP <IP> failed. Error Code (invalid_token). You can also run tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed and investigate any unexplained increase in total_failed. Review /var/log/apm, /var/log/audit, and tmctl output around the timestamps of any OAuth failure bursts, and investigate any TMM core files.
5. Reduce the configuration footprint. Remove OAuth authorization server profiles from any virtual server that does not genuinely need them.
6. Assume breach if you were exposed. If an internet-facing OAuth authorization server ran unpatched during the exposure window, investigate as an incident, not just a patch job.

If you do not run BIG-IP but depend on vendors who might, the move is simpler: ask them directly whether their BIG-IP APM deployments are patched against CVE-2026-94127. A serious provider will answer immediately.

Frequently asked questions

Is CVE-2026-94127 being actively exploited?

Yes. F5 confirmed exploitation in the wild at the time of disclosure on September 22, 2026, and CISA added it to its Known Exploited Vulnerabilities catalog the same day.

What is the CVSS score?

F5 rated it 9.8 under CVSS v3.1 and 9.3 under CVSS v4.0. Both are in the critical range.

Does restricting the BIG-IP management interface help?

No. This is a data-plane vulnerability reached through application virtual servers, so management-interface restrictions do not mitigate it.

Which BIG-IP versions are affected?

Versions 17.1.0 through 17.1.3, 17.5.0 through 17.5.1, and 21.1.0, but only when APM is configured as an OAuth authorization server. End-of-support versions were not assessed.

I am a small business owner. Do I need to do anything?

You probably do not run BIG-IP, but your vendors might. Ask your IT provider or key vendors whether they have patched CVE-2026-94127. It is also a good reminder to review your own security basics, starting with our guides to free VPNs that actually work and cybersecurity courses for beginners if you want to build real security knowledge in-house.