F5 BIG-IP APM Under Attack: Check the OAuth Boundary, Patch, and Investigate

A BIG-IP virtual server that handles OAuth traffic is an authentication boundary, but it is also a network-facing software component. On September 22, 2026, F5 disclosed CVE-2026-94127, a heap-based buffer overflow in BIG-IP Access Policy Manager (APM). F5 says attackers are already exploiting it. When an APM access policy and an OAuth profile are configured on the same virtual server, malicious traffic can lead to unauthenticated remote code execution on the appliance. F5 advisory K000162605, Canadian Centre for Cyber Security alert AL26-022

The administrator’s job is to answer three separate questions: Does a running virtual server meet that configuration condition? Is every relevant BIG-IP instance fixed? What happened while it was exposed? A hotfix answers the second question. It cannot answer the third.

Establish Which Virtual Servers Are Exposed

This is a specific APM configuration flaw, not a claim that every BIG-IP installation has the vulnerable request path. The two features must meet on the same virtual server. An OAuth profile elsewhere in the configuration does not by itself establish exposure. Neither does an APM access policy on a different virtual server. Confirm the effective running configuration for each active, standby, and recovery instance, including instances operated for you by a provider. Canadian Centre for Cyber Security

From the BIG-IP Advanced Shell, these read-only commands show installed boot volumes and virtual-server configuration. Run them only on appliances you administer. The first command distinguishes an active volume from one that merely has an update installed. The second can produce a large, sensitive configuration listing: inspect it locally and avoid pasting it into public tickets. F5’s ltm virtual reference documents the virtual server and its attached profiles. F5 tmsh virtual-server reference, F5 software-status example

tmsh show sys software
tmsh list ltm virtual

For each candidate virtual server, identify its access policy, attached OAuth profile, enabled state, destination, and actual network reachability. Configuration templates and inactive boot volumes are useful leads, but the running service determines present exposure. If the profile relationship is unclear in your BIG-IP version or management interface, have the APM owner or F5 Support verify it rather than inferring safety from a text search.

Apply the Fixed Hotfix

The Canadian Cyber Centre lists these vendor-supported engineering hotfixes for the affected branches. Select the hotfix for the appliance’s actual branch and check F5’s current advisory before installation; a package with a similar number on an inactive volume is not proof of remediation. Canadian Centre for Cyber Security alert AL26-022

The BIG-IP owner should take a configuration backup through the normal change process, plan high-availability failover or a maintenance window, and install the applicable F5-supplied fix. After activation, check the active software volume and hotfix on each peer; then test the affected virtual server, OAuth sign-in flow, and application access. Record the before-and-after build evidence. For Common Criteria evaluated configurations, follow F5’s specific change guidance. Canadian Centre for Cyber Security

If the hotfix cannot be installed immediately, open a case with F5 Support for its vendor-provided iRule mitigation and apply it only as instructed for the affected virtual server. Test legitimate OAuth flows after deployment. The publicly cited guidance does not provide that iRule’s contents, so do not substitute an unreviewed rule copied from another incident. Where the business can tolerate it, the service owner can also limit reachability of the affected virtual server while the fix is arranged. Restricting the management interface is sensible hardening, but it does not remove a flaw in a client-facing APM virtual server. F5 advisory K000162605, Canadian Centre for Cyber Security

Investigate the Exposed Period

F5 confirmed exploitation in the wild, and CISA added this CVE to its Known Exploited Vulnerabilities catalog on September 22. Neither fact proves that your appliance was attacked. For an exposed instance, preserve appliance logs, forwarded logs, configuration snapshots, core-file metadata, and upgrade timestamps before routine rotation or a rebuild removes them. Establish when the vulnerable build, APM policy, OAuth profile, and reachability overlapped. Involve the incident-response owner early if evidence may need forensic handling.

F5’s indicators, relayed by CERT-EU, form a sequence to investigate, not a signature that reliably labels every request: repeated OAuth UserInfo failures, suspicious commands in the audit log near the same time, and a TMM abort or core file. CERT-EU specifically calls out 10 or more invalid_token failures from one IP in a short interval as a reason for human review. An OAuth failure alone is common; a TMM core file alone is not proof of exploitation. CERT-EU advisory 2026-013

On a BIG-IP Advanced Shell, the following read-only checks help start that review. Run them against the relevant log files and time window; rotated or externally forwarded logs may hold older records. Do not paste raw logs into an unrestricted chat or ticket because they may contain user or network details.

grep -F 'Error Code (invalid_token)' /var/log/apm
tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed
grep -F 'AUDIT' /var/log/audit

The tmctl command gives counters, not a historical timeline. Compare them with earlier monitoring or a documented baseline if one exists; an unexplained rise in total_failed is a lead. For the log review, group failures by source IP and time, then correlate that interval with /var/log/audit, externally forwarded logs, changes to accounts or access policies, and TMM crash evidence. Investigate the actual commands and their owner; do not call every administrative action malicious. If your logs do not cover the exposed period, document that gap rather than reporting a negative finding. CERT-EU advisory 2026-013, Canadian Centre for Cyber Security

If the sequence or other evidence suggests compromise, move from vulnerability management to incident response: preserve evidence, contain the affected traffic path with the service owner, determine what code or configuration changed, and recover the appliance from a trusted state with F5’s help. Review credentials, tokens, sessions, and connected systems according to the access the investigation actually establishes. Installing a hotfix on a compromised appliance does not remove persistence or establish that its secrets are safe.

Close the Work With Evidence

The appliance owner should be able to hand the incident-response owner four records:

1. An inventory of active, standby, and recovery BIG-IP instances with their running software volume and the virtual servers that pair an APM access policy with an OAuth profile.
2. The applicable fixed hotfix active on each affected instance, plus successful post-change OAuth and application tests. If an F5 iRule was needed temporarily, record where it was applied and when it can be removed.
3. The exposure window and the appliance, forwarded, and audit logs actually reviewed, including suspicious events investigated and any retention gaps.
4. An incident decision: no suspicious activity found in the available evidence, investigation still open, or confirmed compromise with containment and recovery actions. “No IOC found” is not proof that an exposed system was never compromised.

The same week brought separate actively exploited NetScaler flaws. Keep the response records separate: the products, affected configurations, fixes, and available indicators differ.

Sources

• F5: BIG-IP APM vulnerability CVE-2026-94127, K000162605
• Canadian Centre for Cyber Security: Alert AL26-022
• Canadian Centre for Cyber Security: F5 advisory AV26-949
• CERT-EU: Critical Vulnerability in F5 BIG-IP APM
• F5: tmsh virtual-server reference
• F5: software-status example