The vulnerabilities CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell, require immediate attention from application, infrastructure, and security teams. They involve memory management and the PHP request lifecycle, potentially allowing unauthenticated remote code execution.
In his LinkedIn alert, Moti emphasized the need to activate the emergency IPS protection while patching servers. He also highlighted Check Point WAF’s proactive blocking of the RCE.
Congratulations to Matanya Moses and the Check Point IPS team for rapidly delivering emergency protection and responding to a threat of this severity. Their work provides an important defensive layer while organizations identify exposed systems, validate updates, and implement changes.
To translate that protection into operational results, we need to verify enforcement on the relevant traffic and remediate affected systems in parallel.
How the vulnerabilities work
| Vulnerability |
Technical mechanism |
Consequence |
| CVE-2026-109618 |
Out-of-memory handling interrupts operations while internal request structures are still partially initialized. Request shutdown may consume this invalid state. |
Memory corruption with potential remote code execution. |
| CVE-2026-109619 |
A worker retains references to memory belonging to a completed request. A subsequent request may access those references before the state is reinitialized. |
Use-after-free, memory disclosure, and potential remote code execution. |
For the first vulnerability, the advisory describes issues associated with interruption through longjmp() during out-of-memory conditions. With Apache mod_php, exploitation was demonstrated before application code executed.
For the second vulnerability, exploitation depends on an operation that leaves stale state and another operation that later consumes it within the same worker. Session lifecycle paths were validated in both mod_php and PHP-FPM.
These differences matter when assessing exposure: PHP integrations should not be assumed to have identical exploitation conditions. Likewise, using PHP-FPM alone is not sufficient evidence of immunity.
What a compromise could affect
Code initially executes with the web worker’s privileges. This does not automatically imply root access, but it may be sufficient to compromise application data and functionality.
The scope depends on factors such as:
- Credentials, tokens, and configuration files accessible to the process.
- Write permissions on application directories and the webroot.
- Volumes and user accounts shared between applications.
- Connectivity to databases, internal services, and administrative networks.
- Outbound internet access.
These are impact assessment considerations, not a claim that every exploitation attempt will produce all these outcomes.
Application authentication should also not be considered sufficient protection when vulnerable processing occurs before application code. The position of the access control within the request flow matters.
Emergency protection: what to verify in Check Point IPS
Check Point published advisories CPAI-2026-15172 and CPAI-2026-15184, associated with both CVEs and the PHP Remote Code Execution protection.
The published instructions include updating IPS, locating the protection, reviewing its settings, and installing policy on the Security Gateways.
For operational validation, I recommend checking:
- Updates: the applicable protection package has been updated and made available to the inspection environment.
- Profile: the protection is enabled in the profile that actually applies to the application.
- Action: the effective configuration enforces prevention, accounting for exceptions, staging, and any Detect settings.
- Policy: installation completed successfully on the gateways handling the traffic.
- Traffic path: the connection actually traverses the expected inspection point.
- Visibility: the security engine can inspect the relevant HTTP content.
The advisories document the following log fields:
Attack Name: Web Server Enforcement Violation
Attack Information: PHP Remote Code Execution
Detect provides visibility, but it does not mean blocking. The presence of a protection in the catalog also does not establish that it is being enforced on a connection.
When investigating events, correlate the protection, recorded action, source, destination, timestamp, and inspecting gateway. An absence of alerts does not prove an absence of exposure.
HTTPS, WAF, and direct origin access
Moti’s emphasis on Check Point WAF’s proactive protection reinforces the importance of complementary controls during the response.
However, coverage must be assessed along the application’s actual traffic path. For HTTPS, identify where TLS terminates and where content becomes available for inspection. A protection that depends on HTTP content needs access to that content.
Also check whether the origin can be reached through paths that bypass the WAF or gateway: a direct public IP, an alternative VIP, an old application publication, or internal access that is not subject to the same policy.
Blocking an observed exploitation path should not be interpreted as a universal guarantee against every variant. Emergency protection reduces exposure while patching progresses.
Patched versions and inventory
The PHP project released fixes in the following versions:
| Branch |
Patched version |
| PHP 8.2 |
8.2.35 |
| PHP 8.3 |
8.3.36 |
| PHP 8.4 |
8.4.27 |
| PHP 8.5 |
8.5.12 |
Distributions and vendors may provide backported fixes. In those cases, validate the complete package version and the corresponding advisory; the base version reported by PHP may remain unchanged.
PHP 8.1 and earlier remain outside regular upstream support. The minimal source backports provided for 7.4, 8.0, and 8.1 do not represent a resumption of that support.
When building the inventory, remember that php -v identifies the CLI binary used in that context. The web service may use a different package, executable, or container.
Verify the runtime actually serving requests and include every replica, deployment image, and instance that could return through autoscaling or rollback. Updating only the CMS or framework does not establish that PHP has been patched.
For components embedded in Check Point products, consult sk1000302 and follow the procedure applicable to the installed version. Updating IPS and maintaining an embedded component are separate activities. Do not manually replace appliance packages with packages from a general-purpose distribution.
Change plan and validation
For application servers, the implementation should include:
- Identify exposed services and the applicable patched package.
- Prepare configuration backups and service recovery procedures.
- Validate compatibility on a controlled instance.
- Remove backends from service as the architecture allows.
- Update the runtime and replace processes still running the old code.
- Test authentication, sessions, uploads, and integrations.
- Confirm that all replicas and future deployment images are updated.
- Monitor errors, worker restarts, latency, and memory consumption.
Rollback must account for security exposure. Restoring a vulnerable image may recover service while reintroducing the vulnerability. If necessary, that rollback should have defined containment measures and a deadline for remediation.
Temporary configuration changes should follow the PHP advisories. They may reduce specific exploitation paths but do not replace patching.
When to investigate beyond the patch
Unexpected processes spawned by the web service, webroot modifications, unusual outbound connections, and recurring worker failures warrant investigation. These signals are not exclusive to PHP2Shell and must be correlated with normal application behavior.
If there are indications of compromise, preserve evidence and conduct incident response in parallel. Applying the patch does not automatically remove persistence or invalidate credentials that may already have been obtained.
The IPS team’s rapid response deserves recognition. For those operating the environment, the next steps are to confirm prevention on the correct traffic, complete patching, and record evidence that the exposure has been addressed.
Have you validated effective protection in your environment? Is your biggest challenge the PHP inventory, embedded components, or the maintenance window required to update applications?
References
