The php2shell vulnerability: is your website safe?

If your website runs on PHP, which covers almost every site built on WordPress, Joomla, Drupal or WooCommerce, then until 21 October 2026 it was open to an attack that needs no password and no user account. It is safe only once the server runs a patched PHP version. The fix exists, but someone has to install it, and for most small websites nobody does.

What happened

PHP is the language behind most of the world's websites. According to W3Techs, it is used by 69.3 percent of sites whose server-side language is known. WordPress, Joomla, Drupal, Magento and a large share of online shops run on it.

On 20 October the PHP team announced an urgent security release, and on 21 October it published fixes for two vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Researchers named them php2shell. Both are rated 9.2 out of 10, which is critical. Both let an attacker run their own code on the server through an ordinary web request, without logging in anywhere.

Affected versions run from PHP 5.4 to 8.5, practically everything used in the last twelve years. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Older versions are out of regular support: for 7.4, 8.0 and 8.1 the PHP team provided only source code patches that someone has to build in themselves, and for anything older, nothing.

Why this is more serious than the usual warning

There are many security warnings and most of them do not concern you. This one is different, for three reasons.

The attacker needs no access. With most vulnerabilities an attacker needs at least a user account, or the site has to use a particular plugin. Here it is enough that the server accepts web requests. The PHP team states that every installation serving web pages is at risk.

Attacks began before the release. Details became public even before the scheduled release. Amazon's threat intelligence team saw the first exploitation attempt on 17 October, four days before the fix was published. Amazon reports that the vulnerability is now being exploited on a broad scale. Amazon advises anyone checking their servers to look back to at least 17 October, not just to the release date.

There is no reliable workaround. The PHP team published a few settings that reduce the risk, but states plainly that they do not make a server safe. The only safe choice is to update.

How seriously this was taken elsewhere shows in the fact that some governments and institutions took their sites offline for a while, among them the Dutch government portal and the public web services of the Finnish state.

What an attacker gets once inside

An attacker who can run code on the server has everything your website can reach. That means customer data from contact forms, orders and addresses from the online shop, and user passwords stored in the database.

Most often you do not notice the break-in at all. The site keeps working while the attacker installs a hidden back door that lets them return even after PHP has been updated. An update closes the entrance, but it does not remove what the attacker may already have left behind.

The consequences owners notice only later are familiar: Google marks the site as dangerous and warns visitors in search results, the host suspends the account for sending spam, emails from the site start landing in junk folders, and customers receive messages in your name that you never sent. Because your site processes personal data, a break-in can also be a personal data breach that, under GDPR, usually has to be reported to the supervisory authority within 72 hours.

How to check whether you are exposed

A few things you can check yourself in ten minutes:

• Does your site run on PHP at all? If it is built with WordPress, Joomla, Drupal, WooCommerce, PrestaShop or Magento, the answer is yes.
• Which PHP version does the server run? In WordPress you find it under Tools, Site Health, the Info tab, Server section. If the number is lower than 8.2.35, 8.3.36, 8.4.27 or 8.5.12 for your branch, the server is not patched. If it is 8.1 or older, it gets no regular updates, which is a problem in itself.
• Who looks after the server? On shared hosting, PHP is updated by the host, not by you. Some larger hosts acted even before the release and deployed protective rules across all their servers, but with smaller providers you do not know until you ask. On your own or a virtual server, updating is entirely your responsibility.
• When did anyone last touch the site? If the answer is "when it was built", it is very likely that WordPress, the plugins and the theme are outdated too. In that case php2shell is just one of several open doors.

If you cannot answer one of these questions, that is already an answer. A website nobody knows is updating is, in practice, a website nobody updates.

Why "the host will handle it" is not enough

Even when the host updates PHP, two questions remain that nobody answers for you.

The first is whether the site was attacked between 17 and 21 October, or later, before the update arrived. The host replaces PHP, but it does not inspect the contents of your website. A back door the attacker left behind stays there.

The second is whether the site still works as it should after the update. Older themes and plugins tend to break when the PHP version changes: the contact form stops sending, the cart will not open, or the site shows a blank white page. Often a customer notices this before the owner does.

And one more trap: PHP 8.2 stops receiving security fixes on 31 December 2026. Anyone on 8.2 now will face the same question again in two months, this time without regular security fixes.

How we handle it at Carpolab

The websites we look after do not wait for someone to notice a problem. This is how we work when a warning like php2shell arrives:

• We follow official announcements, not only automated scanners. Automated dependency checkers often show new vulnerabilities with a delay. So we read the developers' own announcements directly, for PHP, WordPress and the frameworks we use.
• First we establish what is exposed. For each site we know where it runs, on which version, and who manages the server. When a warning arrives, we do not guess, we know which sites it affects.
• We take a backup before every update. If something goes wrong, the site is back the way it was within minutes.
• We check the site after the update. We go through the key pages, the forms and the checkout, on phone and desktop, and make sure enquiries still come through.
• We also look for signs of a break-in. With critical vulnerabilities like this one, we check whether anything appeared on the site during the critical days that should not be there.

The same goes for our own website. It runs on a different technology, not PHP, so php2shell does not affect it, but we follow security announcements for it as well and install critical fixes as a priority. This is part of the website maintenance we offer at a fixed monthly price: updates, backups and security in one package, without a separate quote for every small thing.

Frequently asked questions

I have a small site without an online shop. Am I really a target?

Yes. Attackers do not pick sites by hand. They scan the whole web automatically and attack every server that responds. A small site is useful to them as a base for sending spam or attacking others.

My host says PHP has been updated. Is everything fine now?

The entrance is closed. But the site is not necessarily clean if it was exposed for a few days before the update. Nor is it certain that everything works after the update, especially with older plugins and themes.

How do I know whether my site has already been attacked?

Often you cannot tell from the outside. The site can work completely normally. Signs include unknown files on the server, new admin accounts you did not create, or sudden changes in traffic and email. A reliable answer requires checking the server.

What does it cost to have this sorted?

It depends on what the site runs on and what state it is in. You can see an indicative price for maintenance or a redesign in the calculator, and for a check of your site, write to us.

What now

If you do not know which PHP version your site runs on or who updates it, now is the right moment to find out. Send us your website address through the contact form. We will check whether it is exposed and tell you what needs to be done, before Google shows up with a warning or a customer asks why they received a strange email in your name.