PHP2Shell Flaw: Check Your Website This Week

Since 21 October 2026, two flaws in PHP itself, together called PHP2Shell, let an attacker run commands on a web server with no login at all. The fixes are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35; PHP 8.1 and older get no official release. Ask your hosting provider or developer today which PHP version serves each of your sites, and whether the fix is in.

PHP is the programming language behind most business websites. W3Techs counts it on 69.2% of websites whose server-side language is known, as of 27 October 2026. If your company profile runs on WordPress, your hotel has a booking page, an internal admin app was built with Laravel or CodeIgniter, or your payment provider sends notifications to a small script on your server, PHP is in the picture, whether or not anyone wrote it down.

Why does updating WordPress not help this time?

The hole is in the engine, not in WordPress, the theme, or the plugins. Alfons Tanujaya of Vaksincom made exactly this point to detikInet on 22 October: many site owners assume they are safe because WordPress and its plugins are current, while the flaw sits in the server's PHP. CISA, the US cyber agency, says the same in its alert: every PHP installation serving web requests is affected, whatever runs on top of it.

It gets worse. The attack happens before your application's code runs. The PHP security team rates the risk highest for Apache with mod_php, the setup where PHP runs inside the web server itself, because one request from a stranger can trigger the attack before a single line of your site's own code has executed.

What happened, and when?

The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619. A CVE is the public ID number the security industry gives each flaw; most scanners and patch dashboards key on it. The first row of the table is the one to remember: someone was already trying this four days before the public knew, so any review of your servers should look back to at least 17 October.

How does a flaw in PHP itself become a way in?

Picture PHP as a service counter with several clerks. Each clerk is a "worker": it takes one visitor's request, clears and sets up the desk, does the job, then tidies up for the next visitor. The two flaws break that routine in two different places.

The first, CVE-2026-109618, is about running out of desk space. If the clerk runs out of memory halfway through setting up, PHP abandons the job abruptly and jumps straight to the tidy-up, which assumes the desk was fully set up. Half-filled forms get read as if they were complete. An attacker can cause that shortage on purpose with a specially shaped form upload that stays within the server's normal limits. The PHP team confirmed full remote code execution, meaning the attacker's own commands run on your server, over plain HTTP against Apache with mod_php on default settings.

The second, CVE-2026-109619, is about notes left on the desk. A clerk can keep references to the previous visitor's paperwork after that paperwork has been shredded. A few operations run before the desk is reset and act on those stale notes: the session upload-progress feature, the backtrace PHP 8.5 produces on fatal errors, and warnings about bad settings in .htaccess files. Two crafted requests that land on the same clerk are enough. More clerks lower the odds per request but do not remove the condition.

In both cases the commands run as the web server's own account. That account can read your application's configuration: the database password, the .env file holding your payment provider's server key, the email account. From there, planting a web shell, a hidden page that runs any command sent to it, is routine. The Nextcloud add-on case from earlier this month shows what that cleanup looks like.

Which version are you on, and is there a fix for it?

Sources: PHP's supported versions and end-of-life pages, and the watchTowr FAQ on unsupported branches.

The bottom two rows are not a corner case. W3Techs' figures for 27 October 2026 put 7.7% of PHP sites on PHP 5 and 26.6% on PHP 7, with 73.4% of the PHP 7 sites on 7.4. Among PHP 8 sites, 5.7% run 8.0 and 14.9% run 8.1. Add those up (my arithmetic, not W3Techs') and roughly 48% of PHP sites sit on a branch the PHP project no longer fixes. Pratama Persadha of CISSReC cited Censys data to Bisnis showing about 1.5 million of 2.6 million internet-facing PHP hosts unpatched on the day of the announcement. Ardi Sutedja of the Indonesia Cyber Security Forum estimated, in the same article, that tens of thousands to hundreds of thousands of Indonesian websites are exposed. Treat that as an estimate, not a count.

Two traps when you check. First, a backported fix keeps the old version number: cPanel's ea-php81 still reports 8.1.x after the 21 October update, and Debian or Ubuntu packages behave the same way. The proof is a changelog line naming the CVE, not the version string. Second, the command-line php -v can differ from the PHP that actually serves your website, as Komdigi's notice and detikInet's update guide both point out.

What should you check this week?

Most small businesses rent space on a shared or managed server, so the host does the patching. That does not remove your job; it changes it to verification.

If your site is on shared or managed hosting:

