PHP Critical RCE (CVE-2026-109618 & CVE-2026-109619)

Published: Thu 22 October 2026

Prepared by: Brandon Sawyer, Vulnerability Analyst

Purpose

On 21 October 2026, the PHP project released emergency security updates for two critical remote code execution (RCE) vulnerabilities in the core PHP engine, CVE-2026-109618 and CVE-2026-109619, collectively known as "PHP2Shell". Details leaked online on 20 October ahead of the coordinated disclosure, forcing PHP to bring the release forward by a day. The flaws allow an unauthenticated remote threat actor to execute code on any web server running an affected PHP version, regardless of the application running on top of it. watchTowr reports in-the-wild exploitation through its honeypot network as of 21 October, and Rapid7 recommends patching on an emergency basis outside normal cycles.

Vulnerability Details

Both vulnerabilities are memory-safety flaws in how PHP handles fatal errors, particularly out-of-memory (OOM) errors, during request processing. Each carries a CVSS v4.0 base score of 9.2 (Critical), vector string CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N, and successful exploitation grants code execution with the privileges of the web worker.

According to Wiz Research, which discovered the flaws with the help of frontier AI models, a fatal error can leave corrupted internal state behind when a request ends abruptly. A later request handled by the same worker then reuses that stale state. Crafted multipart (form and file upload) requests can trigger the condition, and the session upload progress feature, enabled by default, can consume the stale state even if the application never calls session_start().

All PHP installations serving web requests are at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers mod_php the highest risk, as exploitation can succeed before any application code runs. Wiz demonstrated pre-authentication RCE against the latest WordPress, Drupal and Joomla container images, and separately showed that passwords, tokens and API keys could be read from process memory without achieving RCE.

Wiz states every PHP version released in the past decade, back to PHP 5.4, is affected by at least one of the flaws. Palo Alto Networks has also confirmed that PAN-OS and Panorama are affected, with fixes pending.

Impact

Successful exploitation grants a threat actor unauthenticated code execution on the web server as the web worker account. Because PHP powers an estimated 70% of websites, including WordPress, Drupal, Joomla and Magento, as well as control panels and vendor software that bundle PHP without advertising it, a compromised server can expose:

• Passwords, session tokens, API keys and certificates held in PHP process memory, including data from other users' requests
• Application databases, customer data and business logic behind internet-facing sites
• A foothold for web shells, persistence and lateral movement into the wider network
• Website defacement and service disruption

The vulnerable code sits below the application layer, so a fully patched CMS or even a simple application running on an affected PHP version can still be exploited. Internet-facing Linux web servers and shared hosting without endpoint detection are particularly at risk of quiet, unnoticed compromise.

With exploitation already reported, multiple independent reproductions under way and AI lowering the effort needed to adapt exploits across deployments, mass exploitation is probable and swift patching should be prioritised.

Mitigation

Primary Remediation

The primary remediation is to update all PHP installations to the fixed version for their release line, or a vendor package containing both complete patches:

Linux distributions and LTS vendors received patches in advance, so check your vendor for updated packages. Users of the rpms.remirepo.net repository should switch to distribution packages or build from source, as updates there were delayed. Patch internet-facing systems first.

Palo Alto Networks PAN-OS and Panorama are affected and fixes are pending. Until they are released, restrict management interface access to trusted internal IP addresses or a jump box. Threat Prevention signatures 543004, 97622, 97623, 97624 and 97625 provide coverage.

Compensating Controls

Where immediate patching is not possible, PHP's interim configuration changes can reduce exposure to the confirmed attack paths. Each must be set administratively (php.ini, FPM pool or server configuration, not ini_set() or .user.ini) and every worker restarted:

• Set session.upload_progress.enabled=0 to close the confirmed session lifecycle paths
• On PHP 8.5, set fatal_error_backtraces=0 to close the fatal error backtrace path
• Enforce memory_limit=-1 to remove the predictable OOM trigger, while bounding request size at the frontend (post_max_size of 8M, or 32M where uploads are needed) to avoid resource exhaustion
• Block multipart requests at a WAF or reverse proxy if the application does not use them
• Isolate end-of-life PHP from the internet, or place it behind a VPN or WAF

These measures are stop-gaps only. They address specific known paths, will not remove any access a threat actor already gained, and an update containing both fixes remains the only complete remediation.

Detection

Indicators and Log-Based Detection

As this is an extremely new and emerging situation, no confirmed indicators of compromise (IOCs) have been published at this time. Because exploitation occurs below the application layer, application logs may hold little context, and suppressing diagnostics does not prevent exploitation, so an absence of log entries should not be treated as proof a server is safe.

