PHP2Shell: what Australian organisations need to do now

PHP is the programming language used by about 70% of websites whose technology can be identified. WordPress, Drupal, Joomla and Moodle are all built on it. The two flaws, known together as PHP2Shell, let someone on the internet run their own commands on an affected server. From there they can change your website, steal data held on the server or use it to reach other systems.

In a business of a few dozen to a few hundred staff, PHP is rarely something the IT team thinks of as theirs. It usually sits in the public website, customer portals, booking and enquiry forms, intranets and learning platforms, often run by a web agency or hosting provider. That is why this needs a decision from management, not only a ticket for IT.

Three things to do today:

1. Get written confirmation. Ask whoever runs each of your websites and web applications to confirm in writing, by Friday, that PHP has been updated to a fixed version, or that PHP is not used.
2. Deal with anything that cannot be updated. If a system runs PHP 8.1 or older and no vendor fix is available, take it offline or restrict who can reach it until it is upgraded.
3. Ask whether anyone got in first. Updating closes the door. It does not tell you whether someone came through it before it was closed.

The Essential Eight, the Australian Government's baseline for cyber security, expects critical flaws in internet-facing services to be fixed within 48 hours of the fix being released. For this flaw, that is about 1am AEDT on Saturday 24 October.

Details of the flaws leaked before their planned release date, so PHP brought its fix forward. The Australian Signals Directorate's Australian Cyber Security Centre (ACSC) issued a Critical alert on 21 October, before the fix existed. It said all PHP versions from PHP 5 onwards may be affected. PHP released the fixed versions at 1am AEDT on 22 October. The ACSC reviewed its alert the same day. It now recommends that organisations identify where they use PHP, apply the security updates and other appropriate mitigations, and monitor PHP applications for suspicious activity.

Governments took websites offline as a precaution while they prepared. In Australia, the Australian Signals Directorate confirmed outages to government websites, including its own, cyber.gov.au.

The flaws were found with the help of artificial intelligence. The security firm Calif found the first in August using an OpenAI model, during an audit of PHP funded by OpenAI. Wiz, a security company owned by Google's parent Alphabet, used its own AI research tool and models from Google and OpenAI. Wiz says the flaws had been hidden in PHP's code for more than a decade.

On attacks: several security companies, including watchTowr and Cloudflare, report attempts to use the flaws. At the time of writing, CISA had not confirmed attacks, and neither flaw was on its list of vulnerabilities known to be in use. We recommend planning on the basis that attacks are under way.

You are affected if any website or web application you own runs a version of PHP older than the fixed versions. That includes systems run for you by an agency, a hosting provider or a software vendor.

Common places PHP sits in a mid-sized organisation:

• The public website, especially on WordPress, Drupal or Joomla
• Customer and member portals, online forms and booking systems
• Intranets, staff portals and learning platforms such as Moodle
• Online shops, including Magento and WooCommerce
• Old campaign sites, test copies and staging sites that are still online

Updating WordPress, its plugins or its theme does not fix this. The flaws are in PHP itself, underneath those products.

1. Find every PHP installation. List every website and web application, including test and staging copies. For hosted sites, ask the provider. For servers you manage, check the version the web server actually uses, not only the command-line version, because the two can differ.
2. Update to a fixed version. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On Linux, the version number may not change, because vendors often add the fix to their existing package. Check the package's change log for CVE-2026-109618 and CVE-2026-109619. Restart PHP and rebuild any container images afterwards, or the old code keeps running.
3. If you cannot update today. For PHP 8.1 or older, ask your host or operating system vendor whether they have released their own fix. If they have not, take the system offline or restrict access to known users until it is upgraded. Configuration changes circulating online reduce some routes of attack but do not close the flaws. PHP's position is that updating is the fix.
4. Check whether anyone got in before you updated. No official signs of compromise had been published at the time of writing. Until they are, look for new or changed files in website folders, administrator accounts you do not recognise, new scheduled tasks, unexpected programs run by the web server, and connections from the web server to unfamiliar addresses.
5. Plan the upgrade for anything old. PHP 8.2 stops receiving security fixes on 31 December 2026. Anything on 8.2 or older should be upgraded this quarter, not after the next emergency.

• Contain, do not wipe. Take the affected system offline and keep its logs. Rebuilding straight away destroys the evidence you need to work out what was taken.
• Report it. Report to the Australian Signals Directorate through ReportCyber at cyber.gov.au/report, or call the government's Australian Cyber Security Hotline on 1300 CYBER1 (1300 292 371).
• Check your privacy obligations. If personal information may have been accessed and your organisation is covered by the Privacy Act, the Notifiable Data Breaches scheme may require you to notify the Office of the Australian Information Commissioner and the people affected. If you suspect a breach but are not sure, you must take all reasonable steps to assess it within 30 days.
• Tell your insurer early if you hold cyber insurance, and check what your policy requires you to do and by when.

A flaw hidden for more than a decade was found with AI, and attack attempts were reported within hours of the details leaking. The time between a flaw becoming known and it being used is shrinking. How quickly you fix internet-facing systems is now a measure of business risk, not an IT housekeeping task.

Two questions every leadership team should be able to answer: how many internet-facing systems do we have, including those run by third parties? And how long does it take us to fix a critical flaw in them?

PHP security release · ACSC alert · ReportCyber · OAIC Notifiable Data Breaches · Essential Eight maturity model