By a software engineer at Ureka Technologies

PHP2Shell is a pair of critical bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619, patched on 21 October 2026. Both are rated 9.2 out of 10 and let an attacker run code on a web server without logging in. If anything you own runs on PHP, update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 today and restart the server.

I'm a software engineer, and this is the advice I'd give any business owner or IT team this week. Below: what PHP2Shell is in plain English, why it matters more than the usual security headline, and a 24-hour plan for each side of the table.

Key takeaways

  • Every PHP version from 5.4 to 8.5.11 is affected, on every common server setup.

  • Updating WordPress, Laravel or plugins does not fix it. PHP itself must be updated and restarted.

  • Exploit code is public and attacks started within a day.

  • Business owners: get written confirmation from your host or developer. IT teams: inventory, patch, restart, verify, rotate secrets.

  • PHP 7.4, 8.0 and 8.1 have no official fix. This is the push to finally upgrade.

What is PHP2Shell, in plain English?

PHP2Shell is the nickname for two memory bugs deep inside PHP, the language that runs WordPress, WooCommerce, Magento, Laravel and a huge share of the web.

  • CVE-2026-109618: if PHP runs out of memory at the wrong moment, it can treat half- built request data as valid.

  • CVE-2026-109619: some request data stays in use after its memory has been freed.

The result in both cases is remote code execution: an outsider can run commands on your server as if they were sitting at it. An attacker can also read leftover memory, which may hold passwords, login tokens and API keys from other visitors (Google Cloud, 21 Oct 2026).

Here is the part I explain to every client: the bug is in PHP, below your application. Your own code can be clean and well tested, and the server is still exposed.

Why is PHP2Shell such a big deal?

Because four things lined up at once, and as an engineer, that combination is what makes me move fast.

1. It hits almost everything. PHP 5.4 through 8.5.11, on PHP-FPM, Apache mod _php, php- cgi, LiteSpeed and FrankenPHP (The Hacker News, 21 Oct 2026).

2. It leaked early. Details went public a day before the planned release, so PHP rushed the patch out on 21 October.

3. Exploit code is public. Sophos saw multiple attack attempts and one successful break- in (Sophos, 22 Oct 2026).

4. Big organisations took it seriously. Some services, including government sites in the Netherlands, went offline as a precaution while they patched.

There is also a twist that got the industry talking: researchers from Wiz, Calif and OpenAI used AI tools to turn a flaw that had sat in PHP for over a decade into a working attack. Expect more old bugs to surface this way.

Which PHP versions are affected by PHP2Shell?

Every release from 5.4 to 8.5.11 is affected. Apache with mod_php (PHP loaded directly inside Apache) is the riskiest setup, because one request can trigger the attack before your code even runs.

Your PHP

version

Status

What to install

8.5.0 to 8.5.11

Vulnerable

8.5.12

8.4.0 to 8.4.26

Vulnerable

8.4.27

8.3.0 to 8.3.35

Vulnerable

8.3.36

8.2.0 to 8.2.34

Vulnerable

8.2.35, then plan a move (support ends 31

Dec 2026)

8.1, 8.0, 7.4

Vulnerable, no official

release

A vendor-patched build, or upgrade to

8.3/8.4

7.3 and older

Vulnerable, unsupported

Upgrade

Watch out for this trap: hosts and Linux vendors often patch PHP without changing the version number. Plesk, for example, shipped fixed 7.4, 8.0 and 8.1 builds that look unchanged (Plesk, 21 Oct 2026). Always confirm by CVE number, never by version string alone.

What should a business owner do about PHP2Shell today?

You don't need to touch a server. You need one written answer from whoever runs your website. If you take one thing from this post, send this message today:

"Hi, please confirm in writing that the PHP version running our website includes the fixes for CVE-2026-109618 and CVE-2026-109619 (PHP2Shell), and that the PHP services were restarted after the update. Please also tell me which PHP version we are on."

Then:

1. Know who owns your server. Shared or managed hosting: your host patches PHP. AVPS or cloud server (AWS, Azure, Google Cloud, DigitalOcean): your developer or IT company does.

2. Don't accept "we updated WordPress" as the answer. That changes your site's files, not PHP.

3. Ask about old versions. If you hear 7.4, 8.0 or 8.1, ask for a written upgrade plan with a date.

4. Change your important passwords once the patch is confirmed: admin logins, email, and any payment or API keys your site uses.

