php2shell: what the critical PHP vulnerability means for your business website

On 21 October 2026, the people who maintain PHP shipped emergency fixes for two critical security flaws, now known as php2shell. Under the right conditions, an attacker can use them to take control of a web server without logging in, even if your website has no bug of its own.

PHP sits underneath most of the web. W3Techs puts it behind 69.3% of websites whose server language is known, and every WordPress site runs on it. If your business website is on WordPress, Drupal, Joomla or a custom PHP build, this applies to you.

The fix is an update to PHP on the server. A plugin update won't do it. So the most useful thing you can do today is ask whoever hosts your website two questions: which PHP version are we on, and has it been patched?

Last updated 22 October 2026 (Australian time). We'll update this article as the facts change.

What happened

The PHP project published two advisories on 21 October:

• CVE-2026-109618, remote code execution through memory corruption when PHP runs out of memory while handling a request
• CVE-2026-109619, remote code execution through "stale global state", where data from one request survives and gets reused by the next

PHP rates both 9.2 out of 10 on the CVSS v4.0 scale. Early reports based on a leak claimed 10.0, which was never PHP's rating.

Researchers at Wiz, Calif and OpenAI's Codex Security team found the flaws and reported them to PHP in late August. Details leaked publicly on 20 October and PHP brought the release forward.

As of 22 October, this is what's known about attacks:

• The US Cybersecurity and Infrastructure Security Agency (CISA) said it had not observed exploitation when it published its alert on 21 October.
• By the afternoon of 21 October (UTC), security firm watchTowr was reporting active exploitation attempts. Cloudflare switched on firewall rules for php2shell early that day, and its CTO said it was already seeing early attack attempts, BleepingComputer reported.
• No successful compromise had been confirmed.
• The flaws were not on CISA's Known Exploited Vulnerabilities list when we checked on 22 October.

Sources: Wiz Research, The Hacker News, CISA and php.net.

Why this one is different

Most website security news is about a plugin or a theme. You update the plugin and the hole closes, so staying up to date protects you.

php2shell sits a layer further down, in PHP itself. According to Wiz's analysis, a site doesn't need any vulnerable code of its own to be exposed. Wiz showed working attacks against the current official container images of WordPress, Drupal and Joomla. A WordPress site with every plugin updated this morning can still be exposed if the server underneath runs an unpatched PHP.

The flaws involve PHP getting its memory into a bad state while it handles an incoming request. A carefully built request can turn that bad state into the ability to run the attacker's own code on your server. The attack needs particular conditions and may need tuning for each target, which is part of why there may still be time to patch before attacks spread.

HR platform BambooHR took its service offline in the US, Canada and Ireland as a precaution and had it back the same day with no breach reported. The Dutch government took its DigiD login system offline too, The Hacker News reported.

Who is affected

Wiz says every PHP version back to 5.4, released in 2012, is affected when PHP is serving web requests. What matters for you is which version you're on and whether a fix exists for it.

PHP itself has no official release for 8.1 and older. Several Linux distributions have since shipped patched packages, including Ubuntu and AlmaLinux, and they keep their older version numbers. A server can show "8.1.2" and still be patched, so don't rely on the number alone. Ask your host to confirm the fix for CVE-2026-109618 and CVE-2026-109619 specifically.

How exposed you are also depends on where your site lives.

Managed WordPress or cloud hosting (Cloudways, WP Engine, Kinsta and similar). Your host controls PHP and should patch it for you. Cloudways, for example, applied PHP's interim protections across its fleet on 21 October and began a phased rollout of patches for every PHP version from 5.6 up, using extended support builds for versions PHP no longer maintains.

Budget shared hosting. This depends on the provider, so ask yours.

A VPS or server you or a past developer set up. Nobody patches this for you unless someone has been given the job.

Shopify, Squarespace or Wix. You don't run your own PHP, so there's nothing for you to patch. The platform handles its own servers.

What it means for an everyday business

An attacker who can run code on your web server can usually:

