F5 BIG-IP APM CVE-2026-94127: Code Execution on the Box That Issues Your Access Tokens

Most critical vulnerabilities put an attacker next to your secrets. This one puts them inside the machine that manufactures them. F5's advisory for CVE-2026-94127 describes unauthenticated remote code execution on BIG-IP Access Policy Manager — but only when APM is configured as an OAuth authorization server, the role in which it issues access tokens to your applications. F5 says the flaw has been exploited. CISA added it to the Known Exploited Vulnerabilities catalog on 22 September, the same day the advisory appeared.

The hotfix is a change window. The harder question arrives after it: if someone could run code on the component that signs and issues tokens, which of the tokens it issued are still worth trusting?

What F5 confirms

F5's advisory K000162605 states that when a BIG-IP APM access policy and an OAuth profile are configured on a virtual server, specific malicious traffic can lead to remote code execution, and that the vulnerability “is only present when BIG-IP APM is configured as an OAuth Authorization Server.” Deployments using APM strictly as an OAuth client or resource server, without authorization server profiles configured, are not affected. F5 is explicit about the exploitation status: “We have learned that this vulnerability has been exploited.”

The impact section is equally specific. An unauthenticated attacker can achieve remote code execution; systems in Appliance mode are also vulnerable; and F5 characterises it as a data plane issue with no control plane exposure. The underlying defect is classified as CWE-122, a heap-based buffer overflow, tracked internally as F5 ID 2524777. F5 rates it Critical at 9.8 (CVSS v3.1) and 9.3 (CVSS v4.0), and says the issue was discovered internally.

Affected versions are BIG-IP 21.1.0, 17.5.0–17.5.1 and 17.1.0–17.1.3. The fixes ship as engineering hotfixes — Hotfix-BIGIP-21.1.0.2.0.30.22-ENG, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG and Hotfix-BIGIP-17.1.3.5.0.41.14-ENG. F5 lists every other product it evaluated, including BIG-IP Next, BIG-IQ, F5OS, NGINX, Distributed Cloud and AI Gateway, as not vulnerable. Confirm your own branch against the advisory rather than against a summary such as this one.

On the government side, CISA's 22 September alert lists the CVE as “F5 BIG-IP APM Heap-based Buffer Overflow Vulnerability” alongside three others, under Binding Operational Directive 26-04. Reporting describes the federal remediation deadline as three days — unusually short even for a KEV entry. Romania's DNSC published its own alert on 23 September.

What is not known

There is no published attribution: no actor, no campaign, no named victim. F5 has not said when exploitation began or how widely it has been observed, and “has been exploited” is not the same statement as mass exploitation. There is no public count of how many organisations run APM in the specific authorization-server configuration that is vulnerable. None of these gaps should end up in an incident report as an assumption.

One more absence is worth naming directly, because it shapes everything below. F5's advisory covers patching, the iRule mitigation and indicators of compromise. It says nothing about rotating tokens, signing material or credentials afterwards. The rotation guidance in this article is our recommendation, not F5's.

Look before you reboot

F5 publishes indicators for this specific issue and is careful about how to read them: three signals observed close together are a reason to investigate, and presence alone does not confirm a problem. The pattern F5 describes is multiple OAuth authentication failures, followed by suspicious commands, shortly followed by a TMM SIGABRT.

Repeated OAuth UserInfo failures in /var/log/apm. F5 calls this a medium-confidence indicator and says the signal is repetition, not presence — roughly ten or more in one log, especially all from a single IP address.
An unexplained increase in the failure counter. F5 points at tmctl global_oauth_stat and the total_failed statistic.
Audit-log activity around those timestamps. If the OAuth failures cluster, note the times and go read /var/log/audit for that window.
TMM core files. F5 says it has observed TMM entering a loop, causing the SOD daemon to send a SIGABRT. A core file alone is not an indicator, but it deserves investigation.