In the absence of vendor IOCs, the following hunting leads are derived from Wiz and Huntress reporting and should be treated as a starting point rather than a complete picture:

• Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses
• Unexpectedly large or malformed PHPSESSID response cookies, which may indicate memory disclosure
• Unexplained PHP worker crashes or churn
• PHP worker processes (php-fpm, php-cgi, httpd, apache2) spawning shells (sh, bash, cmd.exe, powershell.exe), interpreters (python, perl) or download tools (curl, wget, nc, certutil.exe)
• Command lines containing reverse shell patterns such as /dev/tcp/, fsockopen or mkfifo
• Reconnaissance commands such as whoami, id, uname -a or ipconfig run from the web server

Recommended Detection and Hunting Activities

• Inventory all PHP installations and confirm versions to scope exposure
• Review web server, PHP and WAF logs for the indicators above, focusing on the period since 20 October 2026
• Alert on PHP worker processes launching shells, interpreters or download tools
• Check web roots for web shells and new files, and review for new cron jobs, scheduled tasks and accounts
• If any indicator is identified, isolate the server, preserve web server and PHP logs, rotate accessible secrets and engage incident response

This is an emerging situation and details are still developing. Triskele Labs is actively monitoring vendor and researcher updates, and this advisory will be updated as further information, including indicators of compromise and additional patch guidance, becomes available. 

Clients with IR retainer will receive a threat hunt that is being developed specific to CVE-2026-109618 & CVE-2026-109619. 

MDR customers: Triskele Labs will continue tuning detections and analysing IOCs for behaviours consistent with the exploitation of CVE-2026-109618 and CVE-2026-109619 across supported log sources as they are made available.

Vulnerability Management customers: Environments will be assessed for vulnerable versions of PHP affected by CVE-2026-109618 and CVE-2026-109619 once detections are made available. Any findings will be communicated through priority channels.

Update: Compensating Controls

Bringing the servers back online without the patch: PHP2Shell compensating controls

You can bring the servers back online before the patch is available, provided the immediate controls below are in place first. This does not remove the vulnerability. It reduces the likelihood of successful exploitation and contains the impact if it occurs, to a level that is monitored and can be responded to.

Immediate: must be in place before servers are turned on

• Threat hunt before you power on. Assume exploitation may have already occurred before shutdown. Hunt for web shells, new or modified files in web roots, unexpected cron entries, and unknown outbound connections. Do not bring a compromised host back online.
• Rotate credentials and invalidate sessions. One of the vulnerabilities in this set (109618) leaks worker memory to unauthenticated callers. Any host that was exposed should be treated as having leaked database credentials, API keys, secrets held in environment variables and configuration, and session data. Rotate every secret the web tier holds or can reach, and invalidate all active customer and administrator sessions before go-live. Doing this at 72 hours is too late; the leaked material is already in someone’s hands.
• WAF in front of every PHP-facing service. Enable your provider’s managed rules for these CVEs where they have shipped them. Where your provider has not, apply body size caps, multipart restrictions and POST rate limiting as custom rules; these are what can actually be deployed today. Set it to block, not monitor. If you need coverage faster than your current provider can give it, RedShield (redshield.co) is a managed web application security service that is already detecting and dropping PHP2Shell exploit attempts at the edge. They deploy in-flight patches that intercept and rewrite requests before they reach the application, with no code changes, and can typically stand up in front of a site in days. For a retailer that cannot patch and cannot stay offline, this is the fastest route to a WAF that is actively blocking this vulnerability rather than waiting on managed rules.
• Application allowlisting on every affected host. If you already have ThreatLocker, Airlock Digital or an equivalent licensed, confirm the agent is installed on the vulnerable servers and move it to enforce. If you do not, deploy one now. Run in learning or audit mode for a few hours of normal traffic, then enforce. Configure the following as a minimum:
  • Block the web server and PHP processes (php-fpm, apache, nginx) from spawning any shell or interpreter: bash, sh, python, perl, curl, wget.
  • Block execution of any binary or script not already on the allowlist, regardless of where it was written.
  • Restrict the web server and PHP processes to writing only within the application path.
  • Where the product supports it (ThreatLocker Ringfencing), restrict outbound network access from these processes to approved destinations only.
  This will not stop the exploit or a web shell, which run inside the already-approved PHP interpreter. It stops what the attacker does next: dropping tooling, establishing persistence and moving laterally.
