Your website says it’s up to date. Have you checked everything?

You read a report about a serious security flaw. It mentions PHP, artificial intelligence and a huge number of websites that might be affected. Your website runs on WordPress, so you log in to check.

WordPress is up to date. So are the plugins. Nothing is waiting in the Updates section.

You close the dashboard feeling rather more reassured.

It’s a sensible check, but it may only tell part of the story. The affected component could be on the server and need updating through a different process.

That’s what makes the PHP2Shell case useful: it makes us look at what we’re actually checking when we say a website is up to date.

What happened with PHP

On 21 October 2026, fixes were released for two critical vulnerabilities in PHP, the language WordPress runs on. Under certain conditions, they allowed an attacker to execute code on the server without logging in. The PHP team urged users to update affected installations immediately. Official PHP advisory.

Wiz researchers demonstrated attacks in test environments running WordPress, Drupal and Joomla. The problem was in PHP, underneath those applications’ code. Wiz research.

It helps to distinguish three things here: having a vulnerable component, receiving an attempted attack and suffering an intrusion. They are different situations and require different evidence.

The widely quoted 70% also needs some context. W3Techs puts PHP at roughly seven out of ten websites whose server-side programming language it can identify. That figure describes adoption; it doesn’t count attacked websites or tell us how many still need a fix. W3Techs statistics.

A website has more than one set of updates

A WordPress website has several parts worth distinguishing.

The first is the application itself: WordPress, the theme and the plugins. Many of their updates appear in the dashboard.

Then there’s PHP, which runs that application. Its version and security fixes are usually managed through the hosting service or by whoever administers the server.

There’s more, too: the web server, operating system and other services also need maintenance.

Each part has its own update process. That’s why you can have updated every plugin and still have a PHP fix outstanding. WordPress’s own guidance explains that PHP is installed on the server, so updating it involves the hosting settings or asking the provider for help. WordPress guidance on PHP.

What Hostinger has done in this case

Hostinger sent us a message explaining that, according to its tests, the known attacks could not exploit the vulnerability on its managed hosting platform. It also outlined the protections it had applied and confirmed that the PHP patch had been installed without customers having to intervene. Hostinger’s technical explanation.

It’s a concrete example of work that happens outside the WordPress dashboard: checking the infrastructure, applying fixes and explaining what is covered.

The distinction lies in the service you’ve bought. On managed hosting, Hostinger looks after PHP. On its VPS plans, that responsibility belongs to whoever administers the server.

There’s another useful detail: the fix can be added to the PHP version the website already uses without changing its displayed version number. To check this on its managed hosting, Hostinger says to look at the Build Date in “PHP Info”: it must be 21 October 2026 or later. How to check this at Hostinger.

That’s why, when deciding what kind of hosting your website needs, it’s also worth considering who handles these checks and how they respond when a security alert appears.

Artificial intelligence is changing the response window, too

The PHP Foundation explains that there had been signs of one of the problems since 2024, although no concrete way to exploit it had been identified at the time. AI-assisted research in 2026 helped demonstrate its full impact. Validation and patching continued to involve human work and decisions. The PHP Foundation’s explanation.

For someone running a business, the practical consequence is the ability to respond.

AWS documented an attempt related to PHP2Shell on 17 October in its decoy systems, before the fixes were published. It also observed further attempts on 21 October. This is not a count of compromised websites, but it shows that activity can begin before the alert reaches your inbox. AWS analysis.

A maintenance process needs to be able to deal with a critical alert without waiting for the next monthly review.

What to ask to find out whether your website is covered

You don’t need to learn server administration. Getting specific answers does help.

Which PHP version is actually running my website?

The site information can be a starting point. But “we have PHP 8.3” is too vague: the same branch includes versions released before and after the patch.

For the two initial flaws, PHP released versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Some providers supply patched builds of their existing packages, as we’ve just seen with Hostinger. Fixed PHP versions and packages.

Who applies the fix, and who checks that it’s working?

There should be a named person or team responsible, and confirmation that refers to your website or service. If you have several websites, test installations or subdomains, the review needs to include them.

Checking the main website leaves the status of everything else unanswered.

How will the change be made and the business functions checked?

Before changing versions, the project’s compatibility needs to be reviewed and a recoverable backup needs to be available. A staging environment lets you test the change, particularly where plugins or custom development are involved.

Preparation should support an urgent fix. If a temporary measure is needed while a compatibility problem is resolved, it should be decided by someone who understands the environment.

Afterwards, check what matters on that website: send a test enquiry, log in to the private area or go through a purchase in a test environment without making a real payment.

A homepage that loads correctly is a useful check. The other functions need their own checks, too.

Has the latest available advisory been reviewed?

On 23 October, PHP added an advisory about another route to code execution, limited to an unusual combination of configuration and application behaviour. It published a mitigation and said the fix would follow the regular release cycle. Whoever is responsible needs to review that additional scenario and determine whether it affects your setup. Updated CERT-EU advisory.

This follow-up is part of maintenance, too: an alert can receive new information after it is first published.

Fixing the flaw and checking what happened are different jobs

Applying a patch closes the routes that patch addresses. Finding out whether someone exploited them earlier requires reviewing the available evidence.

Depending on the exposure and what is found, the technical team will need to assess logs, files and possible changes to the installation. A website that looks normal doesn’t answer that question on its own.

A backup doesn’t replace that review either. If you need to restore an installation, you’ll have to choose a suitable backup and fix the cause before exposing it again. This is part of what we cover when discussing restoring a website without losing orders.

What should be clear after an alert

A useful response should explain which component was checked, what fix was applied, which functions were tested and whether anything still needs investigating.

That gives you something more concrete to close the review with than a screenshot of a dashboard with no updates waiting.

Reassurance has a much stronger basis when you know what has been checked and who took care of it.

If you’re not sure what your website maintenance includes, we can review what’s covered now and what needs to be added. Tell us about your situation.