The practical consequence: collect this evidence before the maintenance window reboots the box and rolls the logs. A patch applied on top of an uninvestigated compromise closes the door and leaves whoever came through it on the inside.

If you cannot patch immediately, F5 offers an iRule to apply to the affected virtual server. It is not a self-service download — you obtain it by contacting F5 Support, which is worth knowing before you plan around it.

Why an authorization server is a different kind of loss

An OAuth authorization server is not a proxy that forwards credentials. It is the party whose signature other systems accept as proof that a user is who they claim to be. Code execution there reaches, or plausibly reaches, a set of material that is unusually load-bearing:

Token signing keys. Whatever the authorization server uses to sign issued tokens is the highest-value item on the box, because it does not just unlock one thing — it forges the proof that unlocks everything downstream.
Client secrets for every registered application that authenticates to the authorization server.
Live access and refresh tokens in flight or cached, plus the session state behind them. A refresh token outlives the password reset that was supposed to end the problem.
Directory bind accounts and connector credentials APM uses to reach Active Directory, LDAP or an upstream identity provider.
Administrative and API credentials on the appliance, and integration secrets to adjacent systems.
The access policy itself. Not a secret, but an attacker who can edit who is authorised does not need to steal anything.

This is why “we patched” is an incomplete answer. A password rotation does not invalidate an already-issued token, and a token signed with a key an attacker may hold does not stop being valid because the software version changed.

A response order that does not lock you out

Establish whether you are in scope at all. Look for virtual servers carrying both an APM access policy and an OAuth authorization server profile. If APM is only a client or resource server, F5 says you are not affected — and that is a much shorter day.
Preserve evidence, then patch. Capture the APM and audit logs, the OAuth failure statistics and any TMM core files first. Then apply the engineering hotfix for your branch, or the iRule from F5 Support if the hotfix has to wait.
Assume the signing material is in scope until evidence says otherwise. Rotating token signing keys forces reissue across every relying application, so it needs a plan rather than a reflex — but the decision belongs to the first day, not the third week.
Revoke sessions before you rotate secrets. Invalidate outstanding access and refresh tokens, then issue new client secrets. In the other order you hand a fresh secret to a system an old token still has a foothold in.
Rotate the cheap things immediately. Appliance administrator accounts, API credentials and directory bind accounts change quickly and cost little. Do them while the signing-key plan is being written.
Restore the management boundary. Restrict who can reach management interfaces to your administration network, so you are not rotating secrets into a system a stranger can still reach.
Write down what you did not verify. If you cannot establish that exploitation did not occur, record that as an open question rather than resolving it optimistically in the postmortem.

The handover problem this creates

Here is the part that catches teams out. The replacement client secrets have to reach the application owners who will configure them — possibly a dozen teams, possibly across time zones, during an incident. And the single sign-on path those people would normally use to authenticate into your chat, your ticketing system and your secret manager may be the very thing under suspicion.

Decide that path before you need it. Keep the channel that carries the value separate from the channel that carries the notification. Keep new secrets out of the incident ticket, where they will be read by everyone who joins the bridge and everyone who reads the postmortem three months later. For the values that unlock everything else — the break-glass administrator credential, certificate or signing-key recovery material — require more than one person to reconstruct them, so one compromised mailbox is not a second incident.

And keep a route that does not depend on the identity layer. If your own SSO is the component in question, a recovery procedure that assumes working SSO is not a recovery procedure.

Where Secretus fits — and where it does not

Secretus is useful for one narrow human step: an authorised person delivering a small, temporary value — a replacement client secret for one application, a break-glass credential, an enrolment code — over a one-time channel that does not retain it the way chat and ticketing do. Team Split can require several holders to reconstruct a high-value text secret such as a break-glass password.

It is not an identity provider, not a token service, and not a configuration management tool. It cannot revoke a session, reissue a signing key, push a secret into your application fleet, or tell you whether CVE-2026-94127 was exploited against you. Patch, preserve evidence, investigate, revoke, rotate — and use a one-time channel only for getting a value to the engineer who has to type it.