PHP2Shell Explained: What Happened, Who’s at Risk and What to Do

PHP2Shell is a pair of critical flaws (CVE-2026-109618 and CVE-2026-109619) in the PHP language itself. They let an attacker run code on a web server without logging in. Both are rated 9.2 out of 10 (CVSS v4.0). Fixes shipped on 21 October 2026.

• Who is affected: every PHP setup that serves web pages, including WordPress, Laravel and custom PHP sites. Updating WordPress or a plugin does not fix it. The PHP runtime underneath must be updated.
• Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no official fix.
• Is it being attacked? Attack attempts are confirmed. A confirmed break-in of a specific server had not been reported in the sources reviewed.

What to do today: check your PHP version, ask your host in writing whether the runtime is patched, and rotate passwords and API keys if you cannot be sure.

What happened with PHP2Shell?

On 20 October 2026, details of two unpatched PHP flaws leaked days before their planned disclosure. The PHP team pulled its release forward and shipped emergency fixes on 21 October at 14:00 UTC, which was 7:30 PM in India. The flaws were found by researchers at Wiz, Calif and OpenAI’s Codex Security team, working with the PHP security team (The Hacker News).

Within hours, security firms reported attackers probing for vulnerable servers. Some organisations took services offline as a precaution while they patched. Here is the sequence, in UTC:

When (UTC)	What happened
17 Oct	Amazon’s honeypot network records an exploitation attempt four days before public disclosure. How the attacker got exploit details is unknown).
20 Oct	Details leak ahead of the planned 22 October disclosure. PHP issues an advance notice that evening and moves the release to 21 October. Around 20:00 UTC, research firm Calif mistakenly posts a video of its working proof of concept.
21 Oct, 03:02	Cloudflare switches on emergency firewall rules by default.
21 Oct, 07:41	Vendor Chainguard publishes container images containing the patch, about six hours before the official release.
21 Oct, 14:00	PHP releases fixed versions (7:30 PM IST).
21 Oct, 14:19	Security firm watchTowr reports active exploitation attempts against both flaws.
21-22 Oct	Precautionary shutdowns reported, including BambooHR and several Dutch government and education systems. The Dutch cyber centre said it had not seen the flaw abused.
22 Oct	Searchlight Cyber releases an open-source scanner. Palo Alto Networks confirms all PAN-OS and Panorama versions are affected and had no fixed release yet. Fortinet and Cisco published advisories and were still checking their products.

What is PHP2Shell, in plain English?

PHP is the programming language that runs the server side of a large share of the web, including every WordPress site. BleepingComputer cites estimates of 75% to 80% of all websites. When PHP handles a visitor’s request, it sets up memory, runs your site’s code, then cleans up.

PHP2Shell is two bugs in that setup and cleanup process:

• CVE-2026-109618: if PHP runs out of memory at the wrong moment, it can be interrupted while its internal data is only half set up. Cleanup then treats the broken data as valid, which attackers can chain into running their own code.
• CVE-2026-109619: leftover internal state can survive after its memory has been freed, and a later request handled by the same worker can use that stale state. This can lead to memory disclosure and code execution.

Two things make this serious. First, the bug is in PHP, not in your website’s code, so even a bare “Hello World” page on a vulnerable version can be attacked. Second, an attacker does not need a login. On Apache servers using mod_php, PHP’s own advisory describes a demonstrated exploit where a single request triggers the attack before any application code runs.

Attackers may also be able to read memory from the PHP worker, which can hold passwords, authentication tokens, API keys and certificates from other visitors’ requests. That is why rotating secrets matters even if you see no damage.

Who is at risk?

Every PHP installation that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest on mod_php. PHP’s analysis supports that PHP-FPM is susceptible too, but one flaw has no complete FPM exploit shown so far, and the other reaches code execution on FPM only through an operation inside the running application (The Hacker News).

Which PHP versions are fixed?

PHP branch	Status	Fixed version
8.5	Supported	8.5.12
8.4	Supported	8.4.27
8.3	Supported	8.3.36
8.2	Supported (reaches end of life 31 Dec 2026)	8.2.35
8.1 and older (including 7.x and 5.x)	End of life: no official fix	None from PHP. Source backports exist for 7.4, 8.0 and 8.1. Otherwise use a vendor backport or upgrade.

A caution on version numbers: Linux distributions and long-term-support vendors received the patches in advance, so a package can carry the fix while showing an older-looking version number. Check the package changelog for the CVE, not just the version string (The Hacker News).

How big is the exposure?

• Qualys, analysing anonymised data from 12,000 customers, found about 71% of PHP installations (roughly 110 million) on end-of-life versions, and only about 28% (44 million) on supported branches awaiting the fix. Only 199,000 were patched in the first 12 hours.
• VirusTotal fingerprinted about 5.1 million internet-facing IP addresses running PHP. Roughly four in five hide their version number. Among the 1.1 million that disclose it, about 758,000 run end-of-life branches (5.4 to 8.1) and about 272,000 run a supported branch. WordPress was the most common application on top, at about 538,000 IPs.