• Egress deny by default. Block all outbound internet from the vulnerable servers except explicitly required destinations. This breaks callbacks, tooling downloads and data exfiltration.
• Network segmentation. Isolate the vulnerable servers so they can reach only what the application requires (database, cache, payment gateway). No reachability to corporate, admin or management networks.
• EDR deployed and confirmed. Class-leading EDR on every affected host, set to block, with confirmation it is reporting.
• MDR agent running and pre-authorised containment agreed. Confirm the agent is installed, reporting and the hosts are visible to the SOC. For the servers you choose to bring back, we agree a change to the standard response before go-live: if the SOC sees a web shell or confirmed post-exploitation on one of these hosts, we isolate first and call after. This requires a named approver, an out-of-hours contact and the isolation method agreed in writing before the servers come up. Without this, the monitored-risk position has no teeth: detection without authority to act is a phone call during an active intrusion.
• Disable dangerous PHP functions, test first. Disabling exec, shell_exec, system, passthru, proc_open and popen in php.ini reduces what a web shell can do. It does not stop the exploit itself, and applied blind it will break cron and CLI jobs on platforms such as Magento. Test in a non-production environment, confirm scheduled jobs still run, then apply. Remove any PHP handlers or modules not in use.
• Clean snapshot. Take a known-good image of each server before turning on so there is a baseline to compare against and restore from.

Risk at this stage: exploitation remains possible if the WAF controls are bypassed, and bypasses for new rules typically appear within days. The WAF reduces the chance of initial access; allowlisting, egress control and segmentation limit what the attacker can do with it; EDR and MDR detect and, under the pre-authorised containment agreement, respond to what gets through.

Next: within 72 hours of being back online

• Tune allowlisting policy based on the first days of enforcement logs. Close any exceptions granted during go-live that are not required.
• Replace custom WAF rules with provider managed rules as they ship, and confirm they are in block mode. If RedShield is in place, confirm with them that the shield for these CVEs is active and being watched for bypass attempts.
• File integrity monitoring on web roots and configuration files, alerting on any new or changed PHP file.
• Forward web server access logs, PHP logs, allowlisting block events and process execution telemetry to the SIEM.
• Alert on the web server process attempting to spawn shells, interpreters or network tools. With allowlisting enforced these attempts will be blocked, and each block is a high-fidelity indicator of exploitation.
• Run PHP under a low-privilege service account with no sudo and no interactive shell.
• Mount upload, temp and cache directories as noexec.
• Rate limiting and geo-restriction at the edge to reduce exposure to opportunistic scanning.
• Confirm the DFIR retainer is active and the escalation path is agreed with named contacts on both sides.
• Agree the patch path with the vendor, including a test environment and a target date.

Risk at this stage: dwell time. If initial access succeeded before these controls landed, the attacker may be persistent and quiet. The threat hunt should be repeated once these controls are live.

Nice to have: within two weeks

• Extend allowlisting across the full web and application tier, not only the vulnerable servers.
• Web roots mounted read-only, with deployment via a controlled pipeline only.
• Kernel-level containment (SELinux, AppArmor, or minimal containers).
• Admin and management paths restricted to VPN or IP allow-list.
• DNS filtering on the web tier to block resolution of unapproved domains.
• Canary files in web roots to detect unauthorised access or enumeration.

Residual risk to accept

A WAF is a virtual patch, not a patch. The controls above reduce likelihood and limit blast radius but the vulnerability remains until PHP is patched and the process is restarted. The decision to turn on is a decision to accept a monitored, contained risk in exchange for revenue, and it should be reviewed daily until the patch is applied.

Material risk: enforcing allowlisting on a production retail server without a learning period will break the application. Audit mode first, enforce second, with someone watching the first hour of enforcement.

Update: Patching Process

PHP2Shell: patched clients, what to do now

Patching closes the door. It does not tell you whether someone already walked through it. If you patch and stop there, you will feel safe, and that feeling is the problem. Every host that was exposed before the patch landed must be threat hunted. Not sampled. Every one.

Immediate: today

