PHP2Shell: Critical PHP Vulnerabilities and What Website Owners Should Do

On October 21, 2026, the PHP team shipped an emergency update fixing two critical vulnerabilities in the language itself. Known as PHP2Shell, they let an attacker run their own code on a server with a single HTTP request, no login required. Nearly every PHP version from the past decade and more is affected, and attacks started before the fix was out. If your website runs on WordPress, 1C-Bitrix, Laravel, OpenCart or any other PHP-based platform, this applies to you.

What happened

On October 20, the PHP developers gave advance notice of an urgent release, and the next day they shipped versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both vulnerabilities are rated 9.2 out of 10 on the CVSS v4.0 scale, which is critical.

• CVE-2026-109618 involves running out of memory. When a request exceeds memory_limit, PHP aborts it abruptly, and the request's internal data can be left half-built, for example while a file upload is being parsed. The cleanup code then treats that data as valid, which makes it possible to corrupt memory and hijack execution.
• CVE-2026-109619 involves stale state. After a fatal error, some of a request's internal data can outlive the memory behind it, and the next request handled by the same PHP process uses it before it gets reset.

The key point for a business: the attack fires before your site's own code even runs. So it does not matter how carefully the site was built or whether its plugins are up to date. If the PHP version on the server is vulnerable, so is the site.

The bugs were found over the summer by researchers using AI models, and the PHP team has been preparing the fixes since then.

Which versions are affected

• Every PHP version from 5.4 through 8.5.11 is vulnerable.
• The fixes are in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
• There will be no official releases for PHP 8.1 and older, as those branches are no longer supported. Given the severity, the PHP team has published minimal source-code fixes for 7.4, 8.0 and 8.1, and some Linux distributions and extended-support vendors are shipping their own packages.
• Every way PHP handles web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team singles out mod_php as the highest-risk setup.

Also keep in mind that PHP 8.2 support ends on December 31, 2026. If your site runs on 8.2 or older, plan a move to 8.4 or 8.5 once the emergency update is in place.

Is it being exploited?

Yes. Amazon reports that the first exploitation attempt hit its honeypots on October 17, four days before the fixes came out, and attempts became widespread after the release. Cloudflare is recording millions of attacks and sees attackers tweaking their requests to slip past protective filters. According to researchers, most attacks go through the mechanism that tracks file upload progress in PHP sessions.

That means you should look for signs of compromise from October 17 onwards, not from the date the update was released.

What to do right now

1. Find out your PHP version

• in WordPress: Tools → Site Health → Info → Server;
• in your hosting panel (cPanel, ISPmanager, Plesk), under the PHP settings for your domain;
• from the developer or studio that maintains your site.

Running php -v in a terminal shows the command-line PHP version, while the site itself may run on a different version through PHP-FPM. Go by the version the site or hosting panel reports.

2. Update PHP

Updating is the only way to fully close these vulnerabilities. On shared hosting, the provider updates PHP, so ask their support whether the fixed versions are installed. On your own server or VPS, update the packages from your distribution's repository and restart PHP-FPM or the web server. If PHP was installed from the remirepo repository, note that it had no updates on release day, and the PHP team advised switching to distribution packages or building PHP from source. Sites running in Docker need to be rebuilt on an updated base image and their containers restarted.

3. If you cannot update today

Temporary measures block the known attack paths, but they do not make a server safe. Use them only to hold the line until you update:

• turn off session.upload_progress.enabled in php.ini, the FPM pool or the web server configuration, then restart every PHP process. Setting it with ini_set() or a .user.ini file will not work;
• on PHP 8.5, also turn off fatal_error_backtraces;
• lower post_max_size: 8M if your site has no file uploads, 32M if it does;
• against the first vulnerability, the PHP team suggests removing memory_limit, but then a single request can use up all of the server's memory. This needs a memory cap at the container level and is best decided together with your administrator.

If your site runs on an old version that cannot be updated quickly, CERT-EU advises cutting it off from the internet for the time being. For a site that brings in leads that hurts, but a breach costs more.

4. Check the site for signs of compromise

• new or modified PHP files since October 17, especially in upload and cache folders;
• unfamiliar administrators in your CMS and new users on the server;
• new cron jobs and unknown processes;
• suspicious requests in the web server logs and spikes in PHP errors;
• customer complaints about redirects to other sites, and warnings in Google Search Console.

If you find anything, updating PHP is not enough. You need to remove the malicious code, restore the site from a clean backup and change every password and key stored on the server, including database, payment, email and API credentials.

What this says about website support

Mass attacks started within hours of disclosure, and the first attempts came even earlier. Sites looked after by a contractor get updates like this on the same day. Unattended sites stay vulnerable for weeks, and the owner finds out once the site has already been hacked. We covered what technical support includes in "Website Support After Launch". And if your hosting access is still with a former developer and you cannot even check your PHP version, start with our article on how not to lose your domain and website. Post-launch support can be ordered together with website or web application development.

Frequently asked questions

My site runs on WordPress and every plugin is up to date. Am I safe?

Not unless the PHP version on the server has been updated. The vulnerability is in PHP itself, and the attack fires before WordPress code runs, so updating the CMS and plugins does not help here.

My site is built on a website builder. Does this affect me?

Usually not, since the platform manages its own servers. But if you have a separate server, for example for a CRM, a bot or a customer portal written in PHP, check it.

Does Cloudflare or another WAF protect me?

Partly. Cloudflare is updating its rules against known attack variants, but attackers are already crafting requests to get around the filters. A WAF buys you time to update; it does not replace updating.

How can I tell whether my host has updated PHP?

Check the version in your hosting panel or in WordPress Site Health. For its branch it should be at least 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Linux distributions sometimes ship the fix without changing the version number, so if your version is older, ask your host whether PHP2Shell has been patched.

Not sure your server has been updated? Get in touch: we will check your PHP version, install the fix and look for any signs of compromise.