Neither dataset is India-specific, and VirusTotal notes its figures describe the exposed footprint, not confirmed vulnerable servers.

Why this matters for Indian websites (our analysis)

This section is analysis, not a reported finding. We found no India-specific exposure data and no CERT-In advisory on PHP2Shell in our searches, so check cert-in.org.in for updates. But the structure of the Indian web suggests where the risk concentrates:

• Small business, news, education and personal sites on shared hosting. Most run WordPress or WooCommerce. On shared hosting, you often cannot patch PHP yourself. Your host controls the runtime.
• Legacy software. School, college, clinic and local-government sites built years ago on PHP 5 or 7 are the classic long tail. Security researchers quoted by Help Net Security expect forgotten, unmaintained apps to stay vulnerable for a long time.
• Agency-managed sites. If a freelancer or agency built your site, nobody may be watching the PHP version.

Who discovered the PHP2Shell vulnerabilities?

The research involved several people and organizations:

• Wiz Research: The cloud security research team that investigated and disclosed the vulnerabilities.
• Calif: A security research organization that collaborated on the discovery and exploitation work.
• Google DeepMind: Its Gemini 4 Argon model contributed to vulnerability discovery, exploit development, attack detection and patch validation.
• OpenAI: OpenAI Codex Security was also involved in the wider research effort, according to the PHP2Shell project disclosure.

How did they find bugs that had been hidden for years?

The surprising part is that the underlying bugs had existed for more than a decade. What changed was the researchers’ ability to analyze them and demonstrate that they could be exploited.

1. They examined PHP’s internal source code

The researchers investigated how PHP manages memory when a request fails, particularly when it runs out of memory. They identified cases where internal state could become corrupted or remain in use after the memory it referenced had been freed.

2. They used AI to investigate complex behavior

The team used Wiz Atlas, Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol during the research. Gemini 4 Argon made a particularly important contribution to finding the vulnerability, developing exploits, detecting attacks and validating the patch.

3. They tested whether the bugs could actually be exploited

Discovering suspicious code wasn’t enough. The researchers chained multiple memory-handling flaws together and tested whether they could achieve remote code execution without authentication. They demonstrated the impact against WordPress, Drupal and Joomla test deployments.

4. They worked with PHP maintainers to fix the vulnerabilities

Wiz Research coordinated with the PHP team, Calif and OpenAI, while other technology companies helped prepare mitigations. PHP released security fixes on October 21, 2026.

Both vulnerabilities received a CVSS v4.0 severity score of 9.2 out of 10. Under certain conditions, successful exploitation could allow an unauthenticated attacker to execute malicious code on an affected server.

Is PHP2Shell being exploited right now?

Yes, in the sense of attempts. No, as far as the reports reviewed confirm, in the sense of a verified break-in of a named server. Cloudflare reported early attack traffic and said attackers changed their payloads to get around its rules. watchTowr reported active exploitation attempts, and Amazon’s honeypot saw one four days before disclosure. As of The Hacker News update on 21 October, no source had reported a confirmed break-in of a specific server.

That can change quickly, and a lack of reports is not proof that no one was hit. Researchers recommend checking for signs of compromise even on patched servers.

Fact check: what is confirmed and what is circulating online

A viral post bundled real facts with unverified claims. Here is how each stacks up against the sources we could check.

Claim	Status	What the sources show
Two critical PHP flaws rated 9.2	Confirmed	CVE-2026-109618 and CVE-2026-109619, CVSS v4.0 9.2, per PHP and multiple security outlets. A leaked claim of 10.0 was not PHP’s rating.
Details circulated 20 Oct, fixes 21 Oct	Confirmed	Leak on 20 Oct, patches at 14:00 UTC on 21 Oct.
Attackers are trying to exploit it	Confirmed (attempts)	Cloudflare, watchTowr and an Amazon honeypot all reported attempts.
Websites went offline	Confirmed, but precautionary	BambooHR and Dutch government and education systems went offline as a precaution. The Dutch centre said it had not seen abuse.
Hospitals and banks worldwide went dark	Not verified	We found no source tying PHP2Shell to such outages.
Cloudflare’s CEO said attempts jumped to millions	Not verified	Cloudflare’s CTO, Dane Knecht, described early attacks. We found no figure in the reports reviewed.
About 2.6 million PHP servers; 1.1 million on old versions	Does not match	VirusTotal counts about 5.1 million PHP IPs. About 1.1 million disclose a version. Qualys puts end-of-life share at 71%.
PHP runs about 7 in 10 sites	Roughly right	BleepingComputer cites estimates of 75% to 80%.
Patching does not remove a backdoor	True	Researchers advise checking for signs of earlier compromise.
Other incidents in the same post (SBI, Capcom, Onamae, GitLab and others)	Not verified here	The post itself says none has a confirmed link to PHP2Shell. We did not verify them for this article.

What should you do? A step-by-step checklist

If you run a website (WordPress, WooCommerce or custom PHP)

