PHP2Shell: the PHP flaw affecting millions of websites, explained without jargon, and what to do today

If your website runs on WordPress, WooCommerce, PrestaShop, Joomla, Drupal or any custom-built software, there is almost certainly PHP underneath. On 21 October 2026 the PHP team had to release emergency patches for two critical flaws that let a stranger, with no password and no account, run commands on the server where your website lives. They are being called PHP2Shell.

This guide is written for anyone who owns a website and needs to understand what happened, whether it affects them and what to do today, without being a techie. It is not a line-by-line forensic analysis: it is what you need to know, with the dates and facts checked against the original sources (all listed at the end), plus what we found when reviewing more than 150 websites.

In 30 seconds. These are two PHP flaws (CVE-2026-109618 and CVE-2026-109619), rated 9.2 out of 10, that can be exploited over the internet without logging in. They are already being used. Updating WordPress or your plugins does not fix them: you have to update PHP, and your hosting provider controls that. Ask your provider, or check their panel, which version your site runs and make sure it is a patched one: 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or higher).

What happened, day by day

The pattern is the usual one: attackers don't wait for you to find out. Between a patch being published and the flaw being used against real websites, hours pass, not weeks.

What PHP2Shell is, without jargon

PHP is the engine that runs your website: it receives every visit, does the calculations, queries the database and returns the page. To do that it reserves chunks of memory, uses them and frees them. Both flaws sit in that behind-the-scenes work:

• CVE-2026-109618. If PHP runs out of memory just while it is preparing a request, it leaves the information half-built and, when it tidies up, treats it as if it were complete. An attacker can trigger that situation on purpose and exploit the mess.
• CVE-2026-109619. PHP leaves information from one request pointing at memory it has already freed, and the next request handled by the same process can end up using those leftovers. It is like the next customer being handed a sheet of paper with someone else's details.

Think of a service counter. Someone arrives and hands over a package in a shape the clerk can't process properly; the clerk gets tangled up in their own paperwork, leaves things uncollected, and the next visitor, who knows exactly what happened, gets the clerk to follow their instructions. The visitor needs no membership card and has never been inside before: handing over the package is enough.

What makes it serious is where it happens. According to the PHP project itself, the most dangerous case (Apache with the mod_php module) can be exploited before a single line of your website's code runs. That's why it doesn't matter how well your shop is programmed or how strong your admin password is: the attacker doesn't go through there.

Both flaws score 9.2 out of 10 on the CVSS 4.0 scale. With them, an attacker can run code with the permissions PHP has in your account, or read parts of the server's memory.

Why updating WordPress and plugins doesn't save you

This is what confuses people most. For years the advice has been "keep WordPress, your theme and your plugins up to date", and it is still good advice, but here it isn't enough. The flaw is in the PHP interpreter, a layer below. Security researchers have shown that access to a server can be obtained on specific versions of WordPress, Drupal, Joomla and Magento, and also on MediaWiki, Symfony, Laravel and phpBB. In other words, it doesn't matter which software you use.

A WordPress firewall or a security plugin doesn't fix it either, because those plugins are PHP code running inside the very engine that is affected. Some network services (such as Cloudflare's firewall) have published rules to stop the best-known attempts, but the company itself describes them as a stopgap that only protects the traffic that goes through them.

Who is affected

Any server that serves pages with PHP: Apache with mod_php, PHP-FPM (the most common on shared hosting), php-cgi, LiteSpeed or FrankenPHP. mod_php is the most dangerous scenario, but the rest are not safe. According to researchers, the affected code has existed since PHP 5.4.0, so we are talking about more than a decade of versions.