• Confirm you are actually patched. Inventory every PHP instance: php-fpm, mod_php, php-cgi, CLI, containers and images. Scan for it, do not rely on the application team’s list. On each host, confirm the running process is on the fixed version, not just the installed package. Restart php-fpm, apache, nginx and any PHP workers. Rebuild containers from a patched base and redeploy; restarting from the old image does nothing. If you cannot show the running process is patched, you are not patched.
• Rotate credentials and invalidate sessions. One of the vulnerabilities in this set (109618) leaks worker memory to unauthenticated callers. Treat every exposed host as having leaked database credentials, API keys, secrets in environment variables and configuration, and session data. Rotate every secret the web tier holds or can reach. Invalidate all active customer and administrator sessions. Do this today regardless of what the hunt finds.
• Preserve evidence. Snapshot every host that was exposed, from disclosure to restart. Copy web server access logs, PHP logs, authentication logs and process telemetry off-host. Attackers clear local logs.
• Keep compensating controls on. WAF rules, egress restrictions, allowlisting and segmentation stay in place until the hunt is complete and clean. Pulling them the moment the patch lands removes your containment while you may still be compromised.
• Start the hunt on the highest-exposure hosts. Internet-facing, customer-facing, anything holding payment or customer data. Web roots first: list every PHP file and compare against the release manifest, look for new or modified files in upload, cache, temp and vendor directories, and search for ev​al, base64​_decode, gzin​flate, sys​tem, pass​thru and shell​_exec. Check .ht​access for handlers executing PHP from non-standard extensions.
• If you find anything, stop. Do not clean up. Isolate the host, preserve the snapshot, escalate to incident response. Cleaning a web shell before understanding what else was done destroys evidence and leaves the other footholds in place.

Within 72 hours

• Complete the hunt across every exposed host. Scope is every host that ran vulnerable PHP while internet-exposed, from disclosure until the patched process was restarted. If you cannot confirm the restart time, hunt from disclosure to now.
• Hunt beyond the web root. New or modified cron jobs, systemd units, timers and init scripts. New users, SSH keys in authorized​_keys, sudo​ers changes. Modified shell profiles, LD​_PRELOAD entries, kernel modules. PHP configuration changes: auto​_prepend​_file, auto​_append​_file, disable​_functions removed. Scheduled tasks and services on any Windows hosts in scope.
• Hunt for post-exploitation. Web server and PHP processes spawning shells, interpreters, curl, wget, nc, python or perl. Outbound connections from the web tier to unknown destinations, especially hosting and tunnelling providers. Lateral movement from the web tier via SSH, RDP, SMB or database connections to hosts it does not normally talk to. Access to credential stores, environment files and cloud metadata endpoints. Large or unusual outbound transfers.
• Review the initial exploit window. Work through web server access logs for the exploit request pattern across the full exposure period. Triskele Labs is providing detection signatures to managed clients as they develop. Look for encoded payloads, unusual parameters, requests from hosting providers and VPN exit nodes, and single-request sessions with no referrer. Correlate any hit with what happened on the host in the following minutes.
• Check for credential misuse. Review use of the credentials you rotated for anomalous activity from unexpected sources during the exposure window. Check cloud audit logs for actions taken with credentials that lived on the web tier.
• Document the hunt. What was in scope, what was checked, what was found, who did it. If the answer to “did you hunt?” is a shrug, you did not hunt.

Later: 30 days and beyond

• Second hunt at 30 days. A clean first hunt is not the end. Attackers who gained access early return once the patch has landed and attention has moved on. We watched this run for two years after Log4j. Repeat the hunt across the same scope.
• Remove compensating controls only after the second hunt is clean, and keep the ones that cost you nothing: egress deny by default, allowlisting, segmentation of the web tier. They were the right controls before PHP2Shell and they remain the right controls after it.
• Put file integrity monitoring on web roots permanently. Alert on any new or changed PHP file. This is how web shells land and it should never again be invisible.
• Alert on the web server process spawning anything. Shells, interpreters, network tools. With allowlisting enforced these are blocked, and each block is a high-fidelity indicator.
• Fix the patch cycle. If it took days to patch, restart and verify, the next one will too. Build the inventory, the restart step and the verification step into the standard process so they are not rediscovered under pressure.

What Triskele Labs is doing

• Threat hunting for exploitation across every exposed host for clients with a DFIR retainer in place. This is happening now without being asked.
• Monitoring for signs of post-exploitation through MDR for all managed clients. Monitoring tells us when something fires. Hunting finds what is already there and has not fired yet. They are not the same thing.
• Leading incident response where indicators are found.

The threat hunt is delivered under retainer. If you do not have one, we can stand one up quickly.

Material risk: a patched host that was exposed for even a short window may already be compromised. Patching without hunting leaves persistence in place and gives the attacker a quiet, trusted foothold that nobody is watching.

Update: Additional Tools

PHP2Shell: Compensating Controls and the Tools That Deliver Them

