PHP2Shell Explained: Affected PHP Versions and What Website Owners Should Do

PHP2Shell is the name given to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that the PHP project fixed on October 21, 2026. Both can let an unauthenticated attacker run code on a server that uses PHP to answer web requests. The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. If your website runs on PHP, which includes almost every WordPress site, the fix is a patched PHP build on the server, followed by a restart of the PHP workers. Updating WordPress core, themes or plugins does not fix it.

Do this now

1. List every PHP site you are responsible for, including staging copies and old sites on subdomains.
2. Get each one onto a patched PHP build. On shared or managed hosting, ask your host: "Is the PHP build serving my site patched for CVE-2026-109618 and CVE-2026-109619?" On your own server, update the package and restart every PHP worker.
3. Confirm it with the PHP version your website reports, for example in WordPress Site Health, not only the command line.
4. Check for signs of an attack from October 17, 2026, when attack attempts were first seen, not from the day you patched.
5. Change passwords and API keys stored on any internet-facing server that ran unpatched PHP, because the flaws can leak server memory.

The rest of this guide explains each step, who is most at risk, what is known about attacks, and what server administrators need to know.

Who is affected

Any site where PHP answers web requests is potentially affected until its PHP build has the October 21 fixes. The bug is in PHP itself, not in the application, so it does not matter whether you run WordPress, Drupal, Joomla, Magento, Laravel or something custom. Researchers at Calif showed attacks working against default or common installs of all of those and more. Logging in is not required, so login pages do not protect you.

How PHP runs on your server changes how exposed you are:

Older PHP versions are affected too. Researchers trace the vulnerable code back to PHP 5.4, and the PHP project published fixes for the unsupported 7.4, 8.0 and 8.1 branches as source code only, so whether you have them depends on your host or Linux vendor. You may also run PHP without knowing it: the EU's joint statement warns that many products use PHP behind the scenes, such as admin panels on network devices.

Not sure whether your site runs PHP?

• It is WordPress, Drupal, Joomla or Magento. Then it runs PHP. For WordPress, /wp-login.php on your domain usually shows a login page.
• The response headers say so. An X-Powered-By: PHP/8.x header confirms it. Many hosts hide this header, so its absence proves nothing.
• Your hosting control panel has a PHP version selector. Then PHP is available to that site.

As a worked example, we ran these checks on polydraft.ai on October 22, 2026: responses come from Cloudflare with no X-Powered-By header, and /wp-login.php returns 404. That matches how the site is built, as a PolyDraft site with no PHP runtime. For your own site, get a definite answer from your host.

How to get the fix

Who installs the patched PHP depends on how your site is hosted.

Two details catch people out. First, restart every PHP worker after updating, or the old version keeps serving requests. Second, Linux distributions often add the fix without changing the version number, so a patched server can still report something like 8.3.6. In that case, check your vendor's security notice for the two CVE numbers rather than the version string.

If you run WordPress, our step-by-step guide on how to update PHP in WordPress covers checking the version, backups, plugin compatibility and the common host control panels.

Is it being exploited?

Attackers were trying before the fix was public. AWS reported attack attempts against its honeypots (decoy servers set up to attract attacks) from October 17, four days before disclosure, and watchTowr, Cloudflare and Datadog reported scanning and attack traffic after release. The US cybersecurity agency CISA said on October 21 that it had not yet observed exploitation, and the flaws were not on its list of known exploited vulnerabilities. Attempts against decoys are not proof that real sites were broken into, but they are reason enough to patch now and to look for signs of an attack from October 17.

If you cannot patch today

Patching is the only complete fix. Until you can:

• Take the site off the public internet if you can, as CISA suggests, or put staging and admin-only sites behind a VPN or IP allowlist.
• Use a web application firewall. Cloudflare added protection for these flaws on October 21, including on its free plan, and Akamai added a rule for its customers. Both say this does not replace the patch.
• Ask your server administrator to apply the interim settings from the PHP advisory, listed in the section below.

For server administrators: packages, interim settings and detection

Patched distribution packages

Package versions keep moving, so confirm against the linked notices.

Distribution	Patched package	Notice
Debian 12 (bookworm)	php8.2 8.2.35-1~deb12u1	DLA-4848-1
Debian 13 (trixie)	php8.4 8.4.27-1~deb13u1	DSA-6574-1
Ubuntu	Updated php8.1, php8.3 and php8.5 packages	USN-8948-1, USN-8948-2
Red Hat Enterprise Linux 10	php-8.3.36-1.el10_2	RHSA-2026:87070
AlmaLinux 8, 9 and 10	Patched PHP packages	AlmaLinux blog, October 21

