PHP2Shell: why a single PHP flaw puts almost every website at risk

On 21 October, the PHP team released fixes for two critical vulnerabilities that attackers had started exploiting before they were even announced. Here’s what PHP2Shell is, which websites it affects and what to do about it today.

9.2CVSS v4.0 score, both flaws

0logins an attacker needs

5.4+oldest affected PHP version

1.3M+potentially vulnerable servers

Most website security news is about a specific plugin or platform: you update one component and the problem is gone. PHP2Shell is different. The flaws are in PHP itself – the programming language that powers WordPress, Joomla, Drupal, Magento, PrestaShop, Laravel and most other website systems. According to W3Techs, PHP runs almost 70% of websites whose server-side language is known.

So this time the question isn’t “am I using a vulnerable plugin?” but “which PHP version serves my website, and has it been patched?”

What is PHP2Shell?

PHP2Shell is the name researchers gave to a chain of two vulnerabilities: CVE-2026-109618 and CVE-2026-109619. The PHP security team rated both 9.2 on the CVSS v4.0 scale. The 10.0 score that initially circulated online was incorrect, but 9.2 still means critical.

The name describes the outcome. Through PHP, an attacker gets a “shell” – the ability to run commands on your server. They don’t need a password or an account on your website: a single specially crafted HTTP request is enough.

Researchers have confirmed working attacks against WordPress, Drupal, Joomla and Magento sites. Every way PHP serves web requests is affected:

PHP-FPM – the most common setup on modern servers;
Apache mod_php – where the PHP team considers the risk highest;
php-cgi, LiteSpeed and FrankenPHP.

Why a security plugin won’t protect you

The key thing about PHP2Shell is when the attack happens. PHP processes the request data before it runs any of your website’s code. That means every protection that works inside your website never even finds out about the attack.

The request’s path to your website

Press the button to see where the attack stops. Click any layer to see what it can do.

A specially crafted HTTP POST request. It looks like ordinary traffic and needs no login or account.
Can block known attack patterns, but only for traffic that passes through it. New variants can slip by, and if your server can be reached directly by its IP address, the WAF is bypassed entirely.
Hands the request to PHP. Limiting request size at this level reduces the risk from one known attack method, but doesn’t remove the flaw.
This is where the flaw is. PHP reads and processes the request data before running your website’s code, so the attacker’s code runs right at this step.
Your website system doesn’t even get to start. It makes no difference whether it’s up to date.
Nothing left to stop: the attack happened before these protections kicked in.

The conclusion is simple: the only complete fix is updating PHP itself. Everything else is a temporary measure that buys you time.

Two flaws, one chain

Both flaws relate to how PHP handles memory while processing requests. Website owners don’t need the technical details, but it’s worth knowing how they differ, because each one has different temporary mitigations.

Out-of-memory corruption · CVSS 9.2

When PHP runs out of memory just as it starts reading a POST request, some of its internal data is left only partly set up. At the end of the request, PHP treats that data as valid – even though its contents are controlled by the attacker. That opens the way to running their own code.

In plain terms: the attacker deliberately “overloads” PHP and exploits the mess it leaves behind.

Temporary measure: memory_limit=-1 at server level and a request size limit on the web server.

Use-after-free · CVSS 9.2

After one request, a PHP worker can be left holding a reference to memory that has already been freed. A later request handled by the same worker then uses that memory. This can leak memory contents and allow code execution. The flaw is reachable through the session upload progress feature, which is enabled by default.

In plain terms: one request leaves “litter” behind, and the next one exploits it.

Temporary measure: session.upload_progress.enabled=0, and on PHP 8.5 also fatal_error_backtraces=0.

How it unfolded

2024
During PHP’s first external security audit in years, the team spots the first signs of the memory problem that later became CVE-2026-109618. No working attack is found, nothing is made public and the fix stalls. The PHP Foundation later admitted the delay was a failure on its part.
11 August 2026
Researchers at Calif and OpenAI independently report to the PHP team that the same problem allows code execution on the server. Fixing it becomes the top priority.
17 October
Amazon Threat Intelligence records the first exploitation attempt in its honeypot network – four days before public disclosure.
20 October
The CVE identifiers leak. The PHP team publishes advance notice of a critical security release.
21 October
Because of the leak, fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are released a day earlier than planned. Cloudflare reports the first attacks and deploys temporary WAF rules.
Now
Attacks are increasing and come from several different actors. Amazon recommends looking for signs of compromise from 17 October, not from the disclosure date.

What this means for you: even if you updated PHP yesterday, your website could have been compromised earlier. A patch closes the door, but it doesn’t remove whoever already got in.

Is your website vulnerable?

Any website served by an unpatched PHP version is vulnerable. These versions already include the fix:

