What actually happened
The flaw is tracked as CVE-2026-94127, a heap-based buffer overflow in the BIG-IP Access Policy Manager (APM). F5 rates it 9.8 on CVSS v3.1 and 9.3 on CVSS 4.0.
Exploitation needs no account, no user interaction, and works remotely. An attacker sends specially crafted traffic to an affected virtual server and runs code on the appliance itself.
CISA added it to the Known Exploited Vulnerabilities catalogue, which means one thing: this is not a theoretical risk, it is being used in the wild.
Are you even affected?
The good news is that this does not hit every BIG-IP deployment. It only applies where APM acts as an OAuth authorization server.
Specifically, you are exposed if the same virtual server carries both:
- an APM access policy, and
- an OAuth authorization server profile.
If that combination does not exist in your configuration, this particular flaw does not affect you. The rest of this post is still worth your time.
What to do now
- Patch. F5 has released fixes, and this is the only complete answer.
- If you cannot patch yet, F5 provides an iRule-based workaround to apply to the affected virtual server. Request it through F5 Support.
- Check whether you were already hit. F5 flags a suspicious pattern: repeated failed OAuth authentications and unusual commands, shortly followed by the TMM process crashing with
SIGABRT. - Do not stop at patching. If the appliance was already compromised, an update alone does not evict the attacker.
The lesson is not about F5
It is tempting to file this under vendor-specific bad luck, but the pattern is familiar. A large share of the worst incidents in recent years did not start on the internal network. They started on the very devices you put at the edge to protect it: VPN gateways, load balancers, firewalls, identity proxies.
Those devices make unusually attractive targets for three reasons:
- They are reachable from the internet by design. That is precisely their job.
- They run with high privilege, and often see traffic before it is encrypted again on its way out.
- They get patched rarely, because patching means downtime and because they have been working fine so far.
How to be in a better position next time
You cannot prevent every zero-day. You can decide what is visible from the outside and how fast you react.
- Know what faces the internet. Assessments routinely turn up an admin interface or a long-forgotten test virtual server that nobody meant to publish.
- Set a separate patching deadline for edge devices. For anything on the KEV list, the unit is days, not weeks.
- Track the CISA KEV catalogue, not just CVSS scores. Confirmed exploitation is a stronger signal than theoretical severity.
- Test the perimeter regularly, not once a year.
If you are not sure what is exposed
That is exactly what a penetration test or a vulnerability assessment answers: what is reachable from the internet, what versions are running, and what would happen if somebody actually tried. If you want to know where your perimeter stands, get in touch and we will talk it through.