1. Find the branch. In cPanel it is under MultiPHP Manager or Select PHP Version; other panels have an equivalent. Write down the branch for every site and subdomain, not just the main one.
2. Ask the host three questions. Which PHP version serves my site? Is the fix for CVE-2026-109618 and CVE-2026-109619 applied, and how can you show it, especially on 7.4, 8.0 or 8.1 where the number does not change? When were Apache, PHP-FPM or the LiteSpeed PHP processes restarted after the update? A patched file does nothing until the workers restart.
3. If the panel only offers 7.x, 8.0 or 8.1 and the host cannot show a backport, switch the site to 8.2 or newer after testing it on a staging copy, a test copy of the site, or move to a host that can answer the questions.

If you run your own server, VPS or containers:

1. Check what is really running. php-fpm -v and apachectl -M tell you more than php -v. Then search the package changelog for the CVE.
2. Update and restart every worker. For containers, rebuild the image on a fixed base; restarting a container does not replace the binary inside it, as ProjectDiscovery notes.
3. Catch old binaries still in memory. A process that started before the update keeps running the old code even after the file on disk changed.
4. Apply the interim settings anyway. PHP's advisory lists session.upload_progress.enabled=0, and on 8.5 fatal_error_backtraces=0, plus a small post_max_size and blocking multipart uploads, the form posts that carry files, on endpoints that never take files. PHP's own words: there are no complete mitigations, updating is the only safe choice. A firewall such as Cloudflare's buys hours, not safety.
5. Look back to 17 October. New or modified PHP files in the web root, web-shell patterns, PHP workers spawning a shell, unexpected outbound connections, new CMS admin accounts. If a server was reachable from the internet while unpatched, rotate its database passwords, API keys and session signing keys, even if you find nothing.

# What is serving the web, not just the CLI
php-fpm -v; php -v; apachectl -M 2>/dev/null | grep -i php

# Proof of the fix on Debian/Ubuntu and RHEL-family (backports keep the old number)
apt changelog php8.3-fpm 2>/dev/null | grep -m1 CVE-2026-109618
rpm -q --changelog ea-php81-php-cli 2>/dev/null | grep -m1 CVE-2026-109618

# Workers still running a replaced binary
grep -l '(deleted)' /proc/[0-9]*/maps 2>/dev/null | head

# Post-patch review, from 17 October onwards
find /var/www -type f -name '*.php' -newermt '2026-10-17'
grep -rlE 'eval\(|base64_decode\(|shell_exec\(|passthru\(' /var/www

The review commands follow SecureLayer7's checklist and CISA's advice to watch for PHP processes launching shells. One caution: if your access logs rotate weekly, a clean log search for the week of 17 October proves very little by now.

Where does this bite hotels, payments and old internal apps?

A hotel booking page or a web portal in front of the property system is exactly the kind of internet-facing PHP that goes first. The same goes for the small endpoint that receives payment notifications: it usually holds the provider's server key in .env, and an attacker with code execution reads that file in seconds. If such a server sat unpatched on the internet after 17 October, rotate the provider keys as part of the cleanup, not as an afterthought.

Older internal apps are the harder case. A CodeIgniter 3 or Laravel 5 application on PHP 7.4 cannot jump to 8.3 in a week; the code will break in a dozen places. What you can do this week is take the distribution or cPanel backport, put the app behind a VPN so it is no longer reachable from the internet, and then plan the upgrade in stages. The legacy rescue article describes that order: stabilize first, then rebuild.

The layer underneath that nobody lists

PHP is not in your composer.json, so dependency scanners do not see it. Snyk says plainly that its open-source scanner will not report these CVEs because the runtime is not a declared dependency, and that container scans miss the official php: images because PHP is compiled from source there. The inventory you need is simpler and more boring: for each site, which PHP branch, who updates it, and how you verify. Put PHP 8.2's end of life on 31 December 2026, nine weeks from now, in the same list.

The other lesson is about timing. Cloudflare had rules live hours before the release; Amazon saw an attempt four days before it. A patch policy that waits for the CVE number, or for the monthly maintenance window, no longer matches how these weeks go.

If a vendor or IT provider runs your sites, ask them three things this week: which PHP branch serves each site, how they can prove the fix is in, and whether they restarted the workers and reviewed logs since 17 October. A provider who answers within a day is managing your servers. One who cannot is only hosting them. If part of your stack is an old PHP app that nobody dares to touch, I am happy to spend a free 15-minute first call on what a staged upgrade would involve.