PHP2Shell: The Critical PHP Flaws Explained

PHP2Shell is the name for two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, that can let an attacker run code on a web server without logging in. PHP fixed them on 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and its release announcements say: “There are no complete mitigations, updating is the only safe choice.” Because the flaws sit in the PHP engine and not in a plugin or theme, any site running on an unpatched PHP version can be exposed, WordPress sites included. This article reflects the situation on 23 October 2026.

In short

• Both flaws are rated 9.2 out of 10 (CVSS v4.0) and can give an attacker code execution with the web server’s privileges, without a login.
• Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older get no official release.
• PHP rates Apache’s mod_php setup as the highest risk, but every PHP installation that serves web requests is in scope.
• Updating WordPress, plugins or themes does not fix it. The PHP version on the server has to be updated, usually by your host.
• Reports on exploitation differ: AWS saw attempts from 17 October and watchTowr reports exploitation since 21 October, while CISA and Rapid7 had not observed exploitation.

What does the PHP vulnerability do?

Both bugs are memory-safety flaws in how PHP handles incoming web requests. PHP2Shell is the name Wiz, one of the research teams that reported them, gave its exploit script and its php2shell.com site. CISA uses the name too.

• CVE-2026-109618 is triggered when PHP runs out of memory in the middle of a request. According to PHP, “out-of-memory handling can interrupt PHP while internal request data is only partially initialized”, and the cleanup that follows treats that half-built data as valid. The GitHub advisory lists crafted multipart requests, the format used for form posts and file uploads, as a way to force that condition.
• CVE-2026-109619 is about leftover state. Internal data from one request can keep pointing at memory that has already been freed, and “a later request handled by the same worker may use that stale state”, according to PHP’s advisory. The GitHub advisory calls it a use-after-free.

In both cases the result can be unauthenticated remote code execution: an outsider sends specially built requests and ends up running their own code on the server, with the same rights as the web server process. From there they can read the database credentials, plant malware or take over the site.

Because the flaws sit in the language runtime and not in a plugin, a theme or the site’s own code, the attack does not depend on what the site does. PHP says the risk is highest for Apache’s mod_php, where a demonstrated exploit triggers the attack before any of the site’s code runs.

Which PHP versions are affected?

PHP’s official records list the four supported branches as affected up to the fixed releases. Older branches get no official fix.

PHP branch	Status on 23 October 2026
8.5	Fixed in 8.5.12
8.4	Fixed in 8.4.27
8.3	Fixed in 8.3.36
8.2	Fixed in 8.2.35. Security support ends 31 December 2026
8.1, 8.0, 7.4	No official release. PHP published source backports only
7.3 and older	End of life. No fix from PHP

Sources differ on how far back the flaws go. The CVE records name only 8.2 to 8.5, the branches PHP still supports. Wiz, Google Cloud and Cloudflare say versions back to PHP 5.4 are affected, and the UK’s NCSC says: “Organisations using any version of PHP are affected.” For a site owner the practical reading is simple: if you are not on one of the four fixed releases, assume you are exposed.

Version numbers can mislead. Some Linux distributions and long-term-support vendors backport the fixes, so a server can report an older version number and still have the patch. PHP and CERT-EU both point this out and advise asking your vendor. Your host can tell you whether its build carries the patch.

Is PHP 7.4 vulnerable?

Yes, in practice. PHP 7.4 reached end of life in 2022, and PHP did not release a fixed 7.4 version. It published minimal source backports for 7.4, 8.0 and 8.1, which a host or a commercial long-term-support vendor can build from, but a plain 7.4 install stays vulnerable. The US agency CISA is the most direct. It tells organisations that cannot patch, or that run PHP 8.1 or earlier, to take those systems offline until they are updated.

How the PHP2Shell disclosure unfolded

The fixes were meant to come out on 22 October under an embargo. They came out a day early because details leaked.

Date (2026, UTC)	What happened
11 Aug	Calif reports the first bug to PHP. Wiz follows on 24 Aug, OpenAI on 18 Sep
17 Oct	AWS sees the earliest exploitation attempt in its honeypot network
20 Oct	The CVE numbers circulate online with a wrong release time and a wrong score of 10.0. PHP pre-announces the release
21 Oct, early morning	Cloudflare switches on firewall rules, including on its free plan
21 Oct, afternoon	PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35
23 Oct	PHP publishes an informational advisory on a third, related issue

The PHP Foundation says the 10.0 score in the leak was wrong; the official score is 9.2. It also says the security company Chainguard broke the embargo by publishing patched images on the morning of 21 October, hours before the release. Chainguard’s chief executive did not dispute the timing but told The Register the company “didn’t leak”. A user who posted the CVE numbers on Hacker News later apologised and said they had not known about the embargo.

