PHP2Shell: Two Critical PHP Flaws, a Leaked Embargo, and a Race Against the Patch

Kodesec Research | Oct 21, 2026 | 12 min read

Incident Overview#

On 20 October 2026, details of two embargoed vulnerabilities in PHP began circulating online. A post on Hacker News claimed that two remote code execution (RCE) flaws were about to be disclosed. The post was removed, but screenshots had already spread. Security firm watchTowr then confirmed the leak was genuine. Researchers have started calling the pair PHP2Shell.

The PHP security team responded the same evening with an advance notice. It scheduled an emergency security release for Wednesday, 21 October 2026 at 14:00 UTC, which is 8:00 PM in Dhaka. Both flaws are rated CVSS v4.0 9.2. The team said it would publish full details, affected versions and fixed versions together with the release, and that it could ship earlier if details became public or exploitation appeared.

Both triggers PHP named for an early release, public details and signs of exploitation, have now been reported. Cloudflare reported early attacks on the morning of 21 October, and several well-known Dutch sites went offline as a precaution before the patch even existed.

This matters because PHP is not one app. It sits underneath WordPress, WooCommerce, Magento, Drupal, Joomla and Shopware, plus shared hosting platforms, control panels such as cPanel and Plesk, and software that never advertises it runs PHP. W3Techs puts PHP at 69.3% of websites whose server-side language is known. A flaw in PHP core, rather than in one plugin, reaches all of them at once.

Note: This post was written before PHP's 14:00 UTC release, using only the sources listed at the end. The CVE identifiers, the version scope and the technical root cause come from researchers and the leak, not from PHP's own notice. We label claims as claims throughout and will update this post once PHP publishes its advisory.

What Happened: Timeline#

The pace is the story. Compare it with CVE-2024-4577, a separate PHP flaw, where Akamai saw exploit attempts against its honeypots within 24 hours of disclosure. Here the attacks started before the patch was out.

Claims vs. Confirmation#

Fast-moving leaks produce noisy numbers. Cross-checking the sources shows a clear gap between what is claimed and what is confirmed.

The practical conclusion is simple: plan for the worst reading of the scope, and do not rely on any workaround you cannot verify.

Who Is Exposed#

PHP only fixes its currently supported branches. According to the expected version numbers, that means 8.2 through 8.5. Anything older, including 8.1, 8.0, 7.x and 5.x, is end of life and gets no official fix.

That is a large group. Security company Mallory counted about 884,000 internet-facing hosts whose HTTP banner reported PHP 8.1 or older on 20 October. That is 59% of the roughly 1.5 million hosts that reported any version at all. Banners are not proof of an affected system, and a further 740,000 hosts reported PHP without a version. Researcher Silas Cutler gives a rough estimate of over 1.3 million internet-exposed hosts being potentially vulnerable.

You are most at risk if you run:

• End-of-life PHP. Unless your vendor backports a fix, there may be no patch at all.
• Shared hosting and control panels. cPanel and Plesk hosts often run many sites on one PHP build.
• Vendor software that bundles PHP. Appliances and Windows software that ship php.exe or php-cgi.exe are easy to forget.
• RHEL-based servers using Remi's repository. The volunteer-run repository will not publish updates on 21 October.
• Linux web servers with no endpoint detection. This is where PHP flaws get exploited quietly and stay unnoticed.

How You Get Hacked#

PHP has published no technical details, so nobody outside the research community knows the exact trigger. What we can describe, from the sources, is the shape of the attack and what comes after it. We deliberately leave out exploit specifics.

1. Find. Attackers scan the internet for PHP. With well over a million exposed hosts, finding targets is trivial. Sansec expects mass attacks to start within about 15 minutes of the patch release.

2. Send. Researchers describe the flaws as remote code execution that needs no login. The attacker sends a web request to your server. Nobody has to click anything or sign in. Sansec notes that the attack targets PHP itself, before your store code, your plugins or your application-level security tools ever run. That is why a clean plugin list does not protect you.

3. Run. The attacker's commands execute with the web server's rights. In practice this shows up as a PHP worker such as php-fpm, php-cgi, httpd or apache2 launching things it should never launch: a shell, a scripting interpreter, or a download tool. Huntress advises watching for quick reconnaissance commands such as whoami, id and uname -a run straight from the web server.

