PHP2Shell and WordPress: What Brisbane Businesses Must Do

Last updated: 28 October 2026.

When the Australian Cyber Security Centre’s own website goes offline as a precaution, you know something serious is going on.

That’s exactly what happened last week. A pair of critical flaws in PHP — the software that quietly runs almost every WordPress website — triggered the ACSC’s highest-level alert and sent government and business sites around the world into maintenance mode.

The flaws have a name now: PHP2Shell. And if your business website runs on WordPress, it’s almost certainly relevant to you.

Here’s the good news. You don’t need to be a developer to work out where you stand. In this guide, we’ll explain what PHP2Shell is in plain English, show you how to check your site in two minutes, tell you exactly what to ask your web host, and flag the situations where a quick patch won’t be enough.

At Content Authority, we manage WordPress sites for businesses across Brisbane and South East Queensland. This past week, we’ve had the same conversation dozens of times — so here’s everything we’ve been telling our clients.

What Is PHP2Shell? The Plain-English Version

PHP2Shell is the nickname for two critical security flaws in PHP itself — not in WordPress, not in a plugin, but in the engine underneath them both. The fixes were released on 21 October 2026, and the advice from security agencies worldwide is the same: patch now.

What PHP Actually Does Behind Your WordPress Site

Think of your website like a shop. WordPress is the shopfront — the pages, the menus, the contact form your customers see. PHP is the engine room out the back that builds every one of those pages each time someone visits.

You never see PHP, and most business owners have never had to think about it. But it’s everywhere. According to W3Techs, PHP is used by 69.3% of websites whose server-side language is known, and WordPress alone runs 39.6% of all websites.

When the engine room has a problem, it doesn’t matter how nice the shopfront looks.

The Two Flaws: CVE-2026-109618 and CVE-2026-109619

Every publicly known security flaw gets an official ID number called a CVE. PHP2Shell is two of them:

• CVE-2026-109618 — when a server runs out of memory at the wrong moment, PHP can leave half-built data lying around and later treat it as if it’s valid.
• CVE-2026-109619 — data from one visitor’s request can survive after its memory has been freed, then get reused when the next request comes in.

Both relate to how PHP cleans up after a request goes wrong. That sounds dry, but the consequence isn’t. Both flaws are rated 9.2 out of 10 on the CVSS v4.0 severity scale — firmly in the critical range — and neither requires the attacker to log in.

Why Security Agencies Treated It as an Emergency

The technical term is unauthenticated remote code execution. In plain English: a stranger on the internet could send one specially crafted request to your website and run their own code on your server — no username, no password.

Once someone has that kind of access, they can usually reach the database sitting behind your site. That’s your customer enquiries, user accounts, order history and anything else your site stores.

The timing made it worse. The vulnerability IDs leaked online before the official fix was ready, and Amazon’s threat intelligence team says its honeypots logged an exploitation attempt on 17 October — four days before the patches came out. Security firms still disagree on how widespread real attacks have become, but nobody is advising businesses to wait and see.

What Happened Here in Australia

Australia didn’t sit this one out. Our national cyber agency moved early, and some of the country’s most important websites went dark while the fixes rolled out.

The ACSC’s Critical Alert

The Australian Signals Directorate’s Australian Cyber Security Centre (ACSC) issued a critical alert on 21 October — the highest rating it has. Its message to organisations running websites and web applications was simple: prepare now, and apply the fixes the moment they land.

Once the patches were released, the ACSC followed up on 22 October. It told organisations to apply them along with any other appropriate mitigations, then keep watching their PHP applications for suspicious activity.

If your business thinks it’s been affected and needs help, the ACSC’s hotline is 1300 CYBER1 (1300 292 371).

Why Government and Business Sites Went Dark

Here’s the detail that got everyone’s attention: cyber.gov.au itself was taken offline during the incident. When the agency responsible for keeping Australia cyber-safe pulls its own site, that’s a strong signal about how seriously the experts took this.

Overseas, the reaction was even bigger. France’s Interior Ministry put its websites into preventive maintenance. In the Netherlands, the national cyber security centre took its own site down, followed by the government portal Overheid.nl. In Germany, Berlin’s Charité hospital took its entire website offline.