Wiz says it used AI models to find and exploit the bugs, and its headline credits AI. The PHP Foundation’s timeline has Calif reporting first, on 11 August, and Calif says its first find needed no special harness or access to models that were not generally available.

Is PHP2Shell being exploited?

Security firms and agencies give different answers.

• AWS saw an exploitation attempt in its honeypots on 17 October, before the public disclosure, and more proof-of-concept attempts on 21 October. It adds that it is “unclear if any of these attempts would have succeeded”.
• watchTowr reports exploitation in the wild since 21 October, based on its own honeypots.
• CISA had not observed exploitation when it published its alert, and neither CVE was in its Known Exploited Vulnerabilities catalogue when we checked on 23 October.
• Rapid7 had not seen exploitation either, and says the public exploits only work on specific combinations of operating system, PHP version and server setup.

Attempts are not the same as successful break-ins. Still, exploit code is public, and the security firm VulnCheck says it has a customer-only exploit that gets past ASLR, a standard memory protection, on x86-64 servers (The Register). Patching now is safer than waiting for confirmed attacks.

The third issue PHP flagged on 23 October

Two days after the release, PHP published an informational advisory about a related bug, CVE-2026-115560, in the session upload progress feature. PHP says it “can only occur under an unusual combination of configuration and application code”: an application has to switch PHP’s session serializer at runtime before starting a session. There is no emergency release for it. PHP is handling it in its regular release cycle and will publish a full advisory with the next release. The mitigation PHP gives is the one it already suggested for CVE-2026-109619: set session.upload_progress.enabled=0 in the server configuration.

What are PHP websites?

A PHP website is one whose pages are generated by PHP code on the server each time someone visits. That covers most of the open-source tools small businesses build on, including WordPress, Drupal, Joomla, Magento and PrestaShop. According to W3Techs, PHP runs 69.3% of websites whose server-side language it can detect. Wiz’s “70% of all websites” drops that qualifier.

If your site runs on one of those systems, it runs on PHP, and the PHP version is set by whoever runs the server. On shared hosting and managed WordPress hosting that is your host, not you. A site that is delivered as pre-built static files, with no PHP running on the server, is not exposed through the site itself. Other software on the same account, such as a hosting control panel, a contact-form script or an old test install, may still run PHP.

What to do now

1. Find out which PHP version your site runs. In WordPress, go to Tools > Site Health > Info and open the Server section (WordPress documentation). Most hosting control panels also show it.
2. Check it against the fixed versions: 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. If your version is older, or you are unsure whether your host has backported the fix, ask the host in writing.
3. If you run your own server, update PHP and restart it. That means the PHP-FPM workers or Apache too, so the old code is no longer in memory. Updating WordPress core or plugins does nothing for this flaw.
4. Move off PHP 8.1 and older. Those branches get no official fix. If a move is not possible this week, CISA says to take such systems offline until they are updated, and the joint EU statement from the Commission, ENISA, CERT-EU, Europol and the EU CSIRTs network says to “consider isolating exposed applications from public networks”.
5. Treat temporary measures as temporary. PHP’s own stopgaps, such as a lower post_max_size or session.upload_progress.enabled=0, “reduce exposure to specific attack paths but do not make an installation safe”. Cloudflare likewise tells customers to patch even with its firewall rules in place.
6. Look for signs of compromise if the site was on an old version over the past week: new admin users, unknown files in the upload folders, changed files you did not edit, or unexpected outgoing traffic. The UK NCSC advises checking systems that could not be updated straight away for evidence of compromise, including backdoors.

This is the kind of work that sits at the core of what a website maintenance plan should include: knowing what runs on your server and keeping it on a supported version. Our own website plans include hosting and maintenance for that reason.

If you think your site was compromised

Code execution on a web server usually means access to whatever the site stores, including customer accounts, orders and contact-form messages. Under the GDPR, a personal data breach has to be reported to your data protection authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it” (Article 33), unless it is unlikely to result in a risk to people. If the risk to customers is high, you also have to tell them. Our GDPR checklist for online shops covers the breach rules in more detail.

Practical first steps: take a copy of the server logs and files before you clean anything, change every password and API key the site uses, and restore from a backup taken before the break-in onto a patched PHP version.

Is PHP safe to use?

Yes, on a supported and patched version. The flaws are serious, but PHP’s security team fixed them in all four supported branches, and the PHP Foundation has said it is strengthening its security process after this release. The bigger risk is sites on PHP 8.1, 7.4 or older that nobody updates. Those versions were already outside security support, and they get no official fix this time either. If you do not know who keeps the PHP version on your server up to date, now is a good moment to find out.