topic Re: PHP2Shell: Technical Impact, Emergency Protection with Check Point, and Remediation Priorities in WAF

PHP2Shell: Technical Impact, Emergency Protection with Check Point, and Remediation Priorities

WiliRGasparetto — Thu, 22 Oct 2026 09:24:52 GMT

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

Re: PHP2Shell: Technical Impact, Emergency Protection with Check Point, and Remediation Priorities

jberg712 — Mon, 09 Nov 2026 18:31:34 GMT

Hi Will,

I'd like to see some additional information in regards to Check Point products and the PHP version in use. I can see in SK1000302 that it states and i quote: "This Hotfix implements the PHP 7.4 published fix for CVE-2026-109618 and CVE-2026-109619." When running 'php --version' on our Check Point appliances, they all have the same version of PHP of when R82 was released as per the 'hardening specifications' guide. Check Point is running 7.4.33.

According to php.net 7.4.33 was the final release of version 7 in November of 2022. If that's the case, what 'published' fix for PHP was implemented for Check Point as it appears PHP.net didn't release ANYTHING for version 7 since it's been EOL since 2022.

Is there any detail to the fix released for 7.4.33 that we can be given that informs us of the fix such as binary changes/updates? Or was the fix simply just to add manual mitigation automatically? I'm really confused and concerned since the version of PHP still shows the same version of PHP it's always had even prior to the fix'

Re: PHP2Shell: Technical Impact, Emergency Protection with Check Point, and Remediation Priorities

WiliRGasparetto — Tue, 10 Nov 2026 09:55:25 GMT

Hi @jberg712 ,

I completely understand your concern regarding the PHP version displayed on Check Point appliances (7.4.33) and the mention in SK1000302 that a hotfix was implemented for CVEs CVE-2026-109618 and CVE-2026-109619, even though official support for PHP 7.4 by PHP.net has ended.

1. Why doesn't the PHP version change after the hotfix?

What often happens (including with other vendors) is that when a vulnerability is discovered in software that has reached end-of-life (EOL), appliance or embedded system manufacturers apply specific fixes (backports) directly to the source code of the existing version.

This means that even though PHP.net did not release a new official version after 7.4.33, Check Point may have applied a security patch directly to the PHP 7.4.33 binary/source used in the system.

By default, thephp --versioncommand will continue to show "7.4.33" because the official interpreter version is not changed for each custom security patch applied by the vendor.

2. What exactly was fixed?

Public documentation (including the R82 Jumbo Hotfix Accumulator) states that the hotfix implements the fix for the mentioned CVEs, but does not detail the specific binary or technical changes applied to PHP.

There is no mention of a PHP version update, but rather the application of a fix for the vulnerabilities, which strongly suggests the use of backporting.

There is no indication that the mitigation was only manual (e.g., via configuration), but rather that the affected component was updated.

3. How can I confirm the fix was actually applied?

The most reliable method is to check if the corresponding hotfix/jumbo is installed on the appliance (for example, via SmartConsole or CLI).

Check Point typically does not change the PHP version number for each patch applied, but ensures that the binary contains the necessary fixes.

For more in-depth technical details (such as binary hashes, modified files, etc.), it is recommended to open a case with Check Point support, as this information is not published openly for security and internal version control reasons.

Re: PHP2Shell: Technical Impact, Emergency Protection with Check Point, and Remediation Priorities

PhoneBoy — Tue, 10 Nov 2026 18:01:07 GMT

Much like @WiliRGasparetto said, when we apply a patch to an Open Source component, we do not change the version number.
This has been the case with OpenSSH for years and is why we have an SK like: https://support.checkpoint.com/results/sk/sk65269

Note that we usually only upgrade underlying components to new versions as part of a version upgrade, not a standard jumbo hotfix, and not always to the most recent version.
This is because major new versions often require other components to be upgraded (e.g. kernel/userspace libraries), which has other implications.

Re: PHP2Shell: Technical Impact, Emergency Protection with Check Point, and Remediation Priorities

WiliRGasparetto — Wed, 11 Nov 2026 10:42:00 GMT

Exactly, phoneboy very well put. In my opinion, an immediate move to the new version would be a mistake; it would likely introduce further compatibility issues, or perhaps even expose us to a new CVE in that subsequent version which, as we know, is entirely possible.

Re: PHP2Shell: Technical Impact, Emergency Protection with Check Point, and Remediation Priorities

jberg712 — Wed, 11 Nov 2026 21:33:22 GMT

@PhoneBoy @WiliRGasparetto

Thanks for the responses. I definitely understand compatibility and the at times the reason for not moving forward onto a new major release from a technical standpoint. From a security standpoint however, what I'm trying to clarify is some form of evidence that shows a version of a 3rd party product was in fact updated and patched and is not vulnerable even though a version number hasn't changed. The deal is as I know and personally trust Check Point is making good on what they do being a security company, others need more convincing. When they don't see a version revision or change and you're just saying, 'install this fix' the fix is installed without having some indication it's actually fixed and not vulnerable, we get asked questions by those people... those people being auditors and other higher up management that have concerns of the security. And when there is no noticeable change, such as a version release, or a release that the 3rd party deems secure, and I know we all take it on their word too, having something additional to indicate our products are not vulnerable helps quell those fears and questions. To them they don't understand the technical lingo and more times than not, a published article can suffice. I have had to use published articles against such vulnerablities like OpenSSH, and a lot times will leave it alone, but I can tell when there is conflicting information like when a company that uses OpenSSH, and older version comes up on a vulnerability scan, it's difficult to come to a conssensus and an easy to understand for the non-technical to ensure them we are safe and not vulnerable.

It's a difficult battle and I can see both sides of the issue which is why i'm asking the question about such a high rated vulnerability and with no version change even with a backport installed without some evidence behind it to show a version release change or build number or take or whatever you want to call makes it more difficult to appease and those people start asking more and more questions. And at some point if Check Point continues to use PHP 7 down the road in the 10 years time, there may be a loss of customers becasuse of concerns of potential vulnerabilities, especially when those are EOL and the 3rd parter vendor isn't going to backport or do anything. Thankfully it does seem like PHP did do a back port of it, but there's no guarantee in the future they will continue to do so. So I do hope in some way the higher supported versions of PHP, OpenSSH, etc, do get upgraded and the Check Point products are in the works to incorporate those.

Re: PHP2Shell: Technical Impact, Emergency Protection with Check Point, and Remediation Priorities

PhoneBoy — Wed, 11 Nov 2026 22:06:33 GMT

Ultimately, many people trust a version number to be an accurate indicator that a system is (not) vulnerable to a given exploit.
The only way to be absolutely certain is to test.

Re: PHP2Shell: Technical Impact, Emergency Protection with Check Point, and Remediation Priorities

jberg712 — Wed, 11 Nov 2026 22:10:31 GMT

I agree completely. Unfortunately, some people only look at numbers and trust that is correct. I can make a new revision of a file and all I did was add comments to certain lines of code without any real code change. Would be dishonest in some ways, but that's the whole point of knowing what you trust. And what will the auditors and higher ups choose to trust.