• read or change anything on the website, including form submissions, customer records and orders
• inject spam pages or malicious scripts that get your site flagged by Google or browsers
• send spam from your server, which can get your domain blacklisted and hurt your email delivery
• take the site down, or use it to reach other systems

These rarely arrive as one dramatic event. Often the first sign is a customer saying the site redirects somewhere strange, or a hacked-content warning in Google Search Console.

The Australian Signals Directorate's Annual Cyber Threat Report 2024-25 puts the average self-reported cost of a cybercrime at $56,600 for a small business and $97,200 for a medium business. Both went up on the year before.

The sites most likely to be caught out are the ones built a few years ago that have run on the same server ever since. They're the ones most likely to still be on PHP 8.1 or older, with no official release.

Your checklist for this week

1. Find out your PHP version. In WordPress, go to Tools > Site Health > Info > Server. Your host's dashboard usually shows it too.
2. Ask your host or developer whether the php2shell fixes are applied. Get a yes or no. "Mitigated" is not the same as "patched". PHP's interim settings reduce the risk without removing it, and PHP core developer Gina Peter Banyard put it plainly: "the only mitigation is patching".
3. If you're on PHP 8.1 or older, start the upgrade now. A newer version can break older plugins or custom code, and testing takes time.
4. Check your backups. They should exist, be stored somewhere other than the web server and have been restored successfully at least once.
5. Consider a web application firewall. Cloudflare added rules for php2shell on 21 October for sites behind it. Check that they apply to your plan. A firewall buys time while you patch.
6. Watch for anything odd over the next few weeks: admin users you didn't create, unfamiliar files, sudden traffic spikes or security warnings in Search Console.

For the client websites we look after, we're rolling out patches right now as our top priority, where appropriate.

The patch window keeps shrinking

What happened after php2shell went public is now normal: a serious flaw goes public and attackers move within hours.

Patchstack's State of WordPress Security in 2026 counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, up 42% on 2024. 91% were in plugins, and high-risk vulnerabilities more than doubled. For heavily exploited flaws, Patchstack found the weighted median time from public disclosure to the first exploitation attempt was 5 hours.

Verizon's 2026 Data Breach Investigations Report found that exploiting a vulnerability is now the most common way attackers get in. According to Help Net Security's summary, organisations took a median of 43 days to fully patch actively exploited vulnerabilities, up from 32 days the year before.

Median times from two separate studies covering different sets of vulnerabilities: Patchstack (WordPress, 2025) and the Verizon 2026 DBIR.

The two studies measure different things. Still, for the most targeted flaws, attackers can be moving long before a typical business has patched.

One of the three teams credited with finding php2shell, OpenAI's Codex Security, works on AI-assisted bug finding. We expect tools like it to surface more serious flaws in old, widely used code, faster. That helps when defenders find them first, and it also means attackers have more to work with.

What proactive website security looks like

For a small or mid-size business, most of the work is making sure someone is responsible for each layer of the website.

Someone should own the server as well as the plugins. Plugin updates show up in the WordPress dashboard. PHP patches, server packages and SSL renewals don't.

PHP should be upgraded on a schedule, while there's time to test. PHP 8.2's end of life on 31 December means the next upgrade is already due for many sites.

Managed hosting costs more than the cheapest shared plan. Part of what you pay for is someone else watching for this kind of problem.

Monitoring and tested backups won't stop every attack. They mean you find out sooner and can restore a clean copy. Know who you'd call, how fast they'd respond and where your last clean backup is. A website support and maintenance arrangement should answer all three.

You don't necessarily need an agency for this. A good managed host plus a careful developer, or an in-house person with time set aside each month, can cover most of it.

What to watch next

• Whether php2shell is added to CISA's Known Exploited Vulnerabilities list, which would mean confirmed exploitation
• Reports of successful compromises, especially against WordPress sites
• Hosts finishing their patch rollouts

We'll update this article when any of those change.

Not sure where your website stands? We look after WordPress and PHP sites for Australian businesses, including server-level updates like this one. If you'd like us to check your PHP version and patch status, our support team can help.