On 21 October 2026, PHP shipped an emergency fix for two critical flaws, nicknamed PHP2Shell, that let an attacker take over a web server with one crafted request. No password, no login, no plugin needed. If your website runs on PHP, which includes WordPress and WooCommerce, update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 today.
Most of the websites you visit run on PHP: WordPress, WooCommerce, Joomla, Drupal, Magento, Laravel apps and countless custom sites. On 21 October 2026 the PHP team released an emergency fix for two flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, now widely called PHP2Shell.
Both allow unauthenticated remote code execution: an attacker can run their own code on your server, then steal data, plant malware or hijack the site. If your business has a website, here is what happened, why it matters, and what to do today.
- Severity of each flaw (CVSS v4.0)
- 9.2/10
- Severity of each flaw (CVSS v4.0)
- of websites with a known server language run PHP
- 69%
- of websites with a known server language run PHP
- internet-exposed servers estimated to be vulnerable
- 1.3M+
- internet-exposed servers estimated to be vulnerable
- between the first exploit attempt and the public fix
- 4 days
- between the first exploit attempt and the public fix
The short version
- What: two critical flaws in the PHP engine, not in a plugin or a theme.
- Impact: an attacker can take over the server with a single crafted web request. No login needed.
- Who is affected: essentially every PHP installation that serves web pages, through PHP-FPM, Apache mod_php, php-cgi, FrankenPHP or LiteSpeed. Apache mod_php is the most exposed. The vulnerable code path goes back to PHP 5.4, released in 2012.
- The fix: upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or apply your Linux vendor's patched package.
- Status: exploitation attempts have already been seen, including one Amazon recorded four days before the flaws were made public.
01
What exactly is broken?
These bugs live in the layer underneath every PHP application. That is why a perfectly coded, fully updated WordPress site can still be vulnerable.
CVE-2026-109618, out-of-memory corruption. When PHP runs out of memory partway through reading an incoming request, the clean-up that follows can treat half-built data as if it were valid. A carefully crafted file-upload style request can trigger it while staying within normal size limits, and on a vulnerable server that corruption becomes a route to running code.
CVE-2026-109619, stale state between visitors. A PHP worker handles many requests one after another. Because of this bug, memory from one request can be freed yet still referenced, so the next request on that worker can reach it. Attackers can trigger it through PHP's session upload-progress feature or, on PHP 8.5, through its fatal-error back-trace feature. Memory can leak too, so secrets held in memory, such as passwords, API keys and tokens, could be exposed.
- 01One crafted requestAn attacker sends a single upload-style web request. No login, no password.
- Bug triggers here02PHP reads the requestThe bug fires here, inside the PHP engine: corrupted memory or stale state from a previous visitor.
- 03Attacker code runsThe server now runs the attacker's commands: steal data, plant malware, hijack the site.
02
How it was found, and how it leaked
PHP credits researchers at Wiz Research, Calif and OpenAI's Codex Security team with finding and reporting the flaws, and Google's Gemini team helped on the fix. Then the timeline got away from everyone.
17 Oct
First exploit attempt
Amazon's MadPot honeypots record a PHP2Shell exploitation attempt, four days before anything is public.
20 Oct
The leak
The CVE numbers surface online early, with a wrong 10.0 score attached, and a video of a working proof of concept is posted by mistake.
21 Oct · 03:02 UTC
Cloudflare switches on firewall rules
On by default for its customers, as a stopgap before any patch exists.
21 Oct · 14:00 UTC
PHP ships the fix
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, brought forward a day because of the leak.
22 Oct
The original release date
The day the fix was meant to come out.
03
Why this matters for the whole internet
PHP is used by about 69% of websites whose server-side language is known, according to W3Techs figures cited by Tenable, and one researcher estimates that over 1.3 million internet-exposed servers could be vulnerable.
The disruption was real. BambooHR took its service offline in the US, Canada and Ireland as a precaution. In the Netherlands, government services including DigiD and MijnOverheid went offline while patches were applied; the Dutch national cyber-security centre said it had not seen the flaw abused and urged everyone to patch. Cloudflare reported attackers changing their payloads to slip past its new rules.
We are seeing early attacks emerging and are updating mitigations as new vectors show up.
04
The fix, by PHP version
| Your PHP branch | Vulnerable if below | Update to |
|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.12 |
| PHP 8.4 | 8.4.27 | 8.4.27 |
| PHP 8.3 | 8.3.36 | 8.3.36 |
| PHP 8.2 | 8.2.35 | 8.2.35 |
| PHP 8.1 and older | All versions | A supported 8.x branch |
If you install PHP from Ubuntu, Debian, Red Hat or a similar vendor, apply your vendor's update. The PHP team also published minimal source backports for 7.4, 8.0 and 8.1, and some hosts ship their own. Treat those as a bridge, not a destination.
05
If you run a business website
- Check your PHP version. You will find it in your hosting control panel (hPanel, cPanel or Plesk) or, on WordPress, under Tools, Site Health, Info, Server.
- Ask your host directly whether your PHP is patched for CVE-2026-109618 and CVE-2026-109619. Most good hosts patched shared servers within hours, but do not assume.
- On PHP 8.1 or older? Switch to 8.4 or 8.5 from your hosting panel, then test the site.
- Change your passwords if your server ran an unpatched version while exposed: hosting, WordPress admin, database, and any payment or email API keys. The memory-leak path means secrets may have been readable.
06
If you manage servers
Inventory every PHP installation, including copies bundled inside appliances and control panels. Patch internet-facing servers first, then restart every PHP worker, because old workers keep running the vulnerable code until they restart. If you cannot patch this hour, PHP's interim mitigations reduce the risk without removing it:
- Set session.upload_progress.enabled = 0 in php.ini, an FPM pool or server configuration. Not in .user.ini or ini_set().
- On PHP 8.5, set fatal_error_backtraces = 0.
- Set memory_limit = -1 at an admin level applications cannot override, keep post_max_size low (8M, or 32M if you need uploads), and cap request sizes at the web server or proxy.
- Do not use RLIMIT_AS or RLIMIT_DATA. They can trigger the vulnerable allocation failure.
New habits for 2026 and beyond
- Patch in hours, not weeks, for critical, internet-facing flaws.
- Do not run end-of-life software. Every PHP version without official updates is a standing liability.
- Layer your defences: a firewall or CDN in front, request-size limits, least-privilege servers and off-server backups you have actually tested.
- Watch behaviour, not just CVE lists. A web server suddenly launching a shell is suspicious whatever the bug is called.
- Know your stack. You cannot patch what you do not know you run.
Sources
Facts current as of 22 October 2026. This is a fast-moving story, so check the PHP advisory for updates.