CVE-2026-94127: F5 BIG-IP APM OAuth Unauthenticated RCE — Detection, Triage, and Remediation Guide

On September 22, 2026, F5 disclosed CVE-2026-94127 — a critical vulnerability in BIG-IP Access Policy Manager (APM) that allows an unauthenticated remote attacker to execute code on the BIG-IP system. F5 has released engineering hotfixes, and given the internet-exposure profile of BIG-IP appliances, this is a drop-everything patch candidate for any organization running APM as an OAuth authorization server.

The scoping detail matters: the flaw only affects systems where APM is provisioned and configured to act as an OAuth authorization server — i.e., the BIG-IP is issuing access tokens to downstream applications. That narrows the blast radius, but don't let that breed complacency. In my experience, most APM deployments that have grown organically over years have OAuth Authorization Server or OAuth Resource Server roles enabled somewhere in the access profile tree, and many administrators don't actually know which role their box is serving until they look. Edge-facing appliances with management and self-IP surfaces exposed have historically been treated as crown-jewel targets by both ransomware affiliates and nation-state actors — an unauthenticated RCE on a token-issuing system is exactly the class of bug that gets weaponized within days of disclosure.

Technical Analysis

Affected Component and Attack Surface

• Product: F5 BIG-IP Access Policy Manager (APM)
• Vulnerability: CVE-2026-94127 — unauthenticated remote code execution
• Affected configuration: APM acting as an OAuth authorization server (issuing access tokens to clients/applications). Systems where APM is not provisioned, or where APM is provisioned but no OAuth authorization server is configured, are not affected.
• Fix availability: Engineering hotfixes released by F5 (see the vendor advisory at MyF5; the summary coverage is available via The Hacker News at https://thehackernews.com/2026/09/f5-patches-critical-big-ip-apm-zero-day.html).

How the Vulnerability Works (Defender's View)

The OAuth authorization server flow on BIG-IP APM exposes HTTP(S) endpoints on the virtual server handling token issuance and authorization requests (commonly paths under /v1/oauth2/ such as /v1/oauth2/token and /v1/oauth2/authorize). The flaw allows an attacker to reach code execution without any valid session, token, or credential — meaning the vulnerable surface is reachable by anyone who can route to the virtual server IP.

From an exploitation-mechanics standpoint, unauthenticated RCE on BIG-IP appliances historically manifests in one of two observable ways:

1. Crafted HTTP requests to the vulnerable endpoint carrying payloads that break out of the request-handling logic — you will often see anomalous request sizes, encoded payloads, shell metacharacters, or template/command-injection markers in URI, query string, or POST body fields logged by APM/LTM request logs.
2. Post-exploitation command execution as a web-serving process context — on BIG-IP this means unexpected child processes spawned by the traffic management or web service daemons (e.g., httpd spawning sh, bash, curl, wget, python, or calls to tmsh), unexpected writes to world-writable or config paths (/tmp, /var/tmp, /shared/tmp, /config), and outbound connections from the appliance to infrastructure that has no business talking to it.

If code execution lands on a token-issuing system, the downstream risk compounds: an attacker with code execution on an OAuth authorization server can potentially mint or steal tokens, impersonate applications and users, and pivot into every relying application that trusts tokens issued by that BIG-IP. Treat any confirmed compromise of this component as a full identity-plane incident, not just an appliance incident.

Exploitation Status

As of disclosure, F5 has released engineering hotfixes and published the advisory; the news summary does not confirm active in-the-wild exploitation or CISA KEV inclusion at time of writing. However, the combination of unauthenticated + RCE + edge appliance + identity component places this firmly in the category that historically moves from disclosure to mass scanning within 24–72 hours, and to exploitation shortly after. Do not wait for a KEV listing to act. Assume reconnaissance scanning of internet-exposed BIG-IP OAuth endpoints is already underway.

Detection & Response

Asset Triage First

Before hunting, enumerate your exposure. You need answers to three questions for every BIG-IP in the estate:

1. Is APM provisioned? (tmsh list sys provision — look for apm)
2. Is APM configured as an OAuth authorization server? (Access ›› Federation ›› OAuth Authorization Server, or via tmsh list apm oauth)
3. Is the affected virtual server internet-reachable (directly or behind a WAF/CDN that passes the request path through)?

Only then move into the behavioral detections below.

Sigma Rules

The following rules target the two observable exploitation patterns: anomalous requests against OAuth authorization-server endpoints, and post-exploitation command execution from BIG-IP web/traffic-management processes (relevant if you ingest BIG-IP audit/syslog output via a Linux auditd pipeline or a host sensor).

---
title: Suspicious Requests to BIG-IP APM OAuth Authorization Server Endpoints
id: 6f2b8c41-9d3e-4a7b-b5c9-2e1f4a6d8c03
status: experimental
description: Detects HTTP requests to BIG-IP APM OAuth token/authorize endpoints containing command injection or traversal markers consistent with exploitation attempts against CVE-2026-94127.
references:
  - https://thehackernews.com/2026/09/f5-patches-critical-big-ip-apm-zero-day.html
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/09/23
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_path:
    cs-uri|contains:
      - '/v1/oauth2/token'
      - '/v1/oauth2/authorize'
      - '/oauth2/token'
      - '/oauth2/authorize'
  selection_payload:
    cs-uri|contains:
      - '%2e%2e'
      - '../'
      - '%24%7b'
      - '${'
      - '%3b'
      - ';id;'
      - '%7c'
      - '|id'
      - 'bash'
      - 'curl '
      - 'wget '
      - '$(id)'
      - '`id`'
    cs-method:
      - 'POST'
      - 'GET'
  condition: selection_path and selection_payload
falsepositives:
  - Legitimate OAuth integrations with unusual parameter encoding (rare)
  - Internal vulnerability scanners (suppress by scanner source IP)
level: high
---
title: BIG-IP Web Service Spawning Command Shell or Utility Process
id: 3c9a1e72-5f48-4b6d-9a2c-7e4d1f8b5a06
status: experimental
description: Detects command shells, download utilities, or scripting interpreters spawned by web/traffic-management daemons on F5 BIG-IP systems, consistent with post-exploitation activity following CVE-2026-94127.
references:
  - https://thehackernews.com/2026/09/f5-patches-critical-big-ip-apm-zero-day.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/09/23
tags:
  - attack.execution
  - attack.t1059.004
  - attack.command_and_control
  - attack.t1105
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/httpd'
      - '/tomcat'
      - '/restjavad'
      - '/mcpd'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/python'
      - '/python3'
      - '/perl'
      - '/nc'
      - '/ncat'
      - '/tmsh'
  condition: selection_parent and selection_child
falsepositives:
  - F5 support-driven troubleshooting invoking tmsh from support sessions
  - Legitimate iCall or monitoring scripts (validate against change records)
level: critical
---
title: Webshell or Payload File Written to BIG-IP Temporary or Web Paths
id: 8b4d2f15-7a6c-4e91-b3d8-5c2a9f6e1b07
status: experimental
description: Detects creation of script or executable files in BIG-IP writable paths commonly abused for post-exploitation payload staging on compromised appliances.
references:
  - https://thehackernews.com/2026/09/f5-patches-critical-big-ip-apm-zero-day.html
  - https://attack.mitre.org/techniques/T1505.003/
author: Security Arsenal
date: 2026/09/23
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|startswith:
      - '/tmp/'
      - '/var/tmp/'
      - '/shared/tmp/'
      - '/config/'
  selection_ext:
    TargetFilename|endswith:
      - '.sh'
      - '.py'
      - '.pl'
      - '.php'
      - '.jsp'
      - '.elf'
  condition: selection_path and selection_ext
falsepositives:
  - Administrative deployment scripts and hotfix staging (correlate with maintenance windows)
  - F5 iHealth or qkview diagnostics output
level: high

Tuning note from the trenches: rule one will fire on vulnerability scanners — that's fine and actually useful (it tells you someone is probing your OAuth surface), but suppress known scanner ranges to keep the alert actionable. Rules two and three should be near-zero-noise in a healthy BIG-IP environment; if they fire, treat them as incident triggers, not tuning exercises.

KQL — Microsoft Sentinel Hunt

BIG-IP systems forward logs via syslog/CEF to Sentinel through the log collector. This query hunts for anomalous request volumes and suspicious payload markers against OAuth endpoints in your proxy/WAF/syslog telemetry, plus outbound connections from BIG-IP device IPs (which should almost never initiate internet-bound connections outside NTP, DNS, licensing, and update endpoints).

let lookback = 7d;
let bigip_devices = dynamic(["10.0.0.0/8"]); // TODO: replace with your BIG-IP self-IP / management subnets
let suspicious_markers = dynamic(["%2e%2e", "../", "${", "%24%7b", "bash", "$(id)", "|id", ";id;", "curl ", "wget "]);
// Stage 1: Suspicious requests hitting OAuth token/authorize endpoints via WAF/proxy/syslog
let suspicious_requests =
    union isfuzzy=true
    ( CommonSecurityLog
      | where TimeGenerated > ago(lookback)
      | where RequestURL has_any (suspicious_markers)
      | where RequestURL has "oauth" and (RequestURL has "token" or RequestURL has "authorize")
      | project TimeGenerated, SourceIP, DestinationIP, RequestURL, RequestMethod, DeviceVendor, DeviceProduct, ReceivedBytes, SentBytes ),
    ( Syslog
      | where TimeGenerated > ago(lookback)
      | where SyslogMessage has "oauth" and (SyslogMessage has "token" or SyslogMessage has "authorize")
      | where SyslogMessage has_any (suspicious_markers)
      | project TimeGenerated, HostIP, Computer, SyslogMessage, SeverityLevel );
suspicious_requests
| extend Stage = "Suspicious OAuth endpoint request"
// Stage 2: Correlate with anomalous outbound connections from BIG-IP device IPs within 30 minutes
| join kind=inner (
    CommonSecurityLog
    | where TimeGenerated > ago(lookback)
    | where ipv4_is_private(DestinationIP) == false
    | where DeviceAction !in ("allow-internal", "")
    | summarize OutboundConns = count(), Destinations = make_set(DestinationIP) by SourceIP, bin(TimeGenerated, 30m)
    | where OutboundConns > 50
) on $left.SourceIP == $right.SourceIP
| project-rename ApplianceIP = SourceIP
| order by TimeGenerated desc

If you don't have the join producing results, run the two halves independently — Stage 1 alone is a valid hunt. A simpler high-signal companion query: alert on any first-seen external destination contacted by your BIG-IP management or self-IP addresses over the past 7 days versus a 90-day baseline. Appliance egress is one of the cleanest behavioral baselines you'll ever build.

Velociraptor VQL

If you have endpoint collection capability on or adjacent to the appliance (or are scoping a suspected-compromised BIG-IP during IR), this artifact enumerates suspect processes and recent file drops in the writable paths attackers favor on BIG-IP.

-- Hunt BIG-IP post-exploitation: suspicious child processes of web daemons
-- and recently created executable/script files in writable paths.
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(bash|/bin/sh|curl|wget|python|perl|nc |ncat|tmsh)'
  AND (
    CommandLine =~ '/tmp/|/var/tmp/|/shared/tmp/'
    OR Exe =~ '/usr/local/www|/var/ts'
  )

-- Enumerate recently created script/executable files in BIG-IP writable paths
SELECT FullPath, Size, Mtime, Ctime, Btime
FROM glob(globs=['/tmp/*.sh', '/tmp/*.py', '/tmp/*.elf',
                 '/var/tmp/*.sh', '/var/tmp/*.py',
                 '/shared/tmp/*.sh', '/shared/tmp/*.py',
                 '/config/*.sh'])
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC

Remediation and Verification Script

This Bash script runs on the BIG-IP advanced shell to determine whether the appliance is in scope, capture forensic state before patching (critical — hotfix installation can overwrite evidence), and prepare for hotfix application. Run it during triage; do not skip the evidence-preservation steps.

#!/bin/bash
# CVE-2026-94127 triage and pre-patch evidence capture for F5 BIG-IP APM
# Run from advanced shell (bash) as root. Review output before any hotfix install.

OUT=/shared/tmp/cve-2026-94127-triage-$(date +%Y%m%d-%H%M%S)
mkdir -p "$OUT"

echo "=== 1. APM provisioning status ==="
tmsh list sys provision 2>/dev/null | grep -i -A2 apm | tee "$OUT/provision.txt"

echo "=== 2. OAuth authorization server configuration (SCOPE CHECK) ==="
# If this returns configured OAuth server objects, the system is IN SCOPE.
tmsh list apm oauth 2>/dev/null | tee "$OUT/oauth-config.txt"
if tmsh list apm oauth 2>/dev/null | grep -qi "oauth-server"; then
  echo "[ALERT] OAuth authorization server configured - system is IN SCOPE for CVE-2026-94127" | tee "$OUT/IN-SCOPE.txt"
else
  echo "[INFO] No OAuth authorization server found - verify no oauth profile is attached to virtual servers"
fi

echo "=== 3. Current software version and hotfix level ==="
tmsh show sys version | tee "$OUT/version.txt"

echo "=== 4. Suspicious processes (shells/downloaders under web daemons) ==="
ps auxf | grep -E "(httpd|restjavad|mcpd)" -A5 | grep -E "(bash|/bin/sh|curl|wget|python|perl|nc)" | grep -v grep | tee "$OUT/suspicious-procs.txt"

echo "=== 5. Recently modified files in writable paths (last 7 days) ==="
find /tmp /var/tmp /shared/tmp /config -type f \( -name "*.sh" -o -name "*.py" -o -name "*.elf" -o -name "*.php" \) -mtime -7 2>/dev/null | tee "$OUT/recent-files.txt"

echo "=== 6. Unexpected administrative accounts and recent logins ==="
tmsh list auth user | grep -E "^(auth user|    shell|    partition-access)" | tee "$OUT/users.txt"
last -30 | tee "$OUT/logins.txt"

echo "=== 7. APM/OAuth access log review (suspicious request markers, last 200k lines) ==="
tail -200000 /var/log/apm 2>/dev/null | grep -E "(\$\{|%2e%2e|\.\./|;id;|\|id|bash|\$\(id\))" | tail -50 | tee "$OUT/apm-suspicious.txt"

echo "=== 8. Unexpected outbound connections ==="
netstat -anp 2>/dev/null | grep ESTABLISHED | grep -v -E "(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)" | tee "$OUT/egress.txt"

echo "=== 9. Integrity: compare against known-good config ==="
tmsh list /sys crypto key 2>/dev/null | head -20 >> "$OUT/keys-present.txt"
csoconf -a 2>/dev/null >> "$OUT/config-dump.txt"

echo "Triage bundle written to $OUT"
echo "NEXT: preserve $OUT off-box (scp to IR share), then apply the F5 engineering hotfix per the MyF5 advisory."

Remediation

1. Determine scope immediately. Per F5, only systems where APM acts as an OAuth authorization server are affected. Run the scope check in the script above (tmsh list apm oauth) across every BIG-IP in the estate — including lab, DR, and cloud (BIG-IP VE) instances. Don't assume; verify.

2. Apply the F5 engineering hotfix. Hotfixes are available from F5 for supported versions. Engage F5 Support via MyF5 to obtain the correct engineering hotfix for your software branch, and reference the official advisory linked from the coverage at https://thehackernews.com/2026/09/f5-patches-critical-big-ip-apm-zero-day.html. Follow F5's standard hotfix installation procedure (tmsh install sys software hotfix ...), verify the active volume post-install, and confirm the OAuth services restart cleanly.

3. Reduce exposure while patching. If hotfix application requires a maintenance window you can't get immediately:

   • Restrict network reachability to the OAuth-facing virtual server using packet filters, AFM, or upstream firewall rules — allowlist only the networks of legitimate relying applications where architecture permits.
   • If the OAuth authorization server role is not actually required (common finding — it was enabled for a project that ended), decommission it: remove the OAuth configuration and the associated access profile from the virtual server. An unconfigured feature cannot be exploited.
   • Place a WAF policy in front of the virtual server blocking requests containing injection markers to /v1/oauth2/* paths as a compensating control — this is mitigation, not a fix.

4. Hunt before and after patching. Patching closes the hole; it does not tell you whether someone walked through it. Run the KQL hunt and the triage script, review /var/log/apm, /var/log/ltm, and audit logs for anomalous requests predating the patch, and preserve evidence off-box before hotfix installation. If any indicator of compromise surfaces, treat it as an identity-plane incident: rotate OAuth client secrets, signing keys, and any tokens the box could have issued.

5. Validate management-plane hygiene while you're in there. Confirm the BIG-IP management interface and self-IPs are not internet-reachable (this remains the single most common F5 compromise amplifier), enforce MFA on administrative access, and confirm syslog/audit forwarding to your SIEM is functioning — you cannot hunt what you cannot see.

6. Track the KEV. Given the severity class, monitor CISA's Known Exploited Vulnerabilities catalog for CVE-2026-94127. If it lands on KEV, federal civilian agencies will receive a Binding Operational Directive deadline, and it should trigger your own emergency-change SLA regardless of sector.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub