Cybersecurity News

Cybersecurity News: F5 BIG-IP Zero-Day Exploited

Published September 24, 2026 · DNS Benchmark Pro Editorial · Reading time: 6 minutes

The dominant piece of cybersecurity news this week is a zero-day vulnerability in the box that sits in front of everything else. F5's BIG-IP Access Policy Manager terminates TLS, brokers single sign-on and fronts VPN, web and API estates for a large share of the Fortune 500. A pre-authentication remote code execution flaw there is not an application bug; it is an infrastructure bug, and it lands on the same tier of tech infrastructure that carries DNS-over-HTTPS front ends, load balancers and identity gateways. For most enterprises this is the most consequential server infrastructure advisory of the month.

What F5 disclosed on 22 September

F5 said it discovered the defect through internal research and then found evidence of exploitation in the wild — the sequence that turns a scheduled quarterly advisory into an out-of-band one. The company shipped engineering hotfixes rather than full point releases, published three indicators of compromise, and offered an iRule mitigation through its support portal for operators who cannot take a maintenance window immediately.

Inside CVE-2026-94127: an overflow in the data plane

The flaw is classified CWE-122, a heap-based buffer overflow triggered by improper handling of memory while the system parses specially crafted network traffic. The detail that decides its severity is where that parsing happens: in the Traffic Management Microkernel, the process that moves production traffic, not in the management plane.

That matters because most hardening advice for application delivery controllers is written around the control plane — restrict the admin interface, put it on an out-of-band VLAN, require MFA. None of that helps here. The vulnerable code path is reached by the same traffic the appliance exists to serve, on the same virtual server a browser hits, from any source address permitted to speak to it. The CVSS vector is AV:N/AC:L/PR:N/UI:N: 9.8 under CVSS v3.1, 9.3 under v4.0.

Which deployments are exposed

Unlike most cybersecurity news of this severity, the precondition here is narrow and worth checking before you panic. A virtual server must have an APM access policy and an OAuth profile configured in authorization-server mode. F5 is explicit that deployments using APM only as an OAuth client or resource server are unaffected.

In practice, authorization-server mode is what an organisation turns on when BIG-IP is the identity broker rather than a consumer of someone else's tokens — the typical pattern where APM issues tokens for internal APIs, partner portals and legacy applications that never learned to speak modern SSO. Those are exactly the deployments that see untrusted traffic first. Shadowserver's scan data shows more than 15,000 BIG-IP APM fingerprints reachable from the internet, with roughly 5,000 each in North America and Europe; how many run the vulnerable configuration is not externally observable, which is itself the reason to verify locally rather than infer.

Detection: what a compromise looks like in the logs

F5's published indicators describe a recognisable sequence rather than a single artefact. Defenders should correlate, in order:

• Ten or more OAuth authentication failures from one source IP in a short window, or an unexplained jump in the total_failed OAuth counter.
• Invalid-token entries in /var/log/apm.
• Suspicious commands in /var/log/audit that line up in time with those failures.
• A TMM crash with SIGABRT, or unexpected core files.
• Configuration changes no administrator made.

The TMM abort is the useful pivot. Memory-corruption exploits against a traffic daemon rarely land cleanly on the first attempt, so failed attempts leave crash artefacts before a successful one leaves none. Any BIG-IP that has quietly restarted TMM in the past fortnight deserves a compromise assessment, not just a patch. Treat this as a potential data breach update, not only a patching exercise: an attacker with code execution on an identity broker sits upstream of every session it issues.

Why this matters for DNS security and cloud security

BIG-IP APM is frequently the same tier that terminates encrypted DNS. Where an organisation publishes an internal DNS over HTTPS endpoint, the TLS termination, the access policy and the token check usually live on the appliance, not on the resolver behind it. Code execution there means an attacker can observe or redirect resolution before any DNS security control on the resolver ever sees the query — DNSSEC validation downstream does nothing about a compromised front end.

There is an availability dimension too. A memory-corruption bug that aborts TMM produces the same user-visible symptom as a volumetric DDoS attack — connections dropped, sessions re-authenticating, latency spiking — with none of the traffic volume that makes a DDoS attack obvious on a flow graph. Several incidents that get filed as an unexplained network outage look like this in the first hour.

Patching without wrecking DNS server performance

Hotfixing an appliance pair means failing over, and failing over an OAuth authorization server means every active session re-authenticates against the peer. Sequence that badly across a fleet and a security fix becomes a self-inflicted network outage. The same discipline applies to the resolver tier: reboot too many recursive resolvers at once and cold caches push network latency up for minutes, and DNS server performance degrades long before anything logs an error. Users report that as an outage regardless of what the dashboards say.

Measure rather than guess. A network diagnostic tool that measures real DNS-over-HTTPS resolution latency gives a before-and-after comparison in minutes, and our explainer on DNS over HTTPS covers why encrypted transports shift where the latency actually accumulates. For the wider patch-lag picture, see this week's Linux kernel KEV additions.

The IT security checklist for this week

1. Enumerate virtual servers, not appliances. Find every virtual server carrying both an APM access policy and an OAuth authorization server profile; that intersection is the exposure.
2. Apply the engineering hotfix for your branch, or open a support ticket for the iRule mitigation if the window has to wait.
3. Hunt before you patch. Pull /var/log/apm and /var/log/audit and look for the failure-then-command-then-SIGABRT sequence. Patching first destroys the evidence.
4. Rotate what the box held. Signing keys, client secrets and service credentials on a device with suspected code execution should be treated as disclosed.
5. Restrict reachability. Where an OAuth endpoint serves known partners, an allowlist in front of it shrinks the attack surface today and for the next zero-day vulnerability.
6. Baseline, then failover. Capture resolver and gateway timings before the window so the post-change numbers mean something.

Industry impact

The pattern behind this cybersecurity news cycle is now familiar: the perimeter device is the target, and the server infrastructure behind it inherits the blast radius. VPN concentrators, firewall managers, file transfer appliances and application delivery controllers have supplied a steady run of pre-authentication remote code execution flaws because each one is internet-facing by design, holds credentials by design, and is patched on a slower cadence than the servers behind it. F5 in particular has been under sustained attention since the October 2025 theft of BIG-IP source code by a state-sponsored actor, and researchers recently documented a Linux rootkit built specifically for BIG-IP APM.

For enterprise IT news readers the operational lesson is about placement rather than severity scores. Consolidating TLS termination, identity and encrypted DNS onto one appliance is efficient and, for years, has been the recommended architecture. It also means a single heap overflow in that appliance is simultaneously an authentication bypass, a DNS security problem, a cloud security problem and a potential availability incident. The consolidation is not wrong — but it raises the price of a slow patch cycle, and CVE-2026-94127 is this quarter's invoice.

Sources

• F5 security advisory — BIG-IP APM OAuth vulnerability (CVE-2026-94127)
• CISA Known Exploited Vulnerabilities Catalog
• The Hacker News — F5 Patches Critical BIG-IP APM Zero-Day Exploited for Unauthenticated RCE
• SecurityWeek — Critical F5 BIG-IP Vulnerability Exploited as Zero-Day
• BleepingComputer — F5 patches BIG-IP APM zero-day exploited in RCE attacks
• CSO Online — F5 fixes actively exploited zero-day flaw in BIG-IP APM

Independent editorial analysis published by DNS Benchmark Pro / Genext Information Systems. The CISA seal is a U.S. government work in the public domain; the benchmark screenshots are original captures of the DNS Benchmark Pro engine. No images on this page are AI-generated.