If you cannot patch PHP2Shell today, the question is not whether to turn the servers off. It is which controls let you keep them on at a risk you can see and respond to.

The compensating controls themselves are covered in the update above: WAF in front, egress denied by default, segmentation, application allowlisting, EDR and MDR, credential rotation and a threat hunt before anything comes back up. This update is the practical companion. For each control, here are the tools that deliver it, including what is free and deployable today and what is a managed service you can stand up in days.

Two rules for reading it. First, use what you already have. A control you can enforce this afternoon beats a better one you can enforce next month. Second, no single layer holds. The WAF reduces the chance of initial access. Allowlisting, egress control and segmentation limit what an attacker can do once inside. EDR, file integrity monitoring and the SOC catch what gets through. Build all three layers, not one.

WAF and edge

A WAF in front of every PHP-facing service is the first control, and it must be in block mode. Enable your provider's managed rules for these CVEs where they have shipped them. Where they have not, apply body size caps, multipart restrictions and POST rate limiting as custom rules. Those are deployable today on every platform below.

• Cloudflare WAF. Managed rulesets ship fast for high-profile CVEs, it sits in front of almost anything, and the custom rule engine handles body caps and rate limits well.
• Akamai App & API Protector. Adaptive rules and the broadest edge footprint. The natural choice for a large retailer already on Akamai CDN.
• Fastly Next-Gen WAF (formerly Signal Sciences). Strong for API-heavy and headless commerce, with fast custom signals.
• Imperva Cloud WAF. Mature managed rules and virtual patching, widely used in regulated and retail environments.
• F5 Advanced WAF or NGINX App Protect. On-premises or self-hosted where traffic cannot leave the environment.
• AWS WAF with managed rule groups. A reasonable baseline, but it does not yet carry PHP2Shell detections. Use custom rules or put one of the above in front. We expect this to change quickly.
• Azure Front Door WAF. Same caveat as AWS for Azure-hosted estates.
• ModSecurity or Coraza with the OWASP Core Rule Set. Free, self-hosted, and deployable today on nginx or Apache. The right answer for anyone with no commercial WAF and no time to procure one.

Managed virtual patching and in-flight mitigation

If your current provider cannot give you coverage fast enough, a managed service that intercepts and rewrites requests before they reach the application is the quickest route to a WAF that is actively blocking this vulnerability rather than waiting on rules.

• RedShield. In-flight patches that rewrite requests at the edge, deployed and tuned by their team, with no code changes and a warranted outcome. RedShield is already detecting and dropping PHP2Shell exploit attempts and can typically stand up in front of a site in days. For an organisation that cannot patch and cannot stay offline, this is the fastest path we know of.
• Imperva and Akamai managed security services. Vendor-run tuning and custom rule authoring on top of their WAFs, for organisations already on those platforms.
• Sucuri. PHP-focused edge firewall and virtual patching, common in Magento and WordPress estates. Cheap and fast to deploy.
• Patchstack. Virtual patching specifically for WordPress and its plugin ecosystem. Worth naming if any WordPress is in scope, and it usually is somewhere.
• Contrast Security or Imperva RASP. Runtime protection inside the PHP process itself rather than at the edge. Slower to deploy, but it catches the WAF bypasses that will arrive within days of any new rule.

Application control and allowlisting

Application control will not stop the exploit or a web shell, because both run inside the PHP interpreter that is already approved. What it stops is everything the attacker does next: spawning a shell, pulling down tooling, dropping a binary, establishing persistence. Every one of those is a new execution, and allowlisting blocks it.

If you already have one of these licensed, confirm the agent is on the vulnerable servers and move it to enforce. If you do not, deploy one. Run in learning or audit mode for a few hours of normal traffic first, then enforce, with someone watching the first hour.

• Airlock Digital. Allowlisting with parent process rules and script control. Linux and Windows agents. Block the web server from spawning interpreters and shells, and block any unapproved binary or script regardless of how it arrived.
• ThreatLocker. Allowlisting plus Ringfencing, which is the key feature here. Ringfence php-fpm, apache or nginx so they cannot launch bash, sh, python, perl, curl or wget, cannot write outside the application path, and cannot reach the internet except to approved destinations.
• Ivanti Application Control. Windows-centric. Relevant if any IIS-hosted PHP exists.
• Microsoft Defender Application Control and AppLocker. Windows only and free with the operating system.
• SELinux or AppArmor. Native Linux confinement, free, and capable of restricting what the web server process can execute and where it can write. Not as operable as a commercial product, but it is already on the box.