These organisations have dedicated security teams. Most small businesses don’t — which is exactly why it pays to understand where your own site stands.

Is Your WordPress Site Affected?

If your website runs on WordPress and you haven’t confirmed your PHP version since 21 October, assume it’s affected until you know otherwise. Every site on an unpatched PHP version is exposed, no matter how up to date everything else is.

Why “My WordPress Is Up to Date” Doesn’t Protect You

This is the part that catches people out. You can have the latest WordPress, a fully updated theme and every plugin on its newest version — and still be vulnerable.

That’s because PHP2Shell lives one layer below WordPress. WordPress.org said so itself on 21 October: these vulnerabilities aren’t specific to WordPress, they affect any server hosting a PHP application, and no WordPress update is required or planned to fix them.

A few other things that won’t save you:

• Security plugins. Tools like Wordfence and MalCare run as PHP code, so they only start working after PHP has already processed the incoming request. MalCare has said plainly that its firewall can’t block PHP2Shell.
• Maintenance mode. PHP handles the request before WordPress even checks whether the site is in maintenance mode.

The only real fix is a patched version of PHP, installed by whoever runs your server.

Which PHP Versions Are Fixed — and Which Aren’t

The PHP project released four patched versions. If your site runs one of these (or newer), you’re covered. If it doesn’t, you’re not.

Now for the number that should worry a lot of Brisbane business owners. According to WordPress.org’s public statistics on 22 October, 35.8% of WordPress sites run PHP 8.1 or older — versions with no official patched release. Another 23.7% are on PHP 8.2, which runs out of security support in about nine weeks.

In other words, more than half of WordPress sites need more than a quick patch over the next few months.

How to Check Your Site’s PHP Version in Two Minutes

You don’t need to touch the server or call a developer to find out which PHP version your site runs. There are two easy ways to check, and you only need one.

Method 1: WordPress Site Health

WordPress has a built-in health check that shows your PHP version in a few clicks:

1. Log in to your WordPress dashboard.
2. Go to Tools → Site Health.
3. Click the Info tab.
4. Open the Server section.
5. Look for the line labelled PHP version.

Write down the full number — something like 8.3.36, not just 8.3. You’ll need it in a minute.

While you’re there, glance at the Status tab too. If Site Health is already flagging your PHP version as outdated, that’s your first clue about which section below applies to you.

Method 2: Your Hosting Control Panel

Most Australian hosts use cPanel or something similar. Look for a menu item called Select PHP Version, MultiPHP Manager or PHP Configuration — it’ll show the version each site is running.

On VentraIP, for example, you’d log in to VIPcontrol, open your web hosting service, launch cPanel, then click Select PHP Version under Software. Other hosts follow a similar path, though the labels move around.

Why the Full Version Number Matters

“8.3” doesn’t tell you whether you’re patched. “8.3.36” does. The last number is the one that confirms the PHP2Shell fix is installed.

There’s one wrinkle. Some hosts apply security fixes to their existing build without changing the version number — Hostinger has said some of its sites will keep showing the old number for exactly this reason. So if your number looks old, don’t panic. Ask your host to confirm in writing whether the 21 October fix has been applied.

What to Do Right Now, Based on Your PHP Version

Once you know your version, your next step is straightforward. Find your row below.

PHP 8.3, 8.4 or 8.5

You’re in the best position. Patched releases exist for all three branches — 8.3.36, 8.4.27 and 8.5.12.

If your version number matches (or is higher), you’re covered. If it’s lower, your host hasn’t installed the fix yet. Contact them today, ask when it’ll be applied, and ask them to confirm that PHP has been restarted afterwards. A PHP process that hasn’t been restarted can keep running the old code even after the update is downloaded.

PHP 8.2 — Patched, but Living on Borrowed Time

PHP 8.2.35 fixes PHP2Shell, so get that installed now.

But there’s a catch. PHP 8.2 reaches end of life on 31 December 2026. After that, it won’t receive any more security fixes — so the next time a serious flaw turns up, there won’t be a patch for 8.2 at all.

