Appliance mode is not a mitigation when the bug is in the data plane

F5 published the CVE record for CVE-2026-94127 on September 22 at 14:17 UTC — unauthenticated remote code execution in BIG-IP APM, CVSS 3.1 9.8 and CVSS 4.0 9.3, found internally by F5. CISA added it to the Known Exploited Vulnerabilities catalog the same day, with a due date of September 25 and the forensic-triage flag set. CERT-EU issued its own advisory on the 22nd as well.

Two sentences in F5's own record decide what this week looks like. The first narrows who is affected: the flaw "is only present when BIG-IP APM is configured as an OAuth Authorization Server," and deployments "using APM strictly as an OAuth Client / Resource Server (without OAuth authorization server profiles configured) are not affected." The second forecloses the fallback: "The BIG-IP system in Appliance mode is also vulnerable. This is a data plane issue; there is no control plane exposure."

Both reflexes are control-plane answers

When a 9.8 lands on an appliance and there is no maintenance window this week, two things get reached for: the hardened configuration, and locking the management interface down to a jump host. Both change who can administer the box. F5's sentence says the exposure is not on the administrative path at all. The malicious traffic arrives at the virtual server, on the same listener that serves the application, so it is reachable by anyone the service is reachable by. Appliance mode does not narrow that by one packet, and F5 says so rather than leaving you to work it out after the change request is written.

A mitigation does exist, and it is shaped like the bug. The workarounds field of the CVE record says an iRule is available on request by opening a ticket with F5 support — a data-plane control for a data-plane defect. CISA's KEV notes put the two steps in order: apply the vendor-provided iRule "to allow for proactive forensic triage," then "install the final vendor patch as soon as possible." If your KEV tracking ingests the CVE ID and the due date but not the requiredAction text, September 25 reads as a patch deadline when what the field actually demands is mitigate, triage, then patch.

Classify the virtual server, not the version

The exposure question here is a configuration question, and version inventory cannot answer it. A box running 17.1.3 with APM validating tokens as a resource server is out of scope; the identical build issuing tokens as an authorization server is in scope. The check is per virtual server: does it have an access policy with an OAuth profile bound, and is that profile an authorization server profile rather than a client or resource server one.

Whether the precondition reached you at all depends on when your feed read the record. F5's CNA container carries a dateUpdated of September 23 at 00:45 UTC, roughly ten hours after publication. CISA's KEV entry, dated the 22nd, still describes the condition as an access policy and an OAuth profile on a virtual server, with no mention of the authorization-server role, and CERT-EU's advisory from the same day describes it the same broader way. If you triaged this on the 22nd, the sentence that most likely takes you out of scope is not in the copy you read.

The fix carries the second problem. For all three affected branches the fixed artifact is an engineering hotfix, not a release: Hotfix-BIGIP-21.1.0.2.0.30.22-ENG, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG, Hotfix-BIGIP-17.1.3.5.0.41.14-ENG. A version comparison cannot order those strings against 17.1.3, so an inventory that decides compliance by comparing numbers will keep reporting a remediated box as vulnerable. The fix has to be recorded as a fact about the host, by hand, in whatever system the next person will actually look at.

That same arithmetic bites the other way. CVE-2025-53521, the APM RCE CISA added to KEV in March, was fixed at 17.1.3 and 17.5.1.3 — and both sit inside the September record's affected ranges. Doing March's work correctly does not carry you out of September's, which is the same trap as a patched version reappearing as an affected one.

The cost is a few hours walking every virtual server to classify its OAuth role, plus a support ticket and a change on a device in the traffic path for the iRule. The expensive version is skipping the walk, patching every APM box under a three-day clock, and still not knowing which ones were ever exposed.

What to check this week

• Enumerate virtual servers with an OAuth profile bound and label each one authorization server or client/resource server. That label, not the build number, is your exposure list — the same discipline a NetScaler precondition clause demands.
• Before patching, run a compromise assessment. CERT-EU, citing F5's advisory, points at repeated failed UserInfo requests in /var/log/apm with error description "The access token is invalid" — especially ten or more from one IP in a short window — followed by suspicious commands in /var/log/audit and a TMM SIGABRT shortly after.
• Check the OAuth failure counter for an unexplained rise in total_failed:

tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed

• Record the installed hotfix build string as its own inventory field. Your scanner will not read it and the ticket is the only place the next person will find it.
• If you remediated CVE-2025-53521 in March by moving to 17.1.3 or 17.5.1.3, treat those hosts as in scope, not as done.

North InfoSec runs AI-assisted penetration testing and security assessments, including configuration review of internet-facing access appliances. northinfosec.com