Cato CTRL Threat Brief: Cato AI native SASE delivers PHP2Shell protection at machine speed

Executive summary

On 21 October 2026, PHP released fixes for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities known as PHP2Shell that can enable unauthenticated remote code execution. Cato’s self-evolving CVE mitigation agent helped turn the investigation into concrete research output by creating a proof of concept and generating an IPS signature in minutes. The agent connects vulnerability analysis, controlled lab testing and protection generation. Validation feedback and researcher corrections inform improvements to its skills and workflows, while security researchers review proposed protections before release. Cato has put PHP2Shell IPS protections in place, connecting fast agentic research with cloud enforcement to help customers reduce exposure on inspected traffic while they update affected applications.

Why Cato AI native SASE enables protection at machine speed

Speed matters because attackers can study the same patches defenders use. Our AI-native SASE approach connects our self-evolving agentic CVE mitigation researcher with centralized cloud inspection and enforcement. The researcher helps turn vulnerability analysis into candidate signatures, with validation and security researcher review before release. We can then deliver protections through our cloud without customers installing a separate signature package on each PHP server. This shortens the path from disclosure to protection while application owners complete remediation.

What happened

The flaws affect PHP core rather than a single application or plugin. PHP identifies installations serving web requests as at risk, including PHP-FPM, mod_php, php-cgi, FrankenPHP and LiteSpeed. The highest demonstrated risk is in Apache mod_php, where an unauthenticated request can trigger exploitation before application code runs. A login page therefore does not reliably shield the vulnerable processing.

CVE-2026-109618 concerns out-of-memory handling that can interrupt initialization and leave invalid request data for cleanup to process. CVE-2026-109619 concerns request-owned state retained after its memory is freed and later accessed by the same worker. These failures can lead to code execution. Sensitive process memory may also be exposed. Exploitability depends on the runtime integration, configuration and reachable behavior.

The UK NCSC urged immediate action to identify PHP installations and apply updates. NHS England’s alert highlights code execution and sensitive memory exposure, while Canada’s Cyber Centre also calls for assessment of products that bundle PHP. These official advisories reinforce the urgency of remediation.

The business risk

Public research also shows unauthenticated code execution on tested WordPress, Drupal and Joomla deployments, and separate disclosure of PHP worker memory. These examples illustrate runtime exposure. Exploitability varies by deployment.

For a business, code execution could expose application data, allow content changes or disrupt customer-facing services within the PHP process’s permissions. Memory disclosure could reveal passwords, tokens and API keys even without code execution. Usable credentials could extend the risk to connected services. Prioritize systems by exposure, sensitive data and the business processes they support.

How our self evolving researcher agent built signatures in minutes

Once the PHP fixes became available, we analyzed the changes and found behavior that appeared materially different from the publicly circulated alleged exploit. This prompted additional research before finalizing the signatures. The discrepancy did not establish whether that material described another issue or an incomplete attack path.

Our self-evolving CVE mitigation agent created a proof of concept (PoC) and generated an IPS signature in minutes. The new signatures address the alleged scenario and the patch-analysis findings, with coverage bounded by the attack paths tested.

Our agentic researcher combines vulnerability intelligence, patch analysis and controlled testing to develop candidate IPS protections. Its self-evolving workflow uses validation feedback, execution traces and researcher corrections to refine the skills and workflows used in subsequent investigations. Our security researchers review proposed protections before release, bringing expert judgment to the path from generated signature to customer protection. Figure 1 shows this workflow from patch analysis and PoC creation to signature validation, researcher review and cloud enforcement.

Figure 1. Self-evolving CVE mitigation from patch analysis to PoC, signature and enforcement.

PHP2Shell from PoC to signature in minutes

In Figure 2, the upper pane shows the local PHP2Shell test completion message, while the lower pane shows runtime monitoring and test events. This capture comes from the investigation in which our agent created a PoC and generated a signature in minutes. Detailed outcomes are redacted.

Figure 2. PHP2Shell PoC test and runtime monitoring. Results redacted.

Cato protection

Our infrastructure assessment found that Cato’s production systems are not exposed to PHP2Shell. This finding concerns the infrastructure we operate.

For customer environments, we have added PHP2Shell IPS signatures covering the alleged scenario and additional behavior identified through patch analysis. These protections help block matching exploit requests on traffic inspected by our cloud when the applicable signatures are enabled in blocking mode. Customers should also assess and update affected PHP applications and third-party products in their environments.

The connection to Agentic Threat Prevention (ATP) is the speed of turning evidence into enforcement. Our CVE mitigation researcher uses vulnerability evidence to create signatures after disclosure. ATP evaluates related host activity as an attack develops and activates prevention policies to restrict its next steps.

In our separate controlled demonstration against an agentic attacker, ATP used shared context and inline controls to prevent progression to full domain compromise. The PHP2Shell response described here delivered CVE-specific IPS signatures. Together, these examples show how AI-native SASE can accelerate both the creation of protections and adaptive enforcement during an intrusion.

Our initial response telemetry showed scanning, with no exploitation attempts identified against customers.

The attacker path and where we block it

Figure 3 illustrates a hypothetical PHP2Shell attack and how our IPS protection would apply. It places an attacker on the left, our cloud IPS in the center and a vulnerable PHP service on the right. The crafted request represents an attempt to exploit the PHP runtime. The red stop mark shows where a matching request would be dropped when payload inspection and the applicable blocking protection are active. Some exploit paths involve multiple requests.

Figure 3. Illustrative PHP2Shell attack path and IPS prevention.

The diagram illustrates our protection model rather than documenting an observed customer attack. Traffic must pass through our cloud with its payload visible to inspection and the applicable signature enabled in blocking mode.

Close coverage gaps

Identify PHP services outside our inspection coverage. Extend our inspection coverage and blocking where supported. Protect remaining gaps with an appropriate application-layer control, such as an inbound WAF configured for PHP2Shell. Continue updating affected PHP runtimes.