Is your site affected by PHP2Shell?
If it runs WordPress, probably, and a WordPress update won't fix it. PHP2Shell is a pair of flaws in PHP, the language most websites run on, so the fix comes from whoever runs your server. What to check, what to ask, and why pre-rendered sites had nothing to patch.
- The flaw
- two bugs in PHP itself
- Fixed
- 22 October 2026, AEDT
- At risk
- WordPress, Joomla, Drupal, Magento
- The fix
- your host updates PHP
- Nothing to do
- Shopify, Wix, pre-rendered
- ACSC
- critical alert, 21 October
- Price
- see our own price list
As reported to 24 October 2026. Prices exclude GST; security plans are in US dollars.
Australia · 2026A flaw in PHP itself. Your host fixes it, not a WordPress update.
PHP2Shell is the name given to two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619. PHP is the programming language behind WordPress, WooCommerce, Joomla, Drupal and Magento, and behind 69.3% of the websites whose server language is known. One request built the right way can let an attacker run their own code on the server, with no password needed.
The fix came out at 1am AEDT on 22 October 2026, and it lives in PHP, not in WordPress: updating WordPress, its plugins or its theme does not fix it. Whoever runs the server has to install PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or confirm a patched build of the version you are on.
About one WordPress site in three still runs PHP 8.1 or older, which the PHP project no longer updates. The ACSC issued a critical alert, its highest rating, and Wordfence had blocked more than 74,000 attack attempts by 22 October; as of 24 October no break-in had been publicly confirmed, and the ACSC knew of none in Australia.
Shopify, Squarespace and Wix patch their own servers, so there is nothing for you to update. A pre-rendered site, built ahead of time with a tool like SvelteKit or Astro, runs no PHP at all: its pages are finished files on a CDN, with no database, no plugins and no login page on the public site.
Neither PHP2Shell nor the WordPress plugin attacks the ACSC warned about in July had anything there to reach. What is left to protect is the accounts around the site, and the scripts it loads from other companies.
Four questions to see whether it reaches your site.
- 01
Does it run WordPress, WooCommerce, Joomla, Drupal or Magento?
Then it runs on PHP and stays exposed until your host updates PHP. If your address followed by /wp-admin/ shows a login page, it is WordPress.
- 02
Is it on Shopify, Squarespace, Wix or Webflow?
Then the platform patches its own servers and you have nothing to update. Apps you add run on their makers' servers, and they patch those.
- 03
Is it pre-rendered?
Built ahead of time as files with SvelteKit, Astro, Hugo or similar, it has no PHP on the live site. Headless WordPress is the exception: the WordPress behind it still runs PHP.
- 04
Does anything else on your hosting run PHP?
An old blog, a staging copy, a booking script or a forgotten subdomain is attacked like the main site. The ACSC's first advice was to find every place PHP runs.
Not sure what your site runs? Whoever built or hosts it can tell you, and so can we.
If your site runs PHP, seven things to do this week.
- 01
Find the PHP version.
In WordPress: Tools, Site Health, Info, Server. Fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12; anything older is exposed unless your host says otherwise.
- 02
Ask your host, in writing.
Wordfence suggests: is the PHP service serving my site patched for CVE-2026-109618 and CVE-2026-109619, and has PHP been restarted? Keep the reply.
- 03
Move off PHP 8.1 or older.
The PHP project no longer fixes them, and 8.2 stops getting fixes on 31 December 2026. Ask for 8.3 or 8.4, tried on a copy first, because old plugins can break.
- 04
Patch every copy, not just the main site.
Staging sites, old subdomains and other sites in the same hosting account need the same update.
- 05
Keep the logs and a backup.
Ask the host to keep the server logs from 19 October until the patch, and a backup from before. They are the evidence if anything turns up.
- 06
Look for signs of a break-in.
Admin users nobody created, plugins nobody installed, files named wp2s.php or php2shell.php, and pages that send visitors elsewhere. Any of them means calling your host that day.
- 07
Change the passwords if PHP stayed unpatched.
The flaws can leak what the server holds in memory, keys included. After days unpatched, change the database, admin, hosting and email passwords.
Keep WordPress, plugins and theme updated too: the July attacks came through both.
Pre-rendered or WordPress, when the next alert lands.
| Compared on | Pre-rendered | WordPress |
|---|---|---|
| What answers a visit | Pre-rendered A finished file, sent from the CDN server nearest the visitor. No program runs to build the page | WordPress PHP and the database build every page a cache does not answer, and attack requests are made to skip the cache |
| PHP2Shell, October 2026 | Pre-rendered Nothing to reach. There is no PHP on the live site | WordPress Exposed until the host updates PHP. A fully updated WordPress does not help |
| wp2shell, July 2026 | Pre-rendered Nothing to reach. There is no WordPress on the live site | WordPress A flaw in WordPress itself, attacked from 17 July, fixed in 7.0.2, 6.9.5 and 6.8.6, by hand where automatic updates were off |
| Plugin attacks, July 2026 | Pre-rendered No plugins. Forms, search and bookings are services run by their makers, or small functions built for the site | WordPress Most of the 17 flaws on the ACSC's list were in WordPress plugins, used to plant backdoors on small Australian businesses' sites |
| A login page | Pre-rendered None on the site itself. Editors sign in to CloudCannon or Sanity, which run the sign-in | WordPress /wp-admin/ on every site, the first address bots try, and only as strong as the weakest admin password |
| Who has to act, and how fast | Pre-rendered Nobody, for this kind of flaw. The CDN company patches its own servers | WordPress The host for PHP, and you or your developer for WordPress, plugins and theme, within hours of each alert |
| If someone gets in | Pre-rendered A stolen editor login lets them change what the pages say. Published versions are kept, so the last good one can go back up | WordPress They can run code on the server, read the database password and customer records, and leave a backdoor that outlives the patch |
On security, pre-rendered: the parts that get attacked are not on the site. WordPress can be kept safe, but only by somebody who acts the same day, every time a flaw like this is found. That is why we don't build on WordPress, and why so many of our clients came to us to leave it.
What can still go wrong on a pre-rendered site.
- 01
A stolen login.
The editor, hosting, code and domain each have a login, plus the email that resets them. Two-factor sign-in on every one, a passkey where offered.
- 02
The domain.
Whoever controls the domain decides where visitors go. A registrar lock and two-factor sign-in make a takeover much harder, on any platform.
- 03
Scripts from other companies.
Chat widgets, trackers and tag managers run on every page. In June 2024 polyfill.io, a script on more than 100,000 sites, began redirecting visitors after its domain was sold.
- 04
The building blocks of the code.
Sites are built from shared JavaScript packages. In September 2025, 18 popular ones were swapped for malicious copies for about two hours, so versions stay locked and updates are reviewed.
- 05
Anything that runs on a server.
A contact form, a members' area or a checkout puts code back on a server. On our builds that is a hosted service such as Shopify's checkout, or a small function on Cloudflare.
All five apply to a WordPress site too, on top of the table above.
Staying on WordPress safely, or leaving it, priced.
From the cheapest fix to the one that ends the patching. Security plans in US dollars, read on 24 October 2026; the build figures are ours, ex GST.
| Cost | Option | What it covers |
|---|---|---|
| Cost $0 Your host updates PHP | Option Included with managed WordPress hosting and most shared hosting, because the host controls PHP. Ask for the version and the date in writing. | What it covers Fixes PHP2Shell. The site still runs PHP, WordPress and plugins, so the next alert asks the same question. |
| Cost US$149 a year A security plugin with live rules | Option Wordfence Premium: firewall rules and malware signatures as they are written. The free version gets them 30 days later. | What it covers Blocks known attacks inside WordPress. Some PHP2Shell attacks start before WordPress loads, so it does not replace the PHP update. |
| Cost US$229–1,250 a year Clean-up and response cover | Option Sucuri: US$229 to US$549 a year with unlimited malware removals, a reply within 30 to 6 hours by plan. Wordfence Care, US$590, or Response, US$1,250 with a one-hour reply day and night. | What it covers Someone to clean up after a break-in, fast. Not the hours the site was down, or what customers saw. |
| Cost about $99 a month A WordPress care plan | Option Australian entry plans cover updates, backups and uptime monitoring. Ask whether security alerts and the server's PHP version are part of it. | What it covers A named person on the alerts, if the plan says who and how fast. |
| Cost $9,000–18,000 once A pre-rendered rebuild Ours | Option SvelteKit or Astro on Cloudflare, edited in CloudCannon or Sanity, every old address redirected. The Australian market range is $5,000 to $15,000. | What it covers No PHP, database, plugins or public login left to patch, so the next alert needs nothing from you. |
Who keeps websites patched in Australia, and what to ask them.
- 01
Which PHP version serves my site, and when was it patched?
In writing, with the date. A host that cannot answer within a day is telling you something.
- 02
Who reads the security alerts, and how fast do they act?
A name and a time, not a policy. The ACSC says AI is shrinking the gap between a flaw going public and the first attack.
- 03
What else in my hosting account runs PHP?
Old subdomains, staging copies and test installs get attacked like the main site, and are rarely on anyone's list.
- 04
When did you last restore a backup?
Not take one: restore one. A backup nobody has tried is a hope.
- 05
Who has an admin login, and is two-factor on for each?
Former staff and old agencies included. The weakest login is the one that gets used.
- 06
We do.
Croissant & Baguette is a small studio with a network of Australian specialists. Built in Australia, never offshored. We don't build on WordPress, and none of the sites in our portfolio runs PHP, so none needed a patch for PHP2Shell. We move businesses off WordPress with every old address redirected.
A 20-minute look at your site tells us what it runs on, whether PHP2Shell reaches it, and what we would do about it.
What we charge.
- Website build static, pre-rendered, designed from scratch
- from $9,000 typically $9–18k
- Content migration off WordPress or another platform
- quoted typically $1–4k
- Care plan monitoring, updates, small changes, monthly performance snapshot
- from $250/month
What moves the price within those ranges:
- the number of page templates, not the number of pages
- the amount of content to move, and the number of old addresses to redirect
- which plugins the site relies on, and which become services or built features
- connections to other software, such as a CRM, bookings or payments
Why we stopped building on WordPress
Because most of what a WordPress site costs comes after launch. Every plugin, theme and PHP update has to be applied, and in 2026 that meant acting within hours of a government alert, twice. A pre-rendered site costs about the same to build and needs none of that afterwards, so the care plan becomes a choice.
Fixed quote after a 20-minute call. Bug fixes and critical updates are included for the first 12 months.
What is PHP2Shell?
PHP2Shell is the name for two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619, announced on 20 October 2026 and fixed the next day. Both let an attacker run code on a web server without logging in. Researchers at Calif, OpenAI and Wiz found them with AI models, in code going back to PHP 5.4 from 2012, and several governments took websites offline while they patched.
Is my WordPress site affected by PHP2Shell?
Very likely, until your host has updated PHP. WordPress runs on PHP, and researchers showed the attack working against WordPress, Drupal and Joomla. In Tools, Site Health, Info, Server, PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 or later is fixed. An older number can still be safe if your host patched it, so ask them in writing.
Does updating WordPress fix PHP2Shell?
No. The flaws are in PHP, the language WordPress runs on, not in WordPress, a plugin or a theme, so the WordPress update screen cannot reach them. The fix is a new PHP build installed by whoever runs the server, which on most hosting is your host. Until then, a fully updated WordPress site is as exposed to PHP2Shell as a neglected one.
Are Shopify, Squarespace and Wix sites affected?
Not in any way you need to fix. Shopify, Squarespace and Wix run and patch their own servers, and Shopify is not built on PHP. What you add can live elsewhere: apps and embedded tools run on their makers' servers, and an old blog on your own hosting may run PHP. Check those; the platform itself is its makers' job.
Can a static website be hacked?
Not the way a WordPress server can, because no program runs behind its pages: a static or pre-rendered site is finished files on a CDN. What can be attacked is the accounts around it (the editor, the hosting, the domain and the email that resets them) and any scripts it loads from other companies. Two-factor sign-in and a short list of scripts cover most of that.
Is WordPress secure?
It can be, if somebody keeps it that way. WordPress updates itself and is well maintained, but most sites add plugins, and Patchstack logged 11,334 new WordPress vulnerabilities in 2025, nine in ten of them in plugins. In 2026 the ACSC issued two critical alerts that reached WordPress sites. A secure WordPress site has a named person who acts on each one within hours.
What should I do if my website has been hacked?
Tell your host first, and keep a copy of the site and its logs before anything is cleaned: they show how the attacker got in. Our guide to what to do when a WordPress site is hacked has the rest in order, from passwords and the clean-up to lifting Google's warning, calling the ACSC and checking whether the OAIC needs to know.
Sources
Read on 24 October 2026; the PHP and ACSC pages carry the latest.
- 01 Security advisory: critical remote code execution vulnerabilities, update now PHP · 21 October 2026, fixed versions and stopgaps
- 02 Critical vulnerabilities in PHP ASD's ACSC · 21 October 2026, reviewed 22 October
- 03 Large-scale exploitation campaign targeting website content management systems (CMS) ASD's ACSC · 9 July 2026
- 04 Why it's urgent to update PHP on your WordPress site Wordfence · 21 October 2026
- 05 Attacks on PHP2Shell continue, but no known compromises as a result yet Wordfence · 22 October 2026
- 06 php2shell: frequently asked questions Tenable · the timeline
- 07 Who found the PHP bug that made governments unplug their websites? Decrypt · how the flaws were found
- 08 Critical wp2shell WordPress flaws exploited to install webshells BleepingComputer · July 2026
- 09 Usage statistics of PHP for websites W3Techs · 24 October 2026
- 10 WordPress statistics WordPress.org · PHP versions in use
- 11 State of WordPress Security in 2026 Patchstack · 2025 figures
- 12 Polyfill.io JavaScript supply chain attack impacts over 100K sites BleepingComputer · June 2024
- 13 Widespread npm supply chain attack Wiz · September 2025
- WordPress or pre-rendered? Speed, running cost and security side by side, and why we left WordPress.
- Running costs. What each kind of site costs to keep each year, at renewal prices.
- Hacked? What to do, in order, when a WordPress site has been hacked.
- Leaving WordPress. Every page moved across, every old address redirected, and nothing left to patch.