PHP2Shell: Your Website Is the Easy Part. What Else Should You Check?

On Thursday morning we pointed a customer's domain away from their web server. Their site runs on PHP, and the fix for PHP2Shell could not go on straight away. Until it could, we did not want anyone reaching that site by name.

The question we are hearing this week, from practice managers and office managers alike, is simpler: the website has been updated, so are we done? Not yet. The website is usually the easy part.

What happened

PHP2Shell is the nickname for two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619. PHP is the language under WordPress, Joomla, Drupal and a long list of web tools. The flaws can let someone with no login run their own code on the server. The fix landed at 1am AEDT on 22 October, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Amazon's threat researchers saw the first attempt on 17 October, before the fix existed. Cloudflare has since counted attempts in the millions. Most have failed so far, and at the time of its alert the ASD was not aware of a successful attack in Australia. So it calls for a prompt check, not alarm.

How urgent is this?

It depends on what faces the internet. Attacks come in over the web, so that is where the risk is.

• This week: your website, and anything else online that runs PHP. These are what attackers are scanning for. Ask your host or web developer to confirm the fix. Many hosts patch this kind of flaw automatically, so the answer may already be yes.
• In the normal course of things: software and devices inside your office. The risk is lower, because an attacker would first need to be on your network. Your IT provider can check these as part of routine maintenance.
• Only if something looks wrong: the privacy steps. Most businesses will not need them.

If you need to take a site offline

If your host cannot patch your website within a day or two, taking it offline until they can is a sensible precaution. Pointing the domain at a holding page is quick and easy to reverse. If you have an hour's notice, lower the record's TTL first, so the change spreads faster.

DNS has a limit, and it is the part most people miss. The server is still on the internet at its IP address, and attackers scan IP addresses, not just domain names. Repointing hides the front door. It does not lock it.

So also stop the site at the host, or block web traffic to it at the firewall. And expect some visitors to keep reaching the old server for a while, until their DNS caches expire.

Where else PHP lives in your business

Updating WordPress or its plugins does not fix this. PHP itself has to be updated and restarted, wherever it runs. Most businesses will have only one or two of these:

• Your website, and anything bolted onto it. Online booking, enquiry and new-patient forms, client portals, online shops. Ask who runs the server, not who built the site.
• Hosting control panels. cPanel and Plesk run on PHP. Ask your host to confirm those are patched too.
• Windows software that bundles PHP. Some programs ship their own copy of php.exe. Your IT provider can ask the vendor whether it is affected.
• NAS boxes, firewalls and other devices with a web admin page. Your IT provider can check each vendor's advisory.
• Old tools nobody uses any more. A retired client portal or a test site that is still online is still a server.

Your core software, whether practice management, accounting or job management, is unlikely to be the weak point. It is still worth a quick check. Your IT provider or practice manager can confirm it with the vendor.

Once it is patched, there is a separate question about whether your website is worth rebuilding.

After the patch: how to know you are clean

For a website or server that faces the internet, it is worth confirming nobody got in before the fix. Your host or IT provider can run these checks for you:

1. Confirm the fix is installed and PHP has been restarted. The version number alone is not proof, because some hosts patch older-numbered versions.
2. Check the logs back to 17 October, not 22 October. That is when the first attempts were seen.
3. Look for new files in the website folders, new admin users, and new scheduled tasks or cron jobs.
4. If anything looks out of place, change the passwords and API keys the server held: the database, the WordPress admin, and the logins for booking and form integrations.
5. If something is clearly wrong, restore from a backup you know is clean, from before 17 October, and patch it before it goes back online.

If you cannot patch

PHP 8.1 and older get no official fix. If a server is that old, take it off the open internet or put it behind a firewall or web application firewall. Your provider can set session.upload_progress.enabled = Off in PHP's settings as a stopgap, but the PHP team says no setting change fully closes the hole. It is time to plan a move off that server.

If personal information may have been exposed

If the checks do turn up a problem, it is also a privacy question. Dental and medical practices are covered by the Privacy Act regardless of turnover, because they provide a health service. Most other businesses are covered once turnover passes three million dollars, and some smaller ones are covered too.

If you are covered and personal information may have been accessed, the Notifiable Data Breaches scheme applies. Assess it promptly. The thirty days the Act allows is the limit, not a target. If the threshold is met, notify the OAIC and the people affected. The OAIC explains the Notifiable Data Breaches scheme, and practices also have the OAIC's data breach action plan for health service providers. Our guide covers what the Privacy Act requires of a practice.

If you think you have been compromised, call the ASD on 1300 CYBER1 (1300 292 371).

What we did this week

Our own website runs no PHP, so it needed nothing. If you would like a second pair of eyes on your exposure, get in touch. We support dental and medical practices and other businesses across Victoria, and we will tell you plainly what needs doing and what does not.