WordPress recommends PHP 8.3 or newer. If you’re on 8.2, treat PHP2Shell as your nudge to plan the move to 8.3 or 8.4 before Christmas, not after.

PHP 7.4, 8.0 or 8.1 — No Official Patch Is Coming

This is where things get serious. The PHP project hasn’t released official patched versions for these branches. It has only published source-code backports — fixes that someone has to compile and install manually.

On shared hosting, that’s simply not an option for you. And most hosts won’t do it either.

So the realistic fix is moving your site to PHP 8.3 or 8.4. For many sites, that’s a simple switch in the control panel. For others — especially sites built several years ago — it’s where things start to break. We’ll explain why in a moment, because it’s the single biggest reason a PHP2Shell “quick fix” turns into a bigger job.

The key rule: never flip the PHP version on a live site without testing it first.

Anything Older Than PHP 7.4

If your site is still on PHP 7.3, 7.2 or anything in the 5.x range, no fix has been published for PHP2Shell — and your site has been missing security updates for years.

We’ll be straight with you. A site this far behind almost certainly has a theme and plugins that won’t run on a modern PHP version. Jumping several major versions at once is rarely a simple switch. In most cases we see, it’s the point where rebuilding on a current setup is quicker, cheaper and safer than trying to patch the old site into shape.

That doesn’t mean you need to panic or rush into a new website this afternoon. It does mean the conversation should start this week.

What to Ask Your Web Host (Copy-and-Paste Email)

On most hosting plans, you can’t install the PHP fix yourself — your host has to do it. The fastest way to find out where you stand is to ask them directly, in writing, and keep their answer.

The Three Questions That Matter

Here’s an email you can copy, paste and send today:

Subject: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) — patch status for [your domain]

Hi team,

Following the PHP security release on 21 October 2026, could you please confirm the following for [your domain]:

1. The exact PHP version installed, including the full point release (e.g. 8.3.36).
2. Whether the 21 October PHP2Shell fix has been applied, and on what date.
3. Whether PHP has been restarted since the fix was applied.

If my site is on PHP 8.1 or older, please let me know which newer PHP versions are available on my plan.

Thanks,
[Your name]

A good host will reply with clear, specific answers. If you get something vague like “we’re looking into it” a week after the patches came out, that tells you something too.

Shared Hosting vs VPS: Who’s Responsible for the Patch?

Who actually installs the fix depends on the type of hosting you have:

That VPS row is the one that worries us most. Plenty of businesses moved to a VPS for speed and control, then lost track of who’s responsible for keeping the server itself updated. We cover everything you need to know about VPS hosting for Brisbane businesses in a separate guide.

And if your site sits on our hosting, you can relax — we patch the server side for you. That’s part of the WordPress website support we provide for every site we manage.

Why Upgrading PHP Can Break an Old WordPress Site

For sites on PHP 8.1 or older, the fix isn’t a patch — it’s a version upgrade. And that’s where a lot of older WordPress sites run into trouble.

Each major PHP release removes old features and tightens the rules. Code that ran happily on PHP 7.4 can throw fatal errors on PHP 8.3. The bigger the jump, the more likely something breaks.

Abandoned Plugins and Outdated Themes

Plugins are the usual culprit. A plugin that hasn’t been updated in two or three years was never written for modern PHP. Switch versions, and you might see:

• The dreaded white screen or “There has been a critical error on this website” message
• Contact forms that look fine but never send enquiries
• Booking calendars or sliders that simply disappear
• A WooCommerce store checkout that fails right at the payment step

The nasty part? Some of these breakages are silent. Your homepage might load perfectly while your enquiry form quietly stops working — and you won’t know until the phone stops ringing.

Plugin bloat makes it worse. Every extra plugin is another piece of code that has to survive the upgrade. We share our shortlist of must-have WordPress plugins in a separate guide, and it’s a useful starting point if your plugin list has grown out of control.

Old Page Builders and Custom Code

