PHP2Shell: what a company with a PHP or WordPress site should do now

Two critical PHP vulnerabilities allow a server takeover without a password. What to check, what to ask your host and what to do if you cannot update today.

On 21 October 2026, the PHP team published fixes for two critical vulnerabilities, known publicly as PHP2Shell (CVE-2026-109618 and CVE-2026-109619). Both are rated 9.2 out of 10 and can let an attacker run code on the server without an account or a password. PHP is the language behind WordPress, WooCommerce, PrestaShop, Magento, Joomla, Drupal, Laravel and many custom-built applications, so your company website is very likely among those affected.

This article is for owners and managers, not developers. It covers what to check, what to ask your hosting provider or whoever looks after your site, and what to do if you cannot update today. The steps follow the alert published by DNSC, Romania's National Cyber Security Directorate.

The problem is not in your site's theme or plugins but in PHP itself, the program on the server that runs the site. A specially crafted request can corrupt PHP's memory while it is being processed, and that can lead to a takeover of the server. Details began circulating before the fix was ready. Amazon reported a first exploitation attempt on 17 October, four days before the official announcement.

Security agencies gave the same advice: DNSC in Romania, CERT-EU for the European institutions, the NCSC in the United Kingdom and the FBI in the United States. Update PHP now; if you cannot, isolate the system or take it offline until it is fixed.

Attacks like this are automated: they scan the whole internet rather than pick targets. A five-page brochure site is as exposed as a large online shop, and a compromised server can be used for spam, for attacks on others, or to steal data from forms and the database.

A security plugin does not protect you from PHP2Shell. DNSC points out explicitly that security plugins, maintenance mode and disabling file uploads are not sufficient protection, because they act after PHP has already processed the request. Cloudflare likewise notes that updating the theme or plugins does not fix the problem: PHP itself has to be updated.

• On shared hosting (cPanel, Plesk or your host's control panel): the PHP version is shown in the panel. The safer route is to ask your host's support directly whether they have applied the 21 October fixes.
• In WordPress: Tools → Site Health → Info → Server shows the PHP version.
• On your own server or in the cloud: whoever manages it should check the version the web server actually uses, not just the command-line one. Linux distributions may ship the fix without changing the displayed version number, so the distribution's security notice matters too.

OpenAI has published a free tool that reads the PHP version a website reports. It is a useful first check, but its own documentation says that an "unknown" result does not mean the site is safe: many servers hide their version. The reliable answer comes from the server itself.

The versions containing the fix, released on 21 October 2026, are:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

After updating, every PHP process (for example PHP-FPM) must be restarted and container images rebuilt. DNSC then recommends checking the version the application is actually using. Without a restart, the server can keep running the old code.

A note on PHP 8.2: it receives the fix now, but its support ends on 31 December 2026. If you are updating anyway, it is worth considering a direct move to 8.4 or 8.5, so you do not repeat the work in two months.

The PHP project no longer publishes releases for 8.1, 8.0, 7.x or anything older. The PHP team has made minimal fixes available for 7.4, 8.0 and 8.1, but they have to be built from source. Some Linux distributions and extended-support vendors offer patched packages.

For most companies, the realistic option is migrating to a supported version. For a recently maintained WordPress site, this is usually a setting in the hosting panel followed by testing. For an older application written for PHP 5 or 7, it is a small project: the code has to be adapted and tested before the move. Until then, DNSC recommends isolating the system or applying temporary measures.

The PHP team is clear that there is no complete mitigation: only updating solves the problem. For a few days, whoever manages the server can still reduce the risk:

• disable the "session upload progress" feature in the PHP configuration and restart the processes;
• limit the size and number of fields in requests the server accepts;
• block file uploads where the site does not need them;
• put the site behind a web application firewall (WAF), such as Cloudflare, which has published rules for PHP2Shell. DNSC notes that a WAF only helps if the server cannot be reached directly, bypassing the filter.

If none of this is possible, the NCSC and the FBI recommend taking the system off the internet until it is fixed. For a brochure site, a temporary static page is often a good solution.

Because attempts started before the patch, updating alone is not enough. DNSC recommends looking for signs of compromise from 20 October 2026, 15:00 UTC onwards:

• new or modified files in the website's directories;
• changes to .user.ini files or to the auto_prepend_file setting;
• new scheduled tasks (cron) or SSH keys;
• shell processes or download tools started by PHP;
• new administrator accounts in the application.

If you find anything, isolate the server, keep the logs, reinstall from trusted sources and change every password, key and secret PHP had access to. In Romania, incidents can be reported to DNSC on 1911.

One more check for WordPress. In the same week, attackers used UpdraftCentral keys stolen from the maker of the UpdraftPlus plugin to install hidden plugins and new accounts on otherwise up-to-date sites. If you use UpdraftPlus, update it, delete the UpdraftCentral keys in its settings and review your user list.

DNSC points out that under Romanian Law no. 58/2023, article 5(a), responsibility for the security of an IT system lies with the person or company that owns, manages or uses it. In practice, even if someone else built your site years ago, your company has to make sure it is kept up to date. For the exact obligations in your situation, check with a lawyer.

1. Find out which PHP version the site actually uses, from your host or administrator.
2. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart the PHP processes.
3. If you are on 8.1 or older, plan the migration and isolate the system until then.
4. If you cannot update today, apply the temporary measures or take the site offline for now.
5. Look for signs of compromise since 20 October.
6. On WordPress, also check UpdraftPlus and the users with administrator rights.

At ME Digital we help companies apply the official fixes: we check the real version on the server, update or migrate older applications and look for signs of compromise, as part of our security and updates services. If you would like us to look at your site, get in touch.

• PHP, security announcement of 21 October 2026
• DNSC, Alert: critical vulnerabilities in PHP (updated 22 October 2026, in Romanian)
• CERT-EU, Security Advisory 2026-018
• NCSC (UK), Critical security issue affecting PHP
• PHP Foundation, report on the 21 October 2026 security release
• Cloudflare, WAF protection for the PHP vulnerabilities
• The Hacker News, the 17 October exploitation attempt reported by Amazon
• OpenAI, php2shell-checker
• Patchstack, UpdraftCentral key compromise