4. Stay. Once inside, attackers want to keep access. Expect webshells and new files in the web root, new cron jobs or scheduled tasks, and new admin accounts. Huntress describes a recent, unrelated incident that previews the pattern: a PHP FastCGI process repeatedly wrote a small PHP file into the first writable temp directory it found, ran it, then deleted it to cover its tracks.

5. Spread. A foothold on a web server is a stepping stone. Security commentators warn that attackers will use these flaws to launch further attacks and possibly ransomware. The history supports that fear. CISA's Known Exploited Vulnerabilities catalog already lists three PHP flaws, and two of them, CVE-2024-4577 and CVE-2019-11043, have been used in ransomware campaigns.

The costs land in four places: customer data, uptime, control of your own server, and trust. A backdoor planted today can outlive the patch you apply tomorrow, which is why Aikido recommends checking for compromise going back at least to June 2026 after you update.

A word on public exploit code. Proof-of-concept repositories and "scanners" for these CVEs are already appearing on GitHub and Telegram. Tenable has not verified that any of it works, and unverified exploit code is sometimes laced with malware. OX Security's advice is the same: skip them and wait for the official fix.

How to Protect Yourself Right Now#

The fix is not out yet at the time of writing, so the goal is to be ready to patch the minute it lands, and to shrink your exposure until then. Patching PHP is the only real mitigation. Everything below is a stopgap.

Before 14:00 UTC#

1. Inventory every PHP install. Start with web servers, then hunt for the hidden ones: vendor appliances, Windows software bundling PHP, control panels, and anything running WordPress, Drupal, Joomla, Magento or Shopware. Include container images and PHP-FPM behind your ingress.
2. Agree who patches what. Confirm who owns each install and how updates reach production. Patch internet-facing systems first.
3. Ask your host to stand by. If you do not manage your own stack, ask your hosting provider today to apply the update as soon as it is released. Check whether your Linux distribution backports fixes.
4. Fix the Remi problem now. If you install PHP from Remi's repository, switch to your distribution's packages or plan a source build so you are not waiting on a volunteer-run repository.
5. Decide on end-of-life PHP. Upgrade, take it off the internet, or put it behind a VPN or WAF. If you cannot move, ask your provider whether they will backport the fix.

Stopgaps That Reduce Risk#

These do not replace the patch. Use one or more, and test before relying on them.

Take PHP offline if you can. A PHP core developer calls this the most sensible option. Stop PHP-FPM and have your web server return a static maintenance page. The built-in maintenance modes of Magento and WordPress do not help, because PHP still parses every request before the application checks its maintenance flag.

Put the site behind Cloudflare. Cloudflare has deployed WAF rules for the known exploit vectors for all customers, including the free plan. Its CTO calls them a stopgap and is updating them as attackers try new methods. The rules only protect you if your origin server refuses traffic that does not come from Cloudflare, so restrict HTTP and HTTPS to Cloudflare's IP ranges. If you are not on Cloudflare yet, switching nameservers can take hours, so start early.

Block multipart/form-data at the web server. PHP parses file-upload style request bodies before your code runs. Rejecting them means PHP never parses them. This breaks every file upload, so place a test order afterward, because some stores submit cart or checkout forms this way. Remove the rule once you have updated.

# nginx: add to every server block that passes requests to PHP
if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

# Apache: add to every VirtualHost that serves PHP
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

Go read-only. If you cannot go offline, reject every method except GET and HEAD. Customers can still browse, but cannot log in or order.

if ($request_method !~ ^(GET|HEAD)$) {
    return 503;
}

What Not to Rely On#

• session.upload_progress.enabled and session.use_strict_mode. Sansec lists these as extra hardening with no guarantee. PHP developers have said ini settings will not save you, and Aikido reports they do not protect against these flaws.
• memory_limit = -1. Reported as not protective either.
• CMS maintenance mode. PHP still handles the request first.
• Waiting for a WAF or application-level rule. No complete WAF rule exists yet, and the attack lands before application-level tools run.

One hygiene step is harmless if your apps never accept uploads: set file_uploads = Off. OX Security notes it is cheap and shrinks your attack surface, but they do not claim it stops these flaws.

After You Patch#

• Verify the running version. Check the official advisory for the affected-version list, apply the matching fix, then confirm the version that is actually running, not just the one you installed.
• Hunt for compromise. Look for webshells, unexpected or modified PHP files, new admin users, new cron jobs or scheduled tasks, and unusual outbound connections. Aikido suggests looking back to at least June 2026.
• If you find something, isolate the server, preserve web server and PHP logs, and treat credentials on that host as exposed.

