Is Your Website Patched? PHP2SHELL Explained

Two critical security flaws have been discovered in the software running millions of websites, and attackers may not need a password to exploit them. They may not even need a vulnerability in your website, because this time the weakness is underneath the website itself. Emergency security updates have now been released, and security researchers are already reporting attempts to exploit the flaws.

If your business operates a website, an online store or a web application, there is one urgent question you need answered today: has the underlying server software been patched? I’m Dustin Gray, and today we’re looking at PHP2SHELL. We’ll cover what it allows attackers to do, why it matters to businesses, and what management needs to do right now.

So, let’s look at what’s happened. Researchers have uncovered two critical vulnerabilities in PHP, the programming language behind WordPress and many other websites. The vulnerabilities are rated 9.2 out of 10 for severity, and they can allow something called remote code execution.

In plain English, that means an attacker can potentially make your web server run their own malicious instructions without logging in, without knowing your password, and potentially before your website’s own security protections even get involved. That last point is particularly important because a fully updated WordPress website could still be vulnerable. Every plugin and every theme could be current, and your administrator accounts could have strong passwords. The underlying PHP software could still expose the server to attack.

So, what could an attacker actually do? Consider a business website connected to a customer database. That website might also connect to a CRM, payment services, email systems and other business applications.

If an attacker successfully exploits these vulnerabilities, they may be able to execute code with the permissions of the web server. Depending on how that server is configured, they could read sensitive files, steal database credentials, modify website content, install malicious software, or establish a back door to regain access later.

There’s another particularly concerning capability. Researchers demonstrated that sensitive information could be extracted directly from the server’s memory, including passwords, authentication tokens and API keys. That is information that might provide access to other connected business systems.

This doesn’t mean every affected website has been compromised, but it shows why this is more than a website defacement problem. It is potentially a business systems and data security problem.

So why is this such a big deal? Because PHP is not some obscure piece of software. It powers WordPress, Drupal, Joomla and countless custom business applications.

Researchers at Wiz estimate PHP is used by around 70% of websites. That doesn’t mean 70% of websites have been breached, or that every installation can be exploited in the same way, but it does explain the scale of the response.

European government websites have reportedly been taken offline. Security agencies are urging organisations to act immediately, and working attacks have already been demonstrated by researchers.

There are also reports of attempts to exploit the vulnerabilities. At the time of this bulletin, those reports do not establish a confirmed successful breach. But waiting for a confirmed breach before applying the available security updates would be a dangerous decision.

So what about WordPress hosting? Here’s where responsibility becomes important. Updating WordPress does not update PHP, and updating plugins does not update PHP.

PHP is normally managed at the hosting or server level. That means the person responsible for your website's hosting needs to confirm the security update, not simply tell you that WordPress is up to date.

The PHP project has released emergency patches for its supported versions, and older unsupported PHP versions need particular attention. If your website runs on shared hosting, managed WordPress hosting or a dedicated server, the responsibility for applying those updates may be different. But the business still needs confirmation that its systems are protected.

So, what should management do today? I recommend asking your website provider or IT manager three questions. First, which of our websites and applications run PHP, and what versions are they running?

Second, have the emergency PHP2SHELL security patches been applied to every affected server? And third, have we checked for signs of exploitation, and do we have a recovery plan if suspicious activity is discovered?

Don’t accept “all the plugins are updated” as the answer, because that’s not what this vulnerability is about. And don’t assume that having a firewall means you’re fully protected. The PHP project says updating is the only complete mitigation.

If a vulnerable system cannot be patched immediately, your technical team needs to assess whether it should be isolated or temporarily taken offline. Governments are taking full websites and services offline.

For business owners and boards, the lesson is straightforward. You need to know not just which applications you operate, but what underlying software those applications depend on and who is responsible for keeping it secure.

If you operate a business website, this deserves attention today. Not panic, not speculation, but a verified answer from the person responsible for your hosting: has our PHP been patched against CVE 109618 and 109619?

If they can’t answer that question, the next step is to find out why. I’m Dustin Gray, and this has been a special edition of the Action Report. Stay informed, and make sure someone is actually responsible for the security of your business systems.