PHP2Shell: Critical PHP Vulnerability Requires an Urgent PHP Update

A critical vulnerability in PHP itself, nicknamed PHP2Shell, lets attackers take over a website without logging in. Every WordPress site on an unpatched PHP version is exposed, and attacks have already started. The only fix is a PHP update that your web host has to install.

What is the PHP2Shell vulnerability?

PHP2Shell is the name for two critical flaws in the PHP interpreter, the software your web host runs to power WordPress. The PHP security team rates both as critical, with a CVSS v4.0 score of 9.2:

• CVE-2026-109618: When a request makes PHP run out of memory, PHP can be interrupted while its internal request data is only partly set up. Cleanup then treats that broken data as valid.
• CVE-2026-109619: Internal state from one request can survive after its memory is freed, and a later request handled by the same PHP worker can reuse it.

An attacker can chain these flaws with a specially crafted upload request. No login is needed. The result is remote code execution: the attacker can run their own code on your server and take over the site.

Even without taking over the site, an attacker can read leftover PHP memory, which can contain passwords, session tokens, and API keys.

How widespread is it?

• Every PHP version back to 5.4 is affected by at least one of the two flaws.
• Every common hosting setup is in scope, including PHP-FPM, Apache with mod_php, LiteSpeed, and php-cgi.
• The latest WordPress is not safe. Researchers have shown full takeovers of the latest WordPress, Drupal, and Joomla. Your WordPress core, plugins, and themes can be fully up to date and the site is still exposed.

For the full details, see the official PHP security advisory.

Attacks have already started

Details of the flaws leaked on October 20, a day before PHP released the fix. By the morning of October 21, Cloudflare and several hosting companies were reporting attacks. A public exploit tool is now available, so we expect attacks to grow quickly.

MalCare is already seeing attacks against sites. Treat this as an emergency, not routine maintenance.

Why MalCare’s firewall can’t block PHP2Shell

MalCare’s firewall, like every WordPress security plugin, runs as PHP code. It can inspect a request only after PHP has started up and loaded WordPress.

PHP2Shell strikes earlier than that. The attack fires while PHP is still reading the incoming request, before WordPress or any plugin has loaded. By the time a firewall plugin could look at the request, the damage has already happened.

This vulnerability has to be fixed at the web host level, by updating PHP.

Sites behind Cloudflare are protected for now

Cloudflare sits in front of your server, so it can stop a request before it ever reaches PHP. Cloudflare has pushed an emergency rule that blocks known PHP2Shell attacks, on every plan including the free one. If your site runs behind Cloudflare, that rule protects it.

We still recommend updating PHP on these sites. Cloudflare itself calls the rule a stopgap: it covers the attack patterns known today, and it can’t help if an attacker reaches your server directly instead of going through Cloudflare.

What you need to do now

Work through these steps today, starting with your most important sites.

Step 1: Find your vulnerable sites in the MalCare dashboard

We’ve added a new Vulnerable PHP filter to the MalCare dashboard specifically for PHP2Shell. Log in to your MalCare dashboard and apply the filter to your sites list. It shows every site running a PHP version that is exposed to this vulnerability.

If you manage sites for clients, use this list to see which hosts you need to contact and which clients to warn.

Step 2: Ask your web host to update PHP

PHP has released four patched versions. Your host needs to update each vulnerable site to the patched release for its PHP branch, or a newer one:

Sites on PHP 8.1 or older need to move to a newer branch, so test them before the switch. Older plugins and themes can break on newer PHP. Our guide on updating the PHP version in WordPress walks through doing that safely.

Contact your host’s support team now and mark the request as urgent.

Step 3: Confirm the update

Once your host says the update is done, check the PHP version yourself. In WordPress, go to Tools → Site Health → Info → Server and confirm the version matches one of the patched releases above. Then check the Vulnerable PHP filter in your MalCare dashboard again.

Step 4: Check sites that were exposed

Attacks started before the fix was released, so a site that was exposed may already have been hit.

• Run a MalCare scan on each site that showed up in the filter to look for malware or backdoors left behind.
• Ask your host to check server logs for signs of targeting: unusual upload requests followed by memory-limit errors or repeated HTTP 500 errors, unusually large session cookies, and unexplained PHP worker restarts.
• Rotate credentials if you see any of these signs or the scan finds anything. That includes WordPress admin passwords, the database password, and any API keys stored on the server.

If your host can’t update right away

Some hosts will take longer than others. In the meantime:

• Ask your host to apply PHP’s interim mitigations, such as turning off session.upload_progress.enabled. These reduce exposure but do not make the site safe.
• Put the site behind Cloudflare if it isn’t already. Its emergency rule blocks known PHP2Shell attacks while you wait. Ask your host to block traffic that doesn’t come through Cloudflare, so attackers can’t go around it.
• For high-risk sites, such as stores that handle payments, consider maintenance mode or taking the site offline until PHP is updated.
• If your host cannot give you a clear timeline, consider moving the site to a host that has already patched.