I never expected PHP to make mainstream headlines, but PHP2Shell changed that. PHP is a server-side programming language behind many websites, online stores and customer portals. Successful exploitation can expose customer data, disrupt transactions and services, and put revenue and trust at risk. Here we show how a Tetragon behaviour policy set can be loaded at runtime to restrict actions that might be taken maliciously after compromise, without restarting the application just to install the policies. We’ll explain the risk posed by the PHP2Shell vulnerabilities, then show how a behaviour policy set developed by Isovalent’s dedicated threat research team can limit the impact post-exploit. We’ll focus on examples based on Apache with PHP loaded as a library (mod_php) to explain what the policies control, what to customize and how to validate them for your application. These policies work across both open source Tetragon and Isovalent Runtime Security which builds on Tetragon’s eBPF-based runtime visibility and enforcement. Both offerings give teams evidence about process, file and network activity, together with controls that can reject selected operations inside the Linux kernel. For a PHP application, a behaviour policy set can define which programs its worker may launch, where it may connect and which files it may access.Those permissions remain useful beyond a particular CVE. If a later exploit attempts the same prohibited program launch, connection or file access, it encounters the same control. This gives teams guardrails that reduce the actions available after compromise across multiple vulnerabilities. These guardrails provide runtime protection, giving you a window in which you can roll out the PHP updates that fix the vulnerabilities themselves. PHP2Shell Vulnerability On 21 October 2026, PHP published advisories for CVE-2026-109618 and CVE-2026-109619, commonly discussed as PHP2Shell. The first concerns invalid internal state following memory exhaustion; the second concerns stale state retained across requests. Successful exploitation can allow unauthenticated remote code execution with the web worker’s privileges - and these are not just theoretical threats as PHP’s advisories demonstrate possible paths to exploitation. We always recommend updating to the latest vendor provided version and patches provided in response to CVEs to safeguard against any vulnerability. But a Tetragon policy set can provide protection while you plan the roll-out of those updates. Protecting Apache workers with Tetragon Tetragon uses eBPF to evaluate policy at kernel hooks for operations such as program execution, file access and socket connections. Its selectors combine the operation with process and resource context. A matching enforcement action can reject a covered operation without waiting for a user-space agent to consume an alert and respond. The event also gives investigators context about the responsible process. The Apache behaviour policy set provided by the Isovalent security team organizes these controls into four priorities: The policies provided in this blog post are a framework, and are not designed to be just applied to your environment without modification for your specific application needs and infrastructure configuration, for example, the correct binary paths used by your application, or internal network address ranges for network connectivity to other services. Users of these policies will be expected to curate them around their specific environment. These policies are provided as examples and do not cover the full range of configurable features within Tetragon that could be used for further mitigations. 1. Control program execution can-execute-binaries.yaml detects when non-root Apache processes (which normally handle PHP requests) attempt to launch an executable, using a hook at security_bprm_check, a Linux kernel security check in the execution path. can-execute-binaries-from-shell.yaml controls the set of programs that can be launched through selected shells with Apache as their parent or grandparent. Together with can-execute-binaries.yaml, these policies address both direct execution and the shell-mediated path used by some applications. Applications that need to run other programs can make targeted exceptions. For example, a video-upload service might use FFmpeg to convert uploaded videos. If Apache starts ffmpeg directly, add its full executable path to the allowlist in can-execute-binaries.yaml. If it launches ffmpeg through a shell, allow that shell in the direct-execution policy and ffmpeg in can-execute-binaries-from-shell.yaml. Use the paths shown in your runtime events produced by Tetragon. The following recording walks you through using similar policies as above to mitigate the process execution post-exploit tasks. 2. Restrict outbound communication A compromised worker can attempt network communication directly, even when it cannot launch another program. Restricting destinations can limit callbacks, payload retrieval and data transfers. From the below examples can-connect-socket.yaml checks outgoing IPv4 and IPv6 connection attempts at security_socket_connect. can-send-udp.yaml separately checks UDP sends, including traffic that does not first establish a connection. Both select Apache and its tracked children processes, allowing configured destinations and rejecting other covered activity in enforce mode. Build the permitted destinations around the application’s database, service and DNS dependencies. Tighten the broad internal ranges in the examples: allowing an entire private network may leave lateral-movement targets reachable. Allowed services and DNS traffic remain possible data channels. Data can also leave through an existing HTTP response or another already-established connection. The decision you will need to make is how much communication the application needs and which destinations can be removed from its reach. This excerpt shows the two selectors that are used for restricting a binary's access to creating socket connections. Replace the illustrative addresses and port with the application’s required services, and use the Apache executable paths from your deployment. SAddr and SPort match connection attempts from the selected binaries and their tracked children against the permitted destination addresses and ports. Both must match to bypass the fallback rule. Other IPv4/IPv6 connection attempts trigger `NotifyEnforcer`, which reports in monitor mode and rejects in enforce mode. Each listed port applies to every address in the same selector. The below examples check destinations supplied with individual messages and peers stored in connected UDP sockets. This excerpt retains its hook arguments and all three selectors; metadata and enforcer setup are omitted. This address allowlist applies to every destination port, including UDP replies. Pair it with the connection policy to cover connection attempts as well. 3. Protect files and constrain persistence A worker that cannot start a shell may still try to read credentials or leave a PHP backdoor on disk. File controls provide separate boundaries around data exposure and persistence. For this section, we are first providing two similar policies, one works off an allowlist configuration, the other a denylist configuration. It is for you to choose which one works best for your environment. can-write-allowlist.yaml restricts write-mode opens to approved locations and separately checks listed PHP extensions. can-write-denylist.yaml protects named system locations, PHP files and sensitive configuration filenames. The choice depends on whether the team can define a small set of writable directories or needs to protect selected locations. The allowlist excerpt shows the shared Apache scope and the check for write-mode opens outside permitted prefixes. The denylist excerpt shows a protected-directory rule with an exception, followed by a filename-ending rule. Both inspect file opens at security_file_open, a Linux kernel security check that runs when a process opens a file. Customize the application’s upload, session, cache and data directories, retaining only required exceptions. Allowing writes to a directory does not automatically allow PHP files to be written there. Applications that install PHP-based plugins or modules need both a writable directory and a separate exception permitting PHP files in that directory. can-read-sensitive-file.yaml specifies which files to protect. It reports matching attempts to open those files for reading in monitor mode and blocks them in enforce mode. Add the paths of application-specific credential and key files to its protection rules. The write and read policies select Apache and its tracked descendants, excluding file-access user IDs (fsuid) 0 and 100000. Review these exclusions and path exceptions against your deployment before enabling enforcement. They cover new file opens; already-open descriptors and credentials held in memory remain available to a compromised worker. rename-to-php.yaml checks renames to listed PHP extensions, addressing files introduced under another name and later interpreted as PHP. Checks like this can prevent a malicious actor from landing a new PHP file which then gets executed by the runtime. Match the case-sensitive suffixes to the server’s actual handlers; source names already ending in a listed suffix are exempt. The optional directory exception is commented out. If the application needs that exception, adapt it to the destination path reported in events, which is relative to its filesystem mount. 4. Tailor further protection to your environment The first three policy groups provide adaptable starting points for common post-exploit behaviour. Isovalent has further controls for other actions a compromised PHP worker might attempt, including launching separate programs from memory-backed locations such as /dev/shm and creating new symbolic or hard links that could redirect file access. Other policies can restrict user-ID changes by selected non-root Apache processes and kernel-module loading attempts by Apache and its tracked children. Module loading matters only where a process already has the required privileges. Choosing and applying these additional controls requires a closer look at the application's process relationships, filesystem use and permissions. Their scope and exceptions must fit your specific deployment. Contact Isovalent to assess your stack, assistance with the relevant policies and validate them before enforcement. Put the behaviour policy set into operation The supplied policies excerpts, run your policies in monitor mode by default, reporting matching activity without blocking it. Use this mode to check the set against the application’s normal activity before enabling enforcement. Work with your application teams to identify required programs, destinations and files access. Security teams can use this information to refine and tune the permitted operations via these policies when enforcement modes are configured. Test normal requests, uploads, sessions and background work alongside the actions that should be rejected. Confirm the effective enforcement mode and successful hook loading, since runtime and load-time settings can override the manifest. Where a policy tracks children processes, install the policy before starting the relevant worker processes. Similar behaviour policies are available for PHP-FPM deployments, where PHP runs as a separate service behind Apache or Nginx. Contact Isovalent for access to our full range of policies, or for assistance in crafting policies for your specific platform and application implementations.