How Check Point WAF Pre-emptively Blocked “PHP2Shell” (CVE-2026-109618 and CVE-2026-109619)

[Vani]

This week, two critical vulnerabilities came to light in PHP, the language behind WordPress, Drupal, Magento, and countless other websites. Researchers are calling them PHP2Shell (CVE-2026-109618 and CVE-2026-109619), and each is rated 9.2 out of 10 on the CVSS scale.

No password. No account. No user interaction. Just a crafted web request that can let a stranger run code on your server.

In everyday terms: when a server runs low on memory in the middle of a request, PHP’s cleanup can go wrong. A carefully crafted request can turn that mistake into control of the server.

Why it matters

• It is “zero-click.” The attack can reach your server before your own application even starts. Your login pages and input checks never get a chance to stop it.
• The business impact is real. An attacker can run code on the server, read memory that may hold passwords, tokens, and API keys, and reach customer data the application can access
• The reach is wide. Any application on an unpatched PHP is exposed, including WordPress, Magento, and Drupal sites. Updating your CMS or plugins does not fix it, and PHP 8.1 and earlier no longer get regular upstream support
• Attacks came early. Details leaked before the fix shipped on October 21, and researchers reported attacks before the patch landed

The fix is a PHP update: 8.5.12, 8.4.27, 8.3.36, or 8.2.35. But patching a fleet takes time, and that gap is where a web application firewall earns its place.

But not all WAF are the same: Why prevention-first security matters

When a flaw like PHP2Shell or any other zero day appears, the usual WAF playbook is to wait for a rule written for that one flaw, then apply it. That leaves a gap. Check Point takes a prevention-first approach. Our WAF is built for these zero-day attacks with a dual AI engine: no rules to write, no updates to apply, no waiting, just pre-emptive prevention, as our testing on PHP2Shell showed.

How we tested it

Our R&D team took the published proof-of-concept (PoC) exploit and wrote several variants of it. They sent every variant at a PHP application protected by Check Point WAF with Prevent mode enabled.

• No PHP2Shell rule or signature added
• No configuration changes

Here is what the test and the Check Point WAF logs show.

What we saw in the wild

The first PHP2Shell attack we observed came on October 21, 2026. Since then:

• We identified attack attempts against approximately 10% of our tenants and successfully blocked them, without requiring any security patch
• Our protection also pre-emptively blocked the publicly available PoC from the php2shell project without any configuration change

 Why it worked: two AI engines, one decision

• The Attack-Indicator AI engine is trained on millions of malicious and legitimate requests. It picks up subtle attack patterns and new variants, even when no one has written a rule for that flaw
• The Context Analysis AI engine learns how your application normally behaves from live traffic. It spots requests that do not fit and blocks only the malicious ones
• Together, they inspect every incoming HTTP request in Prevent mode and block attacks even before any CVE-specific rule exists

 For customers, that meant:

Customers carried on with their day

✔ No emergency rule tuning.

✔ No configuration changes

✔ No waiting for a PHP2Shell-specific rule

Check Point WAF delivered automatic, pre-emptive protection against PHP2Shell exploit attempts in our testing and in live attacks, without manual intervention.

We recommend enabling the latest signatures in Prevent mode for the best coverage and visibility. Update to the latest PHP version and close any direct path to your origin server.

Not our first zero day

PHP2Shell is another zero day that Check Point WAF handled with ease, with no rule written and no update applied. Our two AI engines block unknown threats by recognizing attack indicators and by learning what normal traffic looks like for your application. That is how Check Point WAF pre-emptively blocked React2Shell, Log4Shell, Spring4Shell, and MOVEit in the same way, without relying on signatures. Our WAF AI engines stop exploit attempts before anyone has written a rule for them.

Be ready for this one, and the next

PHP2Shell will not be the last flaw to go public while attackers are already moving. A WAF that waits for a rule written after disclosure is already behind. Here is how to be ready now:

1. Patch PHP as soon as you can. Most teams cannot update every server overnight. Until you do, your WAF covers the gap.
2. Check that your WAF is in Prevent mode. In Detect mode, Check Point WAF logs an attack. In Prevent mode, it blocks it. Confirm that every policy protecting a PHP application is set to Prevent.
3. Let us do the watching. Check Point Research is monitoring for scanning, and exploitation attempts across ThreatCloud AI, and our support teams are available 24/7.

The next flaw will go public on its own schedule. If you want to be ready, use AI-powered Check Point WAF.