Themes and page builders are the next risk. Older versions of builders like Elementor or WPBakery, premium themes that stopped receiving updates, and custom code snippets added to a child theme’s functions.php file are all common breaking points.

If a developer built your site years ago and has since moved on, nobody may know what custom code is lurking in there. That’s when professional WordPress website development work stops being a nice-to-have — someone needs to find and fix that code before the upgrade, not after.

Why You Always Test on a Staging Copy First

The safe way to upgrade PHP looks like this:

1. Back up everything. Take a full backup of your files and database with a tool like UpdraftPlus, and store it somewhere other than your server.
2. Create a staging copy. Use WP Staging or your host’s built-in staging feature to make a private clone of your site.
3. Switch PHP on the copy. Move the staging site to PHP 8.3 or 8.4.
4. Test what makes you money. Submit every form, run a test booking or checkout, and click through your key pages.
5. Fix, then go live. Update or replace anything that broke, then switch the live site.

It takes longer than flicking a switch. It’s also the difference between a smooth upgrade and a weekend with a broken website.

Signs Your Site May Already Be Compromised

Patching closes the door. It doesn’t tell you whether someone walked through it before you closed it. With an exploitation attempt spotted as early as 17 October, it’s worth a quick check — even if your host has already applied the fix.

Red Flags to Check For

You don’t need technical skills to spot most of these:

• Admin users you don’t recognise. Go to Users in your dashboard and filter by Administrator. Anyone you can’t account for is a serious warning sign.
• PHP files in your uploads folder. Your wp-content/uploads folder should hold images and documents. A .php file in there almost never belongs.
• Strange redirects. Visitors (or you, on your phone) get sent to spammy or unrelated websites.
• Google warnings. Search results showing “This site may be hacked”, or a security alert in Google Search Console.
• Unexpected changes. New pages you didn’t create, links you didn’t add, or a sudden spike in traffic from overseas.
• Your host gets in touch. Many hosts scan for malware and will contact you if they find something.

A scan with a reputable security plugin like Wordfence can help with the file checks. Just remember: these tools detect problems after the fact — they can’t block PHP2Shell itself.

What to Do If You Spot One

If any of those red flags show up, treat your site as compromised and act quickly:

1. Change every password connected to the site — WordPress admins, hosting, database, FTP and email.
2. Rotate any API keys stored on the site, such as payment gateway or email marketing keys.
3. Restore a clean backup from before 17 October, then apply the PHP fix before bringing it back online.
4. Report it to the ACSC on 1300 CYBER1 if you need advice or assistance.

If your business is covered by the Privacy Act and customer information may have been accessed, you’ll also need to assess whether the Notifiable Data Breaches scheme applies. The OAIC has clear guidance on assessing a data breach — and it’s worth getting advice early rather than late.

How to Take Your Site Offline Without Wrecking Your Google Rankings

Some businesses chose to take their sites offline while they waited for a fix. That’s a reasonable call — but do it wrong, and you could undo years of SEO work in a matter of days.

The key is the error code your site sends while it’s down. Google’s John Mueller has advised returning an HTTP 503 status rather than letting requests time out or serving 404 or 500 errors.

Here’s why it matters. A 503 tells Google “we’re temporarily unavailable — come back later.” Your pages keep their place in the index. A 404 says “this page doesn’t exist,” and enough of those can see your pages dropped from search results altogether.

Most maintenance plugins and hosting control panels can serve a proper 503. Just remember that a maintenance page alone won’t protect you from PHP2Shell — it’s purely about keeping your rankings intact while the real fix happens behind the scenes.

PHP2Shell Is a Wake-Up Call, Not a One-Off

It would be nice to think PHP2Shell was a once-in-a-decade event. The evidence says otherwise.

Back in July, WordPress fixed wp2shell — two flaws in WordPress core itself that allowed a site takeover without logging in. That same month, the ACSC warned of a large-scale campaign exploiting vulnerable content management systems and plugins, with many small and medium-sized Australian businesses already hit and webshells planted on their sites.

The day-to-day risk is even bigger. Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025. 91% were in plugins. 46% had no fix from the developer when they were made public. And for the most heavily exploited flaws, the median time from disclosure to mass exploitation was just five hours.

