PHP2Shell: How to Protect Your Website Visitors

PHP2Shell is a pair of critical flaws in the PHP engine that let an attacker run code on a web server with crafted HTTP requests, no login needed. On Apache with mod_php, one request is enough. PHP shipped patches on October 21, 2026. The first recorded exploitation attempt came four days earlier.

This guide shows you how to check your servers, how to fix them, and why a compromised server puts your website visitors at risk.

How PHP2Shell works

The flaws are in how PHP cleans up after a fatal error, such as running out of memory, partway through a request. Cleanup can leave stale internal state behind, and a later request on the same worker can reuse it. Wiz Research demonstrated two outcomes:

• Remote code execution without a login. Wiz ran it against the default wordpress:latest, drupal:latest, and joomla:latest container images. Those were sample targets: a “Hello World” app on an affected PHP version is exposed too.
• Memory disclosure. An attacker can read a chunk of live worker memory, including data from other requests: passwords, session tokens, API keys, and certificates. It works without code execution, even if the app never starts a session.

PHP2Shell at a glance

Is PHP2Shell being exploited?

Yes. Amazon Threat Intelligence recorded an exploitation attempt on October 17, 2026, four days before public disclosure, and more attempts from multiple actors on October 21. Amazon now describes the flaws as broadly exploited in the wild, and Cloudflare and watchTowr report attacks against both CVEs (Tenable).

How attackers got exploit details before disclosure is still unknown (Help Net Security). Most patch plans assume you hear about a flaw before attackers use it. With PHP2Shell, attackers moved first.

How to check if your servers are affected

Check the PHP version your web service actually runs, not just the one on the command line, then compare it with the fixed releases. Start with internet-facing servers.

1. Inventory every place PHP runs. Include web hosting, containers, appliances, and products that bundle their own PHP runtime. CERT-EU points to an NCSC-NL list of affected third-party products.
2. Check the version the web service uses. On Linux, for example:

php -v
php-fpm -v
systemctl list-units --type=service | grep -E 'php.*fpm'
apachectl -M | grep -i php
ps -ef | grep -E '[p]hp-fpm|[p]hp-cgi|[f]rankenphp|[l]itespeed'

On Debian and Ubuntu, the FPM binary carries its version, for example php-fpm8.3 -v. Check containers separately: list them with docker ps, then run the version check inside each one with docker exec <container> php -v. For managed hosting or bundled products, ask the vendor which PHP build runs your site and whether it’s patched.

3. Compare with the fixed versions. Linux vendors often backport fixes without changing the version number, so check your vendor’s security advisory before you mark a server safe or vulnerable.

Sources: PHP security release, CERT-EU advisory 2026-018. Full technical details are in PHP’s GitHub advisories for CVE-2026-109618 and CVE-2026-109619.

What an external scan can and can’t tell you. An external scan can find PHP-powered sites. It can’t reliably confirm whether they’re patched: servers may hide version headers, and vendors backport fixes. Confirm with an authorized, authenticated vulnerability scan or a package inventory. Don’t send exploit or proof-of-concept requests to production servers.

How to fix PHP2Shell

Update PHP, then restart every PHP worker. That is the only complete fix. Workarounds only reduce specific attack paths.

Why a server compromise puts your website visitors at risk

A shell on your server is also a way into your customers’ browsers. Here is a hypothetical attack chain, not one Wiz reported:

1. An attacker finds a PHP-based store on an unpatched PHP version and gets code execution.
2. They change a template, a bundled JavaScript file, or a database-stored setting, so the checkout page loads one extra script.
3. The script reads the card fields as the customer types, then sends the data to an attacker-controlled domain, disguised as an analytics call.
4. Checkout keeps working, orders complete, and server logs look normal. The theft happens in your customers’ browsers.

This is Magecart-style skimming, introduced through a server compromise: the attacker plants the script from your own server. Memory disclosure opens a second route. A leaked admin token or API key can make the same change with no code execution at all.

The same risk runs through your vendors. If a vendor that serves scripts to your checkout runs unpatched PHP, a breach of its server can push malicious code to your visitors. You can patch your servers. You can’t patch theirs.

Patching closes the door. It doesn’t tell you whether someone already walked through it.

Where Reflectiz helps

Reflectiz doesn’t patch PHP. It shows you what a compromise does in your visitors’ browsers, and it tests how far an attacker could get on your live site.

Security Hub: catch what reaches the browser

Reflectiz Security Hub monitors what runs on your pages in the browser: first-party and third-party scripts, the domains they contact, and which of them touch sensitive inputs. It baselines normal behavior per page and flags deviations.

It is also agentless. A monitoring script added to your pages ships from your own server, so a compromised server can strip or alter it. Reflectiz scans your pages from the outside, in real browsers, so detection doesn’t depend on the server an attacker may control.

In the scenario above, the skimmer has to do three observable things: run on the checkout page, read the card fields, and send data somewhere. If that behavior shows up during the user journeys Reflectiz monitors, Security Hub can flag:

• a new or changed script on the payment page that isn’t in the baseline
• that script reading the card number, expiry, or CVV fields
• data leaving the page for a domain the checkout has never used

Obfuscation alone doesn’t hide a skimmer, because detection is based on behavior, not file hashes or known signatures. The same visibility supports PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 for payment-page scripts.

Offensive Hub: test what a stolen credential can reach

PHP2Shell’s memory disclosure is a reminder that secrets leak. If a session token or admin API key escapes, how far an attacker gets depends on your application: whether sessions expire and rotate, whether authorization runs on every request, and whether one stolen credential opens the whole back office.

Reflectiz Offensive Hub tests that layer. Its AI agents map your live site in a real browser and validate exploitable risks across the OWASP Top 10, including broken access control and authentication failures, with deeper attack chains for login and checkout flows.

What to do this week

1. Patch PHP everywhere and restart the workers. Then rotate secrets that may have sat in worker memory.
2. Ask every vendor that hosts your PHP, or serves scripts to your checkout, whether it has patched.
3. List every script that runs on your checkout and login pages, first-party and third-party, and who approved each one.
4. Map where data typed into those pages goes: which scripts read it, and which domains receive it.
5. Alert on any new script or new data destination on those pages.

Can’t answer 3 and 4 today? Reflectiz shows you what runs on your sensitive pages and where customer data goes.

Sources

• PHP security release, October 21, 2026
• Wiz Research: PHP2Shell
• CERT-EU Security Advisory 2026-018
• Tenable: PHP2Shell FAQ
• Help Net Security: PHP2Shell patched
• BleepingComputer: PHP ships emergency patches