1. Find your PHP version. In WordPress, go to Tools > Site Health > Info > Server. Or look in your hosting control panel (in cPanel, the PHP version selector). Avoid leaving a public phpinfo file on your site.
2. Compare it to the fixed versions. You need 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, or a vendor build that lists the CVE fixes in its changelog. Anything on 8.1 or older has no official fix.
3. Ask your host in writing. On shared hosting you cannot patch PHP yourself. Ask: “Has the PHP runtime on my account been updated for CVE-2026-109618 and CVE-2026-109619?” Switching to a newer PHP version in your control panel only helps if the host has installed a fixed build of that version.
4. Upgrade off end-of-life PHP. If you are on 8.1 or older, move to a supported branch. Test first on a staging copy, because old plugins and themes can break.
5. Put a firewall in front as a stopgap. Cloudflare says its emergency rules are available to all customers, including the free plan. It calls them a stopgap and urges patching. They only help if attackers cannot reach your origin server directly.
6. Rotate secrets if you cannot be sure. Change hosting, database, admin and API passwords, and regenerate WordPress security keys. Because memory can leak, treat unpatched exposure as a reason to rotate.
7. Look for signs of compromise. Researchers suggest watching for unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses, oddly large PHPSESSID cookies, and unexplained PHP worker restarts. Also check for unfamiliar files, admin users and scheduled tasks. Patching does not remove a backdoor already planted.
8. If you cannot fix it quickly, consider taking the site offline. The UK’s NCSC urged organisations to consider this for systems they cannot fix right away. For a small blog this may be unnecessary. For a site handling payments or personal data, it is a real option.

If you cannot patch yet: stopgaps from the PHP team

PHP says these reduce exposure to some attack paths but do not make a server safe. Only updating is a complete fix.

• For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override, keep post_max_size low (8M if you need no uploads, 32M if you do), and use container or cgroup limits as an availability boundary. Do not use RLIMIT_AS or RLIMIT_DATA as a substitute.
• For CVE-2026-109619: set session.upload_progress.enabled=0 and restart every worker. On PHP 8.5, also set fatal_error_backtraces=0. This blocks only confirmed paths, and no setting fully mitigates this flaw.

After updating, review memory_limit and post_max_size. The fix adds a new hard memory limit, and hitting it ends the process without running shutdown handlers.

If you run servers or manage IT for a business

• Update the PHP runtime that serves web requests, then restart Apache, PHP-FPM and any long-running PHP workers. Updating WordPress or Laravel does not update the runtime beneath it.
• Rebuild container images. Take inventory of forgotten apps, appliances and embedded devices.
• Check your vendors. Palo Alto confirmed all PAN-OS and Panorama versions are affected as of 22 October, with no fixed release yet. Fortinet and Cisco were still checking products.
• Searchlight Cyber’s open-source php2shell-scanner can test whether a host is exposed.

Why is PHP2Shell different from other PHP bugs?

• It sits in the runtime, not in an app. Patching your CMS does not help. This is why shared-hosting customers depend on their host.
• AI helped build the exploit. Wiz researchers said the flaws had been present for a long time, but turning them into an exploit took an exceptionally complex chain of steps, and frontier AI models substantially lowered that barrier. The researchers say one person did in about a week what would otherwise have taken a team months. Calif adds that knowing the bug’s history still mattered.
• Disclosure broke down. A leak, an accidentally posted proof-of-concept video and early patched images gave attackers a head start. Amazon saw an attempt four days before disclosure.
• The PHP Foundation admitted a slow fix. It said a core developer found the first signs of the out-of-memory flaw in a 2024 audit, but competing fixes stalled the work. It called the delay a structural failure of its decision process and resources, and says it has changed how it handles security decisions.

The takeaway: the gap between a bug being found and being exploited is shrinking, and “we will patch next month” is a weaker plan than it used to be.

Frequently asked questions

Is my WordPress site hacked because of PHP2Shell?

Not necessarily. No source reviewed confirmed mass compromise. But an unpatched site is exposed, so patch, rotate secrets and check for signs of intrusion.

Do I need to update WordPress or my plugins?

Keep them updated, but that does not fix PHP2Shell. The fix comes from the PHP runtime, which is updated through your host, server packages or container image.

Is PHP 8.1 or 7.4 safe?

No official fix exists for 8.1 and older. Your options are a vendor or distribution backport, building from the published source backports (7.4, 8.0 and 8.1), or upgrading to a supported branch.

Is Cloudflare enough protection?

It helps as a stopgap. Cloudflare itself says to patch, and attackers were already changing payloads to evade its rules.

Does this affect me as an ordinary internet user?

Indirectly. If a site you use is compromised, passwords and tokens stored there could be exposed. Use unique passwords, turn on two-factor authentication, and change your password if a service tells you to.

Did the internet really go into lockdown?

No evidence supports a global shutdown. Some organisations took services offline as a precaution, but we found no verified wave of outages tied to PHP2Shell.

This article is general information, not professional security advice. For business-critical systems, consult your hosting provider or a security professional.