F5 BIG-IP APM heap-based buffer overflow enables unauthenticated remote code execution

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 (RCE). This vulnerability is only present when BIG-IP APM is configured as an OAuth Authorization Server. Deployments using APM strictly as an OAuth Client / Resource Server (without OAuth authorization server profiles configured) are not affected by this vulnerability. Impact: This vulnerability allows an unauthenticated attacker to perform remote code execution. The BIG-IP system in Appliance mode is also vulnerable. This is a data plane issue; there is no control plane exposure. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

• F5 BIG-IP APM: The affected condition applies to deployments with an APM access policy and an OAuth profile on a virtual server, where APM is configured as an OAuth Authorization Server. Appliance mode is also vulnerable.
• 21.1.0 branch: affected when less than Hotfix-BIGIP-21.1.0.2.0.30.22-ENG.
• 17.5.0 branch: affected when less than Hotfix-BIGIP-17.5.1.9.0.160.12-ENG.
• 17.1.0 branch: affected when less than Hotfix-BIGIP-17.1.3.5.0.41.14-ENG.
• Deployments using APM only as an OAuth Client or Resource Server, without an OAuth authorization server profile, are stated to be unaffected. The status of other branches is not established by the record, and software that has reached End of Technical Support was not evaluated.

F5 BIG-IP APM is the affected subsystem. The record classifies the weakness as CWE-122, heap-based buffer overflow and states that it occurs when a virtual server has both an APM access policy and an OAuth profile, with APM configured as an OAuth Authorization Server. Specific malicious traffic can be sent remotely without authentication or user interaction, resulting in remote code execution in the data plane. Appliance mode is also vulnerable, while the control plane is not exposed according to the record. The request shape, vulnerable code path, and exact memory-handling mechanics are not disclosed in the available evidence.

• Reachability: Remotely over the network.
• Authentication and interaction: No attacker authentication or user interaction is required.
• Preconditions: The virtual server must use an APM access policy and an OAuth profile, and APM must be configured as an OAuth Authorization Server. Deployments using APM only as an OAuth Client or Resource Server, without an OAuth authorization server profile, are stated to be unaffected.
• Exploitation status: The record marks the vulnerability as known exploited and records a public exploit.
• Limits: The record does not identify a specific exploit, threat actor, campaign, or indicator of compromise.

The vulnerability allows a remote, unauthenticated attacker to send specific malicious traffic and achieve code execution in the BIG-IP data plane. The technical outcome could include loss of confidentiality, integrity changes, and availability disruption for the system or traffic handled by the affected virtual server. Appliance mode is also within the stated affected scope, while the control plane is not exposed according to the record. The exact post-exploitation reach, accessible data, and effect on other systems are not established by the available evidence.

• Access and data: Successful remote code execution could allow an attacker to affect the confidentiality of data processed through BIG-IP and the affected virtual servers.
• Configuration and traffic integrity: Depending on the privileges of the compromised process, an attacker could potentially alter traffic handling or related data-plane behavior.
• Availability: Exploitation could cause service disruption, incorrect traffic processing, or loss of service on the affected system.
• Operational scope: Appliance mode is also vulnerable, while the record states that the control plane is not exposed.
• The record does not identify a specific breach, victim, or ransomware campaign.

1. Install the corresponding hotfix first: Move each affected branch to the supported hotfix boundary listed in the record: Hotfix-BIGIP-21.1.0.2.0.30.22-ENG for the 21.1.0 branch, Hotfix-BIGIP-17.5.1.9.0.160.12-ENG for the 17.5.0 branch, and Hotfix-BIGIP-17.1.3.5.0.41.14-ENG for the 17.1.0 branch.
2. After updating, confirm that the hotfix is installed on the correct device, virtual server, and data plane, then recheck the APM and OAuth configuration conditions.
3. If immediate updating is not possible, prioritize systems whose virtual servers meet the affected configuration and accept traffic from untrusted networks. Do not assume that using OAuth Client or Resource Server mode alone is sufficient if an OAuth authorization server profile remains configured.
4. Because the record marks the vulnerability as known exploited and publicly exploitable, perform appropriate forensic review of exposed systems before or alongside patching. The record does not provide enough detail for a specific IOC or command-based check.
5. Other branches and software that has reached End of Technical Support are not confirmed by this record; verify the applicable supported upgrade path before concluding that a branch is safe or selecting a remediation path.

1. Inventory all F5 BIG-IP systems and record the installed release, hotfix level, and support status. Software that has reached End of Technical Support was not evaluated in the record, so it should not be treated as confirmed safe.
2. Review each virtual server configuration for the combination of an APM access policy and an OAuth profile.
3. Determine whether APM operates as an OAuth Authorization Server or only as an OAuth Client or Resource Server. The absence of an OAuth authorization server profile is the stated exclusion condition.
4. Identify systems running in Appliance mode and assess whether affected data-plane virtual servers are reachable from the Internet or other untrusted networks.
5. Verify the installed hotfix after remediation. As a precaution, review available data-plane telemetry, anomalous requests, and signs of post-exploitation, but the record supplies no log fields, request pattern, or specific IOC. Absence of those signs does not prove that a system is safe.