PHP is behind around 69% of the websites whose server-side language is known. Estimates of exposed servers vary enormously depending on how you count: from 1.3 million (one researcher's specific search) to more than 22 million instances identified by a large security company. Keep the idea, not the figure: it's a lot.

Which versions are fixed

The 7.4, 8.0 and 8.1 branches have gone years without regular security support (7.4 ended in 2022, 8.0 in 2023 and 8.1 at the end of 2025). That makes this episode a good moment to stop putting off a migration you will have to do sooner or later.

How to find out which PHP your site uses

There are three ways, from least to most technical:

1. In your hosting panel. Almost all of them have a "PHP", "PHP version" or "PHP settings" section per domain. Some providers even label each version as safe or unsafe against this flaw.
2. In WordPress. Go to Tools, Site Health, Info, Server: it shows the PHP version your site is actually running on.
3. Ask your hosting provider or whoever maintains your website. It is the quickest way and leaves a written record.

There is a catch. A panel that says "8.3" only tells you the branch, not the exact number, and it is the provider who decides which specific patch to install. Ask them to confirm that the version your site runs includes the fix for CVE-2026-109618 and CVE-2026-109619. And look at the version the website serves, not the one on the server's command line, which may be a different one.

What to do, step by step

1. Take a backup of files and database, and check it can be restored. If you don't have a routine, we have a separate guide on website backups.
2. Find your current version using one of the three ways above.
3. Switch to a patched version. On most hosts it is a dropdown. If you have no reason to choose otherwise, 8.3 or 8.4 is the sweet spot: they are stable, widely supported by plugins and themes and have years of support ahead. 8.5 is the newest and is also fine if your site is up to date.
4. Wait for the change to apply. On some panels it isn't instant: it is requested and applied within a few minutes. After that, the PHP processes must be restarted; updating the package isn't enough if the old ones keep running. Your provider takes care of it, but ask.
5. Test your website. Go through the home page, a form, the customer area and, if you have a shop, a test order. Check the error log. Very old themes and plugins are the usual source of problems when jumping versions.
6. If something breaks, don't go back to a vulnerable version for convenience. Update or replace that plugin; if there is genuinely no short-term alternative, leave the site on a patched branch and fix the specific problem, or ask us for help.

One practical detail: versions 8.4.27 and 8.5.12 have a known bug that can crash some applications using the SimpleXML extension. The fix has been accepted but, as of 26 October, hasn't been released. If it affects you, the simplest way out is the patched 8.3 branch in the meantime.

If you can't update today: partial mitigations

The PHP project itself is clear: no configuration setting fully closes the problem. Only updating is complete. Even so, two measures reduce the risk until the change arrives, as long as your host lets you touch the configuration:

session.upload_progress.enabled = 0
memory_limit = -1

What they do and what they cost:

• Turning off session upload progress closes one of the known routes for the second and third flaws. In exchange, the file-upload progress bars of some (uncommon) applications disappear.
• Removing the memory limit reduces the chance of triggering the first flaw, but it also removes a useful protection against runaway scripts. It is an emergency measure, not a long-term one, and it should go with a server-level memory limit so that a runaway process can't take down the whole machine. If you don't know how, leave it alone and ask for help.
• On PHP 8.5 it is also recommended to set fatal_error_backtraces = 0.
• After changing any of them, the PHP processes must be restarted.

If your website sits behind a protection service such as Cloudflare, keep it, but don't take it as the solution: it only sees the traffic that goes through it.

Have I already been hacked?

The honest answer is that, if your site ran a vulnerable version in these days, you can't rule it out by gut feeling. That said, there is no reason to panic: mass attacks are automatic and most attempts don't succeed. Here is what to look at, from simplest to most technical:

• Changes you didn't make: new pages, strange text, links to pharmacies or casinos, odd redirects when opening the site from your phone or from Google.
• New administrator users you don't recognise.
• .php files in folders where they shouldn't be, especially the uploads folder (wp-content/uploads), with dates from these days.
• Scheduled tasks (cron) you didn't install, or CPU use and outgoing traffic that spike for no reason.
• Warnings from your host or from Google ("this site may be harmful").

If you use WordPress, you can compare the core files against the originals with wp core verify-checksums and run a trusted security scanner. If you find something, the prudent course is to save the logs before touching anything, restore from a clean backup taken before those days, change every password (admin, database, FTP and SSH) and only then update PHP. Updating without cleaning doesn't kick out someone who is already inside.

What not to do

• Don't download "PHP2Shell checkers" from unknown sites. In the first hours, unverified tools and proofs of concept circulated that could contain malicious code. To know whether you are protected you don't need to run anything: the version is enough.
• Don't consider the problem closed because you blocked file uploads or enabled a security plugin. They are useful layers, not the solution.
• Don't think your site is too small. These attacks are automatic: they sweep addresses, not businesses. Nobody cares what you sell; they care about your server.
• Don't buy a service out of fear. The fix costs what it costs to change a dropdown and test your website.

What we saw reviewing more than 150 websites

At 3CWeb we checked, one by one, the real PHP version serving each website across our own projects and our clients' (using a temporary test file that is deleted instantly, to see the version each one actually serves). Here is what we took away, in case it helps you think about yours:

• The PHP version is among the things people look at least on a website. Almost nobody knows which one they have, and almost everybody assumes "it will update itself". It doesn't: on many hosts the version is chosen per domain and stays as it is for years.
• Around four in ten websites were on branches (7.4, 8.0 or 8.1) with no official patched release. It isn't an immediate disaster if the provider applies the minimal patches, but it is a debt worth paying off.
• A small group was genuinely on old versions, with no patch possible. Those are the first to move.
• Before upgrading, what takes the most time is not the change but checking that neither the theme nor the plugins break. That's why it is best done calmly and with a backup, not in a rush.

What is still unknown

Some data is still moving and should be taken with caution:

• There is no reliable figure for how many websites have been compromised. Attempts have been seen on decoy servers and in real traffic, but there is no count. And it pays to be wary of quick attributions: one security firm linked an attack on a European public administration to these flaws and withdrew that two days later because it couldn't confirm it.
• The technical details keep changing. Some sources contradict each other on dates or on which configurations are really exploitable outside mod_php. Until that is clarified, the prudent approach is PHP's own: treat any installation that serves pages as affected.
• The third flaw (CVE-2026-115560) is awaiting a fix in the next regular release. Its risk is considered low and it needs an unusual combination of configuration and code, but it's worth turning off session upload progress if you can.

That is why the medium-term advice is not "patch and forget", but to stop depending on branches that are no longer maintained and to have someone look at this every so often.

How an attacker thinks (and why you don't need to be an interesting target)

Nobody sits down, looks at your website and decides to attack it because they care about your business. With a flaw like this, it's the opposite: someone writes a program that sweeps through IP addresses or domain lists at speed, asks each one the same technical question ("do you respond like a vulnerable PHP version?"), and if the answer is yes, tries the attack automatically. Your website ends up on the list because it has an unlocked door, not because it matters.

That sweep doesn't tell a multinational apart from a corner shop's website: both take the same moment to check. It's the same logic we cover in our guide to basic cybersecurity for small businesses and freelancers: almost no attack is personal, and that's exactly why closing the obvious doors (here, the PHP version) already removes the vast majority of the risk.

Ethical hacking exercise: what a classic attack looks like, in a simulated environment

PHP2Shell is too new, too technical and still has too many unpatched servers out there to teach with a real attack: publishing that step by step would be handing out a weapon, not a lesson. But we can show you, in a simulated environment with no real server behind it, how an attacker reasons about a classic flaw from more than twenty years ago, so you get the underlying logic: never trust what a stranger types into a form.

It's called SQL injection, and it happens when a form builds its question to the database by pasting in whatever the visitor typed, instead of always treating it as a separate piece of data. Here's what that looks like in a poorly protected login:

What just happened:

1. The form builds its query by pasting in the user's text with no protection at all: username = 'admin'--'.
2. The quote the attacker typed closes the value early, and -- turns the rest of the line into a comment as far as the database is concerned.
3. The password check that came after it never runs: nothing is ever compared, and the session opens anyway.

This specific technique has been fixed for decades in any serious software (WordPress, WooCommerce and PrestaShop already protect their own forms), which is why you can see it explained openly with no risk: it isn't a secret, it's one of the first topics in any web development course, and the fix is simple and well known ("prepared statements", which force whatever is typed to always be treated as data, never as part of the instruction). The relevance to PHP2Shell is the idea, not the technique: in both cases, the problem comes from trusting something a stranger wrote without checking it first.

From the defender's side, here's what the warning looks like when your host detects that your PHP version is on the list affected by PHP2Shell:

If you want to practise for real, do it only against your own websites, a test site you build yourself, or platforms made for exactly that (such as TryHackMe or Hack The Box, which are legal because they give explicit permission). Trying any technique, however basic, against a website that isn't yours and without authorisation is a crime, even if you don't succeed; you don't need to succeed to get into legal trouble.

Frequently asked questions

Sources consulted

• Tenable: PHP2Shell frequently asked questions (timeline, versions, mitigations and CISA).
• JFrog Security Research: all you need to know about CVE-2026-109618 and CVE-2026-109619 (technical cause and mitigations).
• watchTowr: PHP2Shell exploited (observed exploitation and how to detect compromises).
• Palo Alto Networks, Unit 42: threat brief (exposure and the 25 October retraction).

This guide was prepared with the information available on 27 October 2026 and we will update it if anything relevant changes.