How to Spot a Compromised PHP Server#

Because the exploit details are still under wraps, the most reliable detection is behavioral. Alert when a PHP worker launches:

• Shells: sh, bash, cmd.exe, powershell.exe
• Interpreters: python, perl
• Download and network tools: curl, wget, nc, certutil.exe

Also watch command lines for reverse shell patterns such as /dev/tcp/, fsockopen and mkfifo, and for quick recon commands (whoami, id, uname -a, ipconfig) run straight from the web server.

On Linux servers without endpoint detection, Florian Roth's free process-watcher logs every program a PHP process starts, with its command line. Start it in observe mode. Roth is clear about its limits: it sees a program only after it has started and prevents nothing.

How Kodesec Helps#

A PHP core flaw is a stress test for everything around your application: how well you know your estate, how fast you can patch, what you can contain, and whether you would notice an intruder. Kodesec works on each of those links.

1. We find every PHP install. Our cloud security assessment maps PHP across servers, containers and images, including the ones nobody remembered to list.
2. We patch fast and verify. Through DevSecOps and CI/CD pipeline engineering, we rebuild images on patched PHP, roll them out, and confirm the version that is actually running.
3. We contain what cannot be patched. For end-of-life PHP, we design segmentation and isolation so one compromised web server cannot reach your databases, and we plan the migration off unsupported versions.
4. We watch what PHP spawns. Monitoring and observability with SIEM turns "PHP launched a shell" into an alert in minutes rather than a finding in a post-mortem.
5. We hunt for compromise. Our malware investigation work checks for webshells, web root changes, cron jobs and rogue admin accounts, so you know whether anyone got in before you patched.
6. We prepare you for the next one. Incident response playbooks, tabletop simulations and immutable backups mean you contain quickly and never depend on paying anyone.

We also test the surface an attacker sees first. Our web, mobile and API penetration testing covers the same internet-facing PHP applications this flaw targets, including the admin panel, not just the customer-facing pages.

Security is cheapest before the breach. If you want to know where PHP runs in your environment and how exposed it is, book a call and we will scope a test around your platform.

Recommended Checklist for Organisations#

• Inventory every PHP install, including bundled and vendor copies.
• Patch internet-facing systems first, the moment fixes land at 14:00 UTC.
• Treat PHP 8.1 and older as unpatched until a vendor says otherwise.
• Restrict your origin to Cloudflare IPs if you rely on its WAF rules.
• Alert on PHP workers launching shells, interpreters or download tools.
• After patching, verify the running version and hunt for compromise back to June 2026.
• Keep tested incident response plans and immutable, offline backups.

Final Thoughts#

PHP2Shell shows how quickly a leak turns into a live threat. An embargo meant to give defenders a quiet day became a public scramble within hours, with early attacks starting before a patch existed. The unresolved questions are the ones that matter most for planning: which versions are truly affected, how the flaws are triggered, and how many servers are already compromised.

Until PHP publishes the details, the right move is to prepare for the broad reading of the scope, patch fast, protect what you cannot patch, and look for signs that someone got there first.

Note: This analysis is based only on the public sources below. Details such as affected versions, fixed versions and root causes may change when PHP publishes its advisory. It is intended for educational and awareness purposes.

References#

• PHP.net: Upcoming Critical PHP Security Release (advance notice, 20 Oct 2026)
• Huntress: Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities (CVE-2026-109618 and CVE-2026-109619)
• Sansec: Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619
• Cyber Security News: PHP Warns of Two Critical 9.2 Security Vulnerabilities, Urges Users to Prepare for Patches
• Tenable: php2shell (CVE-2026-109618, CVE-2026-109619): Frequently asked questions about critical PHP remote code execution vulnerabilities, 21 Oct 2026
• The Hacker News: PHP2Shell: Two Unpatched Critical PHP RCE Flaws (CVSS 9.2) Trigger Emergency Security Alert, 21 Oct 2026
• The PHP Foundation, advance notice of the upcoming security release, post on X, 21 Oct 2026
• Dane Knecht (Cloudflare CTO), post on X on Cloudflare WAF rules and early attacks, 21 Oct 2026

#php #php2shell #rce #cve-2026-109618 #cve-2026-109619 #vulnerability #patch