5. Ask for a quick log check if the site stayed unpatched for days.

What should an IT company or agency do about PHP2Shell?

Treat it as an incident, not a ticket. Here is the 24-hour plan I'd run across a client fleet.

Window

Action

Done when

Hour 0–2

Inventory every server, container image

and panel running PHP, including staging

and forgotten client sites

You have one list with owner and

PHP version

Hour 0–2

Turn on WAF rules (a web application

firewall filters bad requests) as a stopgap

Rules active on public sites

Hour 2–8

Patch internet-facing, mod

_php and

payment-handling servers first

Changelog shows both CVEs

Hour 2–8

Restart Apache, PHP-FPM, LiteSpeed

and every long-running worker

Process start times are after the

patch

Hour 2–8

Rebuild Docker images from patched

base images; patch control panels' own

PHP (Plesk, cPanel) separately

No old images still deployed

Hour 8–

24

Check memory_limit and

post_max_size; the fix adds a hard

memory limit that can kill heavy jobs

Imports, exports and cron jobs

pass

Hour 8–

24

Hunt for compromise and rotate secrets

on servers exposed for days

Keys, DB and SMTP passwords

changed

Hour 8–

24

Email every client: what you patched,

when, and what's left

Written record sent

One habit worth keeping after this week: check process start times, not just package versions. The most common miss is a server marked "patched" that still runs the old PHP because nobody restarted the workers.

Can you protect a server without updating PHP?

Not fully. The PHP team is clear that updating is the only complete fix. Turning off session.upload_progress.enabled blocks one path for CVE-2026-109619 only. Limiting request size at the web server and running a WAF narrow the attack, and Cloudflare itself called its rules a stopgap. Use these to buy hours, not weeks.

How do you know if a server was already hacked?

Check logs from before the patch for these signs:

  • odd upload-style requests followed by memory-limit errors or bursts of "500" errors

  • unusually large PHPSESSID cookies (PHP's session cookie) in responses

  • PHP workers restarting with no clear cause

  • on WordPress: admin users nobody created, unknown plugins, PHP files in the uploads folder

Found something? Preserve a copy for evidence, restore from a clean backup taken before 20 October, and rotate every credential. A patch closes the door; it doesn't remove anyone already inside.

My take as an engineer: what PHP2Shell should change

PHP2Shell will be patched within weeks. The habits it exposes will not fix themselves.

  • Keep a live inventory. Most teams lose the first hours just finding where PHP runs.

  • Stop running end-of-life PHP. 7.4 and 8.0 left you depending on someone else's goodwill this week.

  • Make patching boring. A monthly patch-and-restart routine turns the next emergency into a routine job.

This is the kind of work we do at Ureka Technologies: keeping client sites on supported stacks and rebuilding the ones that can't be saved. If an old PHP site is holding you back, our website development cost guide shows what a rebuild costs.

What to do next

Send the message above to your host or developer today. If you run servers yourself, start the 24-hour plan now and keep the table as your checklist. To see how we build and maintain sites, read about our website development service.

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, patched on 21 October 2026. Both are rated 9.2 and let an attacker run code on a web server without logging in, and can leak data from server memory. They affect PHP 5.4 through 8.5.11, so nearly every PHP website stays exposed until PHP is updated and restarted.

Which PHP version fixes PHP2Shell?

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Versions 7.4, 8.0 and 8.1 have no official release, though some hosts and Linux vendors ship patched builds that keep the old version number. Because the number alone can mislead, confirm the fix by the two CVE numbers in your package changelog or in writing from your host.

Does updating WordPress fix PHP2Shell?

No. WordPress, theme and plugin updates change your website's files, while PHP2Shell is in the PHP runtime on the server. Your host or IT team has to update PHP and then restart Apache, PHP-FPM or LiteSpeed. Until both happen, a fully updated WordPress site on an old PHP build is still open to attack.

Is PHP2Shell being exploited in the wild?

Yes. Working exploit code went public around the release date, and security firms reported attack attempts within a day. Sophos reported at least one successful break-in, and some organisations took services offline as a precaution. Treat any unpatched, internet-facing PHP server as a target and patch it the same day.

What should an IT company do first about PHP2Shell?

Start with an inventory of every server, container and control panel running PHP, then patch internet-facing and payment- handling systems first. Restart all PHP services, rebuild container images, and confirm process start times are after the patch. Finish by checking logs, rotating secrets on long-exposed servers, and sending each client a written record of what was done.