Restart every PHP worker after updating, rebuild container images, and verify the version through the web server SAPI (for example a temporary phpinfo() page), because the CLI binary can differ.

Interim settings from the PHP advisories

• CVE-2026-109618: set memory_limit=-1 at the administrator level (for example php_admin_value) so applications cannot override it, and limit decoded request body size at the front end and with container memory limits. Do not use RLIMIT_AS or RLIMIT_DATA instead.
• CVE-2026-109619: set session.upload_progress.enabled=0, and on PHP 8.5 also fatal_error_backtraces=0. Load these before request parsing and restart workers.
• WAF: Cloudflare's managed rules have been active since 03:02 UTC on October 21; Akamai App & API Protector uses rule 3000991.

Datadog notes that configuration mitigations "don't fully protect you." Treat them as a bridge to the patch.

What to look for, from October 17

• A PHP or web server worker that launched a shell such as sh or bash. This is the most direct sign of compromise.
• Unusually large form submissions, such as a single field name of several megabytes, or control characters in form values.
• Out-of-memory errors that report Unknown on line 0, and segmentation faults in web server logs.
• Unexpected admin users, changed files in the web root, new scheduled tasks and unusual outbound connections.

Background: what PHP2Shell is and how it was found

The two flaws, in plain terms

• CVE-2026-109618: when PHP runs out of memory while reading a request, it can stop with that data only half set up. Cleanup code then treats the half-built data as valid, which an attacker can steer toward running their own code.
• CVE-2026-109619: a PHP worker can keep references to memory that belonged to an earlier request after that memory is freed, and the next request can use them. One route runs through session upload progress, a feature that is on by default.

Researchers also showed that the flaws can leak server memory, which may include passwords and keys. That is why the checklist includes changing them.

Why you see different severity scores

The PHP security team's official rating is CVSS 9.2 (on the v4.0 scale), and that is the number to use in reports. The US National Vulnerability Database scores the same flaws 9.8 on the older v3.1 scale, and Red Hat rates its own packages 8.1 because its default setup is harder to attack. The 10.0 you may have seen came from posts that leaked the CVE numbers before release, and it is wrong.

Timeline

The underlying weaknesses are old: the PHP Foundation traces related memory-limit problems to research from 2004, a 2020 bug report and a 2024 security audit that noticed the behaviour but did not prove it could be exploited. In 2026, researchers using AI-assisted tools turned them into a working attack.

• August 5: researcher @lcfr_hax posts a timestamp of a finding on X. Calif later credits them as the first to discover PHP2Shell and build a working exploit.
• August 11: Calif and OpenAI report the issues to PHP independently. Wiz and others later add more attack paths.
• October 17: AWS sees the first attack attempts against its honeypots.
• October 20: the CVE numbers leak online. The PHP Foundation announces the release for the next day.
• October 21, 14:00 UTC: PHP publishes the fixes. CISA issues an alert, and EU agencies including ENISA and CERT-EU publish a joint statement.
• October 21–22: Linux distributions ship patched packages and hosts publish their patch status.

PHP2Shell is not wp2shell

Search results often mix PHP2Shell up with wp2shell, a different flaw that needs a different fix. wp2shell (CVE-2026-63030, chained with CVE-2026-60137) was in WordPress core, was fixed in WordPress 6.9.5 and 7.0.2 on July 17, 2026 (6.8.6 for the 6.8 branch), and is on CISA's list of known exploited vulnerabilities. You fix it by updating WordPress. A WordPress site needs both fixes.

Other PHP vulnerabilities from the same period

Patching PHP does not cover flaws in the applications that run on it. If you run an online store, check these too:

What PHP2Shell says about website maintenance

Runtimes of every language get bugs. Two lessons from this one matter for a business website. The first is responsibility: a self-hosted PHP site depends on a chain of the PHP runtime, the web server, the CMS, its plugins and theme, and whoever is supposed to update each one. The second is speed: AI-assisted research turned weaknesses known for years into a working attack, and attempts began before the fix was public. Expect that to happen again, with patch deadlines measured in hours.

For many small businesses, the honest answer to "who patches this?" is "nobody in particular." If that describes your site, this is a good week to decide whether to keep operating that stack or move to a setup with fewer moving parts. Our guide to WordPress alternatives compares the options by who maintains what, and the website redesign SEO checklist keeps your rankings intact if you move.

