PHP2Shell: two critical PHP flaws that let attackers take over a website with a single request

On Saturday 17 October 2026, one of the traps Amazon spreads across the internet to study attacks (the honeypots of its MadPot network) recorded an unusual request aimed at PHP. Four days later, on 21 October, the PHP team published the patch for two critical flaws that nobody had publicly known about until then. In other words, someone was testing the attack before a fix existed. Amazon admits it does not know how that actor got the information ahead of time.

The two flaws are now known as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Both score 9.2 out of 10 and, under the right conditions, allow code to be run on the server with no username or password. They affect the PHP interpreter itself, not a plugin or a specific content management system: it makes no difference whether the site is WordPress, an online shop or a custom application.

🔍 Suspicious message?

Analyze senders, links or files in real time with our scanner.

Analyze now

Why a flaw in PHP hits so many websites at once

PHP is the language that runs most of the web. According to W3Techs, it is used by 69.3% of sites whose server-side language is known. When the flaw is in the interpreter, all of those sites share the same weak point until their server is updated.

The reach over time is wide too. The Calif team, one of the groups that investigated the flaw, traces the oldest affected code back to PHP 5.4.0. The fixed versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For the 7.4, 8.0 and 8.1 branches the project has only published source-code fixes, with no official releases, and older branches get no fix at all. One important detail: some distributions and hosting panels apply the fix to their own package without changing the version number, so the number alone does not always tell the whole story.

The two flaws, explained

The first (CVE-2026-109618) concerns what happens when PHP runs out of memory in the middle of a request. If that happens while the request's internal data is only half set up, the cleanup that follows treats it as valid. That inconsistent state is the way in.

The second (CVE-2026-109619) is a problem of "leftovers" between requests. Part of one request's state can survive after its memory has been freed, and a later request handled by the same process can end up using it before it is reset. In programming terms, this is a use-after-free.

The consequences depend on how the server is set up. According to the PHP project itself, the highest-risk configuration is Apache with mod_php, where an attack has been shown to fire before the website's own code even runs. With PHP-FPM, one of the attack paths is blocked by the way the process starts, but PHP has still validated code execution through another path under suitable conditions. The researchers also showed that process memory can be read without authentication, and that memory can contain passwords, session tokens and API keys.

Attacked before a patch existed, and at scale afterwards

The timeline explains the urgency. On 20 October the flaw identifiers leaked and PHP published an advance notice; the patch was brought forward by a day because of that leak and was released on the 21st at 14:00 UTC. That same day, from 02:00 UTC, Amazon was already seeing proofs of concept in use, coming from several different anonymisation infrastructures, which points to more than one attacker.

Cloudflare has given figures for the volume: thousands of attempts in the ten hours before publication, tens of thousands in the 45 minutes after, hundreds of thousands within two hours and millions since. It has also seen attackers modify their requests to get around the filters as they are blocked. According to the firm Hadrian, most of the attacks observed use PHP's session upload progress path.

There is one nuance worth keeping: the PHP team says it had not identified any working exploit at the time of release, and Amazon admits it is unclear whether the attempts succeeded. But the volume of attempts and the speed at which they adapt are reason enough to treat the update as immediate. The UK's NCSC has asked organisations to update now or take the server offline until they can.

As a side note, several of the teams credited with the discovery (Calif, Wiz and OpenAI, among others) have explained that they used artificial intelligence models in the research.

What it means if you run a website, and if you just browse

If your website is on shared hosting, the PHP update depends on your provider, not on you. Some providers have already patched or have disabled, at server level, the setting attackers use most, but not all of them are moving at the same pace, and sites still on PHP 8.1 or older are the most exposed.

If you only browse, there is nothing for you to update: the flaw is on servers, not in the browser. The risk to you is indirect. A compromised website can start redirecting to fraudulent pages or offering downloads nobody asked for, and that is more likely these days on poorly maintained sites.

Don't do this:

• Don't assume your hosting provider has already updated PHP. Check or ask.
• Don't install third-party plugins or code snippets that promise to "fix PHP2Shell": the flaw is in the interpreter and can only be fixed by updating it.
• Don't download or run the proofs of concept going around to "test" your site. Many are unverified and may contain malware.
• Don't rely only on a web application firewall (WAF) such as Cloudflare's. It helps while you update, but attackers are already adapting their requests to get past it.
• Don't try to disable the vulnerable setting from .user.ini or with ini_set(): that is not enough. It has to be done in PHP's main configuration.
• If you are browsing: don't accept downloads you didn't ask for or follow unexpected redirects, even on a site you know.

Do this:

• Check your site's PHP version: it should be 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later in its branch. A quick way is to upload a file containing <?php echo PHP_VERSION;, open it in the browser and delete it straight away.
• If the version is older, or if you are on shared hosting, ask your provider whether the PHP2Shell fix is already applied (even if the number has not changed) and whether session.upload_progress.enabled has been disabled at server level.
• If your site is still on PHP 8.1 or older, move to a supported branch. PHP 8.2 stops receiving security fixes on 31 December 2026, so the sensible target is 8.3 or later, testing the site first.
• If you run your own server: update, restart Apache or PHP-FPM and confirm with php -v that the interpreter serving requests is the new one. If you can't update immediately, disable session.upload_progress.enabled in php.ini or in the FPM pool, set fatal_error_backtraces=0 on PHP 8.5, limit upload sizes and restart the processes.
• Review the logs from 17 October, not from the 21st: POST requests containing PHP_SESSION_UPLOAD_PROGRESS, new files in the website folder, scheduled tasks or accounts you don't recognise, and PHP processes launching command shells or downloads.
• If you find signs of an intrusion: isolate the site, keep the logs before touching anything, and change every credential the site stores (database, email, API keys), because this flaw allows server memory to be read.

On a website, the software you can't see is as much a part of its security as the software you install. Nobody chooses the PHP interpreter when they set up a shop or a blog, yet it is what runs every request. This time the first attack attempt came four days before the patch: updating these components is measured not in weeks, but in hours.