Hackers Target F5 BIG-IP APM Systems With a Fileless Linux Web Shell

Threat actors are reportedly compromising systems in F5 BIG-IP Access Policy Manager environments and installing a Linux rootkit capable of manipulating PHP file loading. The rootkit injects a web shell directly into memory, allowing attackers to maintain covert access without placing a conventional web-shell file on disk.

The activity was reported on September 8, 2026. However, the initial reporting does not identify the intrusion vector, a corresponding vulnerability, affected software versions, or the number of compromised organizations.

That uncertainty complicates remediation. Defenders cannot yet determine whether installing a particular update closes the attackers’ entry point, but the post-compromise behavior provides a basis for immediate investigation.

A Security Gateway Becomes an Attacker Foothold

The affected environment is F5 BIG-IP Access Policy Manager, commonly positioned in front of sensitive enterprise resources to enforce access policies. Compromise of such a system is more consequential than an infection on an ordinary endpoint.

An attacker controlling an access-management appliance may gain a durable position near authentication flows and protected network services. Depending on the appliance’s configuration and privileges, it could also become a staging point for attempts to reach internal systems.

The reported malware operates in the Linux context underlying the BIG-IP environment. Its main documented capabilities are:

• Intercepting the loading of PHP files.
• Injecting a web shell into system memory.
• Avoiding the creation of a normal web-shell file on disk.
• Concealing malicious execution through rootkit functionality.

No evidence has been disclosed establishing data theft, service disruption, credential interception, or movement into downstream networks. Those outcomes remain possible consequences rather than confirmed findings.

The scale is also unknown. There is no published count of affected appliances or organizations, and no geographic or industry-specific targeting information has been identified. The operators, campaign name, and malware name have not been disclosed.

How the Memory-Resident Web Shell Evades File Scanning

Traditional web shells are usually server-side scripts written into a web-accessible directory. An attacker then sends crafted requests to the script to execute commands or perform other unauthorized actions.

That model leaves a file behind. Security tools can detect it through signature matching, integrity monitoring, suspicious filenames, content inspection, or comparison with a known-good installation.

The technique reported on BIG-IP APM systems removes that dependency. Instead of saving the malicious PHP component as a normal file, the rootkit intercepts PHP-loading activity and injects the web shell into memory.

This creates a gap between what the system appears to contain on disk and what it executes at runtime. A filesystem scan may report no unfamiliar PHP file even while malicious web-shell logic remains active in memory.

The rootkit adds another layer of stealth. Rootkits are designed to interfere with the operating system’s normal visibility into processes, files, network activity, or other resources. The exact concealment mechanisms used in this campaign have not been disclosed, so defenders should not assume that standard administrative output presents a complete view of an affected appliance.

Likewise, the available information does not explain how persistence survives a restart, how attackers communicate with the injected shell, or which PHP-loading mechanism is intercepted. No command-and-control infrastructure, filenames, process names, network indicators, cryptographic hashes, or detection signatures have been published.

Versions, Vulnerabilities and Entry Vector Remain Unknown

The affected product family is F5 BIG-IP, specifically environments operating Access Policy Manager. Exact BIG-IP releases and appliance models have not been identified.

No CVE has been linked to the compromises. It is therefore unknown whether attackers exploited an unpatched software vulnerability, used stolen administrative credentials, abused an exposed management interface, or gained access through another route.

This distinction matters for containment. A software update may remove a vulnerability, but it does not necessarily remove a rootkit from an already compromised device. Conversely, credential rotation alone would not close an unidentified exploitable flaw.

There is also no disclosed fixed version, vendor patch, or confirmed workaround tied specifically to this activity. Organizations should continue applying applicable F5 security updates and hardening guidance, but they should not treat routine patching as proof that an appliance is clean.

Because no vulnerability identifier has been provided, the activity cannot be mapped to an entry in the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog. There is consequently no disclosed KEV inclusion date or remediation deadline associated with this incident.

Detection Must Extend Beyond the Filesystem

Conventional file-based malware scanning is insufficient for this threat. Defenders should combine appliance logging, network telemetry, runtime inspection, configuration review, and memory forensics where those capabilities are available.

Investigation priorities include:

1. Review administrative access. Examine BIG-IP management and system logs for unexplained logins, privilege use, configuration changes, account creation, or access from unexpected sources.

2. Inspect PHP execution behavior. Look for unusual requests, unexpected PHP-loading patterns, execution paths that do not correspond to files on disk, and discrepancies between deployed application content and observed runtime behavior.

3. Analyze memory-resident activity. Investigate anomalous processes and loaded components. Since the web shell is reportedly injected into memory, volatile evidence may be central to determining whether the appliance is compromised.

4. Examine network connections. Identify unexpected outbound traffic, persistent sessions, unfamiliar destinations, and connections that do not match the appliance’s operational role.

5. Check for web-shell behavior, not only web-shell files. Suspicious command execution or request patterns may remain visible in logs or network data even when no malicious script exists on disk.

6. Validate system integrity. Compare the appliance’s configuration and software state with trusted baselines using approved F5 administrative or forensic procedures.

The absence of published indicators means these checks will require behavioral analysis rather than simple matching against hashes or IP addresses. A clean disk scan alone should not close the investigation.

Suspected Appliances Require Evidence-Preserving Containment

Organizations that identify credible signs of compromise should isolate the affected BIG-IP system while preserving logs and volatile memory. Immediate rebuilding or restarting may alter the evidence needed to understand the rootkit and its in-memory payload.

Incident responders should determine when unauthorized access began, which accounts interacted with the appliance, and what internal or external systems communicated with it. The review should extend beyond the BIG-IP device because a compromised access gateway may have been used to reach protected infrastructure.

Credentials accessible to or used through the affected system should be rotated after containment. Privileged accounts, automation credentials, service accounts, and administrative access paths warrant particular scrutiny.

Restoring trust may require more than deleting suspicious files, especially when none are present. Organizations should use vendor-supported recovery and integrity-validation procedures and verify that malicious runtime modifications cannot survive or return after remediation.

Until F5 versions, an initial access method, and validated fixes are disclosed, defenders face two separate tasks: reducing exposure through current security updates and determining whether attackers are already operating inside deployed appliances. The second task cannot be solved by patching alone.