PHP branch	Safe version
PHP 8.5	8.5.12 or later
PHP 8.4	8.4.27 or later
PHP 8.3	8.3.36 or later
PHP 8.2	8.2.35 or later
PHP 7.4–8.1	No official fixed release. Upgrade to 8.2+ or use a package patched by your vendor.
PHP 5.4–7.3	End of life, no fix coming. Upgrade required.

Check your PHP version

Enter your PHP version

Examples:

Where do I find my PHP version?

In your hosting control panel (cPanel, DirectAdmin, Plesk) – under “PHP version” or “Select PHP Version”.
WordPress: Tools → Site Health → Info → Server.
Ask your hosting provider – and ask whether the fix has been applied to your PHP package.

If you create a phpinfo() file to check the version, delete it right afterwards – it reveals a lot about your server.

Why the version number can be misleading

Linux distributions often apply the fix without changing the version number. So an “old” number doesn’t necessarily mean PHP is vulnerable.
The PHP you see on the command line may differ from the one that actually serves your website.
On shared hosting, several PHP versions can run at once, and different domains may use different ones.

30-second risk check

Answer five questions. If you don’t know the answer, choose “Don’t know” – that’s an important answer too.

Do you know the exact PHP version that serves your website?
Has PHP been updated since 21 October, or has your provider confirmed the fix is applied?
Does your website run on PHP 8.1 or older?
Has anyone already reviewed the server logs and files since 17 October?
Does your website have an online store, customer accounts or personal data?

Answered 0 of 5

Order a PHP2Shell audit

What you can do today

Find out the exact PHP version serving your website and compare it with the table above.
Update PHP to a fixed version, or ask your hosting provider to do it. Before moving to a new branch, make a backup and check that your website, theme and plugins work with it.
If you can’t update right away, apply the temporary measures recommended by the PHP team (see below) and restart all PHP workers.
Check whether you’ve already been compromised: unknown PHP files, new administrators, shells spawned by website processes, “on line 0” out-of-memory errors in the logs – since 17 October.
Use a WAF as an extra layer, not a fix. It only protects traffic that passes through it.

Temporary measures in the PHP configuration:

memory_limit = -1                  ; CVE-2026-109618
session.upload_progress.enabled = 0  ; CVE-2026-109619
fatal_error_backtraces = 0         ; PHP 8.5 only

memory_limit must be set so that applications can’t change it (e.g. via php_admin_value in your PHP-FPM settings). Since this removes PHP’s memory limit, the PHP team advises enforcing one at container or cgroup level and limiting request size on the web server. These measures reduce the risk but don’t make PHP safe.

When to call in a specialist

Updating PHP often takes just a few minutes. The harder part is answering three questions: is the fix really active in the PHP that serves your website, will your website work with the new version, and did anyone exploit the flaw before you patched?

That’s exactly what the Redfox Cloud PHP2Shell audit checks. Your website is reviewed by hand by a server engineer, not an automated scanner, and you get the results in writing, in plain language. You don’t need to be our hosting customer.

PHP2Shell audit

29 € + VAT

The exact PHP version and SAPI serving your domain
Whether your provider has patched your PHP package
Error logs and signs of compromise since 17 October
Risk from your CMS and plugins
Written report and a quote for the fix

Order for 29 €

Full security audit

199 € + VAT

Everything in the PHP2Shell audit
System packages, kernel and known CVEs
Server, firewall, SSH, TLS and PHP configuration
Security flaws in your CMS, plugins, themes and custom code
Malicious code, backdoors, unknown cron jobs

Order for 199 €

We get in touch within 2 working hours of receiving payment (Monday to Friday, 9:00–18:00 Vilnius time). One-time payment. You get a quote for the fix after the audit, and it’s up to you whether we do the work.

Frequently asked questions

Is it enough that my hosting provider updated PHP?

If your provider confirms the fix has been applied to the exact PHP version serving your website, the most important step is done. But shared hosting often runs several PHP versions, and a patch doesn’t erase traces of a compromise that happened earlier. So it’s worth checking the logs from 17 October too.

Does Cloudflare or another WAF protect me?

Only temporarily and only partly. A WAF blocks known attack patterns for traffic that passes through it. If your server is reachable directly by IP address, or a new attack variant appears, the WAF won’t help. Only updating PHP solves the problem.

My website runs on PHP 7.4, 8.0 or 8.1. What should I do?

There are no official fixed releases for these versions – the PHP team has only published source code patches for those who compile PHP themselves. The safest path is upgrading to PHP 8.2 or newer. Before that, it’s worth checking that your website and plugins will work with the new version.

How can I tell if my website has already been hacked?

The most common signs are unknown PHP files, new administrators, odd redirects, commands run by website processes and repeated “on line 0” out-of-memory errors in the error logs. Some signs are only visible at server level, so you can miss them just by looking at the website.

Can I test my website with attack code published online?

We don’t recommend it. Publicly shared code is unverified, and such code is sometimes laced with malware itself. It’s safer to check your PHP version, patch status and logs.

Do you know which PHP version is serving your website right now – and that nobody got to it before you did?