Put that together and every WordPress site has four layers that need watching: the server, the PHP version, WordPress core and every installed plugin. This time, the weak point was a layer most business owners didn’t even know existed.

The businesses that got through PHP2Shell with the least stress weren’t the ones with the biggest budgets. They were the ones who already knew exactly who was responsible for each of those layers.

Don’t Wait for the Next PHP2Shell — Let Content Authority Look After Your WordPress Site

Most business owners didn’t get into business to monitor PHP versions. You’ve got customers to look after, staff to manage and a business to grow. That’s exactly why we take this off your plate.

Whether your site just needs patching and watching or it’s reached the end of the road, we’ll tell you honestly which camp you’re in.

If Your Site Just Needs Patching and Watching

If your site is in reasonable shape, you don’t need a new website — you need someone keeping an eye on it.

Our ongoing WordPress maintenance covers the four layers that matter: PHP version management, WordPress core updates, plugin and theme updates, and security monitoring. We test updates before they hit your live site, keep regular backups so a bad day never becomes a disaster, and fix errors and plugin conflicts as they pop up.

When the next critical alert lands, you won’t be scrambling to work out who your host is or which PHP version you’re on. We’ll already know — and we’ll already be on it.

If Your Site Can’t Survive the Upgrade

Some sites are simply too far behind. If you’re on PHP 7.4 or older, carrying a stack of abandoned plugins, or built on a theme that hasn’t been updated in years, patching the old site can cost more than starting fresh.

In that case, we’ll recommend a plugin overhaul or a rebuild on a modern WordPress stack — fast, secure, mobile-friendly and SEO-ready from day one. We’ll carry over your content, set up proper redirects so you keep your Google rankings, and hand you a site that’s built to keep up with PHP updates instead of fighting them.

Book Your Free Website Audit

Not sure which camp you’re in? That’s what our free website audit is for. We’ll check your PHP version, review your plugins and theme, flag any security red flags, and give you a straight answer on whether you need a patch, an overhaul or a rebuild.

If you’d like us to look at the bigger picture too, our digital marketing audit takes in your SEO, content and site performance alongside security.

Call us on 0490 436 812 or email [email protected] to book your free audit today.

Frequently Asked Questions

Does updating WordPress fix PHP2Shell?

No. PHP2Shell is a flaw in PHP, the software running underneath WordPress. WordPress.org has confirmed no WordPress update is required or planned to fix it. Keeping WordPress, your theme and your plugins updated is still good practice — it just doesn’t close this particular hole. Only a patched PHP version does.

My site is on WordPress.com — do I need to do anything?

No. Automattic, the company behind WordPress.com, has said all sites it hosts — including WordPress.com, WordPress VIP, WP Cloud and Pressable — were already protected. This only applies to those platforms, though. If you use WordPress with any other host, check your PHP version and confirm the fix with your provider.

My host says I’m on PHP 8.3. Am I safe?

Not necessarily. You need PHP 8.3.36 or newer to be patched — “8.3” on its own doesn’t confirm it. Some hosts also apply fixes without changing the version number. Ask your host to confirm in writing that the 21 October fix has been applied and PHP has been restarted.

Will changing my PHP version break my website?

It might, especially if your site is several years old or relies on plugins that are no longer updated. Moving between nearby versions, like 8.2 to 8.3, is usually smooth. Bigger jumps carry more risk. Always back up your site and test the new version on a staging copy before switching your live site.

Do I need a whole new website?

Most sites don’t. If your site runs a recent PHP version and actively maintained plugins, patching and regular maintenance is enough. A rebuild usually only makes sense when a site is on PHP 7.4 or older, depends on abandoned plugins or themes, or would cost more to fix than to replace. A professional audit will tell you which applies.

When does PHP 8.2 stop getting security fixes?

PHP 8.2 reaches end of life on 31 December 2026. After that date, it won’t receive security fixes for any new vulnerabilities. If your site is on PHP 8.2, install 8.2.35 now to close PHP2Shell, then plan your move to PHP 8.3 or 8.4 before the end of the year.