PHP2Shell and the Case for Runtime-Based RCE Detection

In Shenjia's PHP2Shell validation, our existing runtime security capabilities identified malicious behavior in the tested exploit chain without adding a PHP2Shell-specific signature or updating the existing detection rules.

This was not because the product had advance knowledge of the vulnerabilities.

It reflects a different detection approach: examine how untrusted data moves through an application and inspect the operations the application is about to execute.

PHP2Shell covers two memory-safety issues in PHP core:

• CVE-2026-109618: An out-of-memory condition can leave internal request state invalid, creating a path to memory corruption during later processing.
• CVE-2026-109619: Request-owned state can outlive the memory backing it. A later request handled by the same PHP worker may access that stale state, creating a use-after-free condition.

These are not ordinary “upload a PHP webshell and visit it” vulnerabilities. They exploit failures inside PHP's request and memory-management logic, and successful exploitation may result in remote code execution.

That distinction matters.

A security control focused only on known HTTP payloads must learn the characteristics of each new exploit. Runtime Application Self-Protection (RASP) can also examine sensitive operations inside the application execution environment.

Shenjia uses PHP runtime instrumentation to track untrusted input—including data supplied through HTTP parameters—as it propagates through application processing.

When that data reaches a monitored high-risk operation, the product evaluates the execution context and parameters for potential command-execution risk.

Its coverage includes common PHP command-execution interfaces such as:

• system(), exec(), shell_exec(), passthru()
• popen(), proc_open(), pcntl_exec()

Dynamic execution paths, including eval() and assert(), can be examined under the relevant policies. The mechanism can also consider risks associated with serialized or deserialized data reaching sensitive operations.

This is more precise than treating every call to a command-execution function as malicious.

Legitimate applications sometimes perform sensitive operations. By considering input provenance, propagation, execution parameters, and context, runtime checks can provide stronger evidence for a security decision.

Depending on policy and the execution point, Shenjia can generate an alert or block the risky operation.

For the tested PHP2Shell chain, the relevant detection logic was already present; no new vulnerability-specific rule was needed.

When a critical vulnerability breaks, organizations must identify affected assets, test patches, schedule production changes, and determine whether exploitation has already occurred.

This takes time—often while attackers are adapting their techniques.

Behavior-based runtime detection helps narrow that gap.

Instead of relying entirely on a new signature for every CVE, teams can also monitor whether an application is using dangerous capabilities in a suspicious way.

There are important boundaries.

Because PHP2Shell involves memory corruption in PHP core, some exploitation paths may execute native code without passing through a monitored PHP function.

Detection coverage therefore depends on the exploit path and the instrumentation in place. A detected RCE attempt is also not the same as proof that every variant can be blocked.

Updating PHP to a fixed release remains essential. RASP is an additional defensive layer, not a substitute for remediation.

Runtime security only delivers lasting value when it works alongside the applications it protects.

Compatibility, operational stability, and control over enforcement matter as much as detection logic.

Shenjia supports policy-driven monitoring and blocking, enabling teams to observe application behavior, evaluate findings, and apply enforcement according to business risk and operational requirements.

The objective is straightforward: preserve visibility into high-risk execution behavior while giving operators a practical way to manage protection in production.

PHP2Shell is a reminder that critical bugs can emerge beneath otherwise well-maintained applications.

The next vulnerability name will be different. Some of the dangerous operations an attacker attempts afterward may be the same.

The goal is not to predict every vulnerability. It is to recognize risky behavior when it reaches the application runtime.

Shenjia's PHP2Shell validation illustrates the value of that approach: existing RCE detection logic identified attack behavior in the tested chain without a new PHP2Shell-specific rule.