PolyDraft is one of those options. It builds a server-rendered Astro site that you deploy into your own Cloudflare account, so there is no PHP runtime or plugin stack for you to patch, and nothing publishes without a person approving it. That is a smaller maintenance surface, not a promise of zero vulnerabilities: every platform has dependencies, and our security page lists what we do and do not claim. PolyDraft does not import or sync a WordPress backend. It rebuilds the public site from its URL, as described on WordPress to Astro.

Frequently asked questions

Does updating WordPress fix PHP2Shell?

No. WordPress core, themes and plugins run on top of PHP. The fix is a patched PHP build on the server, installed by your host or server administrator, followed by a restart of the PHP workers.

My site shows a PHP version below the fixed release. Am I vulnerable?

Not necessarily. Linux distributions often add security fixes without changing the version number. Ask your host, or check the vendor's notice for CVE-2026-109618 and CVE-2026-109619.

Was PHP2Shell exploited before the patch?

Attack attempts against AWS honeypots started on October 17, 2026, four days before disclosure. CISA said on October 21 that it had not yet observed exploitation. Check your logs from October 17.

Is the severity 9.2, 9.8 or 10.0?

The official rating from the PHP security team is CVSS 9.2. NVD's 9.8 uses an older scale, and the 10.0 from leaked pre-release posts is wrong.

Is PHP2Shell the same as wp2shell?

No. wp2shell is a WordPress core flaw fixed by updating WordPress. PHP2Shell is in PHP and is fixed by a patched PHP build. A WordPress site needs both fixes.

Do static or JavaScript sites need to do anything?

Not for PHP2Shell itself, unless PHP runs somewhere in the stack, for example a PHP contact-form handler or an old admin tool on a subdomain. Check before you assume.

Continue with the next task

• Patch a WordPress site step by step: How to update PHP in WordPress
• Compare platforms by who maintains what: WordPress alternatives for business websites
• Move platforms without losing rankings: Website redesign SEO checklist

About this article. First published on October 22, 2026, the day after the PHP security release, and updated the same day with the disclosure timeline, attack reports, distribution packages and related vulnerabilities. It draws on the official advisories, CISA, distribution notices, vendor research and the researchers' own posts on X, listed below. Attack and host patch status were changing hourly, so check the sources for the latest. We are a website platform, not a security vendor: the technical details come from the PHP project and the researchers cited, we did not test exploits ourselves, and we do not reproduce exploit steps. Drafted by an AI agent from the sources below, then checked against them and approved for publication by Vincent Chen. The illustrations are original diagrams made for this article.

Sources

Accessed October 22, 2026.

Official advisories and agencies

• PHP: PHP security releases announcement, October 21, 2026
• PHP security advisories: GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• The PHP Foundation: Today's PHP security release and how we're strengthening PHP security
• NVD: CVE-2026-109618 and CVE-2026-109619
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching and the Known Exploited Vulnerabilities catalog
• ENISA: Joint statement on critical PHP vulnerabilities

Research and security vendors

• Calif: php2shell: A tale of two PHP remote vulnerabilities
• Wiz: PHP2Shell: AI uncovers critical RCE vulnerabilities
• Datadog Security Labs: PHP2Shell: detection, analysis and remediation
• AWS Security Blog: Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure
• watchTowr: PHP RCE FAQ: PHP2Shell
• Cloudflare: WAF protection for the PHP vulnerabilities
• Akamai: Critical remote code execution vulnerabilities in PHP core
• Tenable: PHP2Shell frequently asked questions

Distributions

• Debian: security tracker for CVE-2026-109618
• Ubuntu: CVE-2026-109618 and USN-8948-1
• Red Hat: CVE-2026-109618 and RHSA-2026:87070
• AlmaLinux: Patched PHP packages released

Related advisories

• WordPress: WordPress 7.0.2 release
• Rapid7: CVE-2026-63030: wp2shell (CISA KEV listing, July 21, 2026)
• Adobe: APSB26-146, APSB26-153 and APSB26-92
• Sansec: BlockStrap Magento RCE
• Composer: GHSA-96h3-5x6v-m776 (CVE-2026-59944)

Posts on X

• The PHP Foundation: security release pre-announcement
• Calif: discovery credit to @lcfr_hax
• @lcfr_hax: August 5 timestamp post