Material risk: enforcing allowlisting on a production retail server without a learning period will break the application. Audit mode first, enforce second.

EDR, egress control and segmentation

These three limit the blast radius. The attacker who gets past the WAF should land on a host that cannot call home, cannot reach anything beyond the application's own dependencies, and is being watched.

EDR. Class-leading EDR on every affected host, in block mode, with Linux sensor coverage on the web tier confirmed and reporting. Any of CrowdStrike Falcon, SentinelOne Singularity, Microsoft Defender for Endpoint or Palo Alto Cortex XDR. The product matters less than the configuration: block mode, not detect-only, and the agent actually installed on the web servers rather than only the corporate fleet.

Egress control. Deny all outbound internet from the vulnerable servers except explicitly required destinations. This breaks callbacks, tooling downloads and exfiltration in one move.

• Zscaler Internet Access, Cloudflare Gateway, Palo Alto NGFW or Fortinet FortiGate for enterprise egress filtering.
• AWS Network Firewall, Azure Firewall or GCP Cloud NGFW for cloud-native deny-by-default egress.
• Host-level iptables or nftables deny-all with explicit allows where nothing else exists. Free and deployable now.

Segmentation. Isolate the vulnerable servers so they can reach only what the application requires: database, cache, payment gateway. No reachability to corporate, admin or management networks.

• Illumio, Akamai Guardicore or Zero Networks for host-based microsegmentation without re-architecting the network.
• Cloud security groups and NSGs tightened to application-only flows as the minimum.

File integrity, web shell detection and canaries

Web shells land as files. A new or changed PHP file in a web root should never again be invisible, during this incident or after it.

File integrity monitoring on web roots and PHP configuration, alerting on any new or changed PHP file, .ht​access, php.ini or cron entry.

• Wazuh (open source and free), Tripwire Enterprise, Qualys FIM, or CrowdStrike Falcon FileVantage if you are already on Falcon.

Secrets, sessions, bots, inventory and containers

Secrets rotation and session invalidation. One of the vulnerabilities in this set leaks worker memory to unauthenticated callers, so any exposed host should be treated as having leaked database credentials, API keys, configuration secrets and session data. Rotate every secret the web tier holds or can reach and invalidate all customer and administrator sessions before go-live, not at 72 hours.

• HashiCorp Vault, AWS Secrets Manager, Azure Key Vault or CyberArk to rotate database and API credentials without downtime.
• A session store flush (Redis, Memcached or database sessions) to invalidate every session in one action.

Bot management and rate limiting. Mass exploitation of PHP2Shell will arrive through automated scanning. Bot controls cut that noise before it reaches the WAF and make the real attempts easier to see.

• Cloudflare Bot Management, Akamai Bot Manager, DataDome or HUMAN.

Asset discovery. The patch and the hunt both fail on the host nobody listed. PHP is routinely present on monitoring tools, internal portals, legacy applications and appliances that nobody thinks of as PHP servers.

• runZero, Tenable, Qualys or Rapid7 InsightVM to find every PHP instance, including the ones the application team does not know about.

Containers. Restarting a container from the old image does nothing. Images must be rebuilt from a patched base and redeployed.

• Wiz, Orca, Aqua or Sysdig to find vulnerable PHP base images across the estate.
• Falco for runtime detection of shells spawning inside containers.

What Triskele Labs is doing

• Monitoring all managed environments for exploitation attempts and post-exploitation indicators.
• Threat hunting for exploitation across every exposed host for clients with a DFIR retainer in place.
• Providing detection signatures and indicators to managed clients as they develop.
• Leading incident response where indicators are found.

If you cannot patch and you are deciding whether to turn the servers off, talk to us before you do. The controls above are how you keep them on at a risk you can see.

Material risk: every control on this page is a mitigation, not a fix. The vulnerability remains until PHP is patched and the running process is restarted, and every host that was exposed before that moment must be threat hunted regardless of what the controls caught.

References

• https://www.php.net/archive/2026.php#2026-10-21-5
• https://www.cyber.gov.au/alert/critical-vulnerabilities-in-php
• https://www.wiz.io/blog/php2shell-php-rce
• https://security.paloaltonetworks.com/CVE-2026-109618
• https://watchtowr.com/intelligence/php-cve-2026-109618-faq/
• https://www.rapid7.com/blog/post/etr-cve-2026-109618-and-cve-2026-109619-critical-unauthenticated-remote-code-execution-in-php/
• https://www.huntress.com/blog/php2shell-leaked-critical-php-vulnerabilities