Critical PHP Security Update: What Australian Businesses Should Do

If your business website uses PHP, arrange an urgent version check and security update now. On 22 October 2026, the Australian Cyber Security Centre (ACSC) updated its critical alert after patches were released for two PHP vulnerabilities that can allow unauthenticated remote code execution. The PHP project says updating is the only complete solution.

This matters to Australian businesses because PHP runs many websites and web applications, including a large share of WordPress sites. It does not mean every website has been compromised. It does mean business owners should confirm who manages the server-side PHP version, which version is running and whether the relevant patched release has been installed.

What changed on 22 October 2026?

The ACSC critical PHP alert, first published on 21 October and reviewed on 22 October 2026, says patches are available for two critical vulnerabilities. The alert advises organisations to identify PHP in their environments, review the latest PHP guidance, apply available security updates and monitor related systems for suspicious activity.

The PHP project security advisory identifies the vulnerabilities as CVE-2026-109618 and CVE-2026-109619. It says they can allow unauthenticated remote code execution and affect PHP installations serving web requests through common configurations, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

In plain English, a vulnerable internet-facing PHP environment may allow an attacker to make the server run unauthorised code without first signing in. The practical response is to patch the PHP runtime supplied by the host or server administrator—not simply update a WordPress plugin and assume the work is complete.

Which PHP versions contain the fixes?

The PHP project released the following fixed versions on 21 October 2026:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.1 and older no longer receive normal updates from the PHP project. Some Linux distributions and long-term-support vendors may provide backported fixes, so the visible version number alone may not tell the whole story. Ask the hosting provider whether its package includes the fixes for both CVE numbers. If the site is on an unsupported branch, plan a tested move to a supported version rather than treating an emergency workaround as a long-term maintenance strategy.

The PHP project also notes that PHP 8.2 reaches end of life on 31 December 2026. A business updating to 8.2.35 should therefore discuss the next supported branch with its developer or host instead of postponing the upgrade decision indefinitely.

Does this affect WordPress websites?

WordPress is written in PHP, so a WordPress site normally depends on the PHP runtime provided by its hosting environment. The vulnerability sits below the WordPress dashboard: updating WordPress core, a theme or a plugin does not by itself update the server’s PHP package.

Whether a particular site is exposed depends on its server configuration, PHP package and vendor patch status. Managed hosts may apply security updates centrally. Self-managed virtual servers and older hosting accounts may require direct action by an administrator. Business owners should verify the result rather than assume that “automatic updates” covers every layer.

For the wider routine behind this urgent check, use DanSol’s WordPress maintenance checklist for Hobart businesses. The current alert is a time-sensitive infrastructure task; the checklist covers the recurring backups, updates and functional checks that make urgent work safer.

A practical response plan for Australian small businesses

1. Find out whether the website uses PHP

Ask the person responsible for the website or hosting account. If the site uses WordPress, WooCommerce, Drupal, Joomla, Laravel or a custom PHP application, PHP is likely part of the stack. Do not install an unknown “version checker” plugin just to answer the question.

WordPress administrators can often see a PHP version under Tools > Site Health > Info > Server, but the hosting provider remains the best source for package and backport status. Never publish diagnostic screens, server headers or configuration files containing internal details.

2. Identify who owns the update

Responsibility varies by setup:

• Managed WordPress hosting: ask the host to confirm the fixed PHP package and deployment time.
• Shared hosting: check the provider’s security notice or support channel and confirm which PHP branch the account uses.
• Cloud or virtual server: the server administrator should review the operating-system vendor package, install the security update and restart affected services.
• Agency-managed website: ask whether infrastructure patching is included in the agreement or remains with a separate host.
• Custom application: coordinate the runtime update with the developer and test application compatibility.

If several suppliers are involved, nominate one person to coordinate the answer. “The host handles security” and “the developer handles the website” can leave a gap unless the PHP runtime is explicitly assigned.

3. Confirm a recoverable backup

Before making a production change, confirm there is a current backup of the database and website files and that the business knows how restoration would work. High-change sites may need a fresh backup immediately before the update. An ecommerce store should also consider orders and customer activity that could occur between backup and deployment.

A backup should support recovery, not delay a critical patch unnecessarily. The goal is a controlled update with a rollback path. DanSol’s guide to website maintenance services in Hobart explains what to expect from backups, updates, monitoring and incident response.

4. Test compatibility without postponing the fix

Moving between PHP branches can expose old code, unsupported plugins or deprecated functions. Where possible, test the target fixed version in staging, prioritising the functions customers rely on. Testing should be proportionate and rapid because the official advice is to update immediately.

Check at least:

• the home page and main service or product pages;
• contact, quote and registration forms;
• login and account functions;
• search, filters and downloads;
• booking, cart, checkout and payment flows;
• email notifications and confirmation pages;
• scheduled jobs and third-party integrations; and
• application and server error logs.

An old component that fails on a supported PHP release is a maintenance risk in its own right. Replace or repair it through a scoped change; do not leave a critical runtime unpatched merely to preserve an obsolete plugin.

5. Apply the correct vendor update

Use the update channel appropriate to the environment. A managed host may deploy its own package. A Linux server may receive a patched build from its distribution or long-term-support vendor. A custom environment may move to one of the fixed upstream releases.

Ask for evidence that covers both CVE-2026-109618 and CVE-2026-109619. Useful evidence could include the installed package version, vendor advisory, change record and deployment time. Avoid copying generic shell commands from social media: package names, repositories and service controls differ across systems.

6. Restart workers and verify the live site

A package may be installed while old PHP worker processes continue to run. The administrator should follow the vendor’s instructions to restart or reload the relevant service, then verify the active runtime. Afterwards, repeat the priority customer journeys and inspect error and security monitoring.

For a Hobart accommodation operator, that means testing availability, booking, payment and confirmation. For a professional-services firm, it may mean submitting an enquiry and confirming that the notification reaches the correct inbox. For an online retailer, use a controlled test order and check stock, tax, payment and email behaviour.

7. Monitor and record the outcome

The ACSC recommends monitoring PHP applications and related systems for suspicious activity. Review web-server, application, authentication and security-tool alerts according to the site’s normal incident process. If there are signs of compromise, preserve relevant records and escalate to a qualified responder rather than immediately deleting evidence.

Record the version or vendor package applied, the date, who completed the work, tests performed and any follow-up items. This creates a useful maintenance history and prevents the same uncertainty during the next critical notice.

What if the PHP update cannot be installed immediately?

The PHP advisory lists temporary measures for particular attack paths, but explicitly says they do not make an installation safe. Those settings are technical, configuration-dependent and may affect application behaviour. They should be evaluated by the server administrator as short-term risk reduction while the complete update is prepared.

If a supplier says the patch must wait, ask for:

1. the reason the fixed package cannot be deployed;
2. the specific interim controls being used;
3. the planned patch time;
4. the monitoring and escalation process; and
5. the recovery plan if the service is affected.

Do not publicly announce unpatched server details. Share technical information only with authorised suppliers and staff who need it.

Questions to send your host or website provider

• Does our live website or any connected application use PHP?
• Which active PHP version and server handler are we using?
• Does the installed package fix CVE-2026-109618 and CVE-2026-109619?
• When was the patch deployed, and were PHP workers restarted?
• Is our current branch supported beyond 2026?
• Was a current recoverable backup confirmed before the change?
• Which customer journeys were tested afterwards?
• Were logs or monitoring reviewed for suspicious activity?
• Are any themes, plugins or custom components blocking a supported PHP upgrade?
• Who owns future server-runtime security updates?

If the answer reveals unsupported code, fragile hosting or unclear ownership, DanSol’s Hobart web design and development service covers WordPress and PHP development that can be scoped around the site’s actual requirements.

Frequently asked questions

Were these PHP vulnerabilities being exploited in Australia?

The ACSC alert said it was not aware of successful active exploitation in Australia related to these vulnerabilities at the time of its review on 22 October 2026. That is not a reason to delay: the alert is rated critical and the patches are available.

Can I fix this from the WordPress dashboard?

Usually not. WordPress core, themes and plugins are separate from the PHP runtime installed by the host or server administrator. You can use Site Health to help identify the reported version, but the runtime update belongs at the hosting or server layer.

Will changing PHP version break the website?

It can expose compatibility problems in outdated themes, plugins or custom code, which is why a backup and focused testing matter. However, leaving a critical vulnerability unpatched also carries serious risk. Coordinate a prompt, tested update rather than choosing between panic and inaction.

Is updating to PHP 8.2.35 enough?

It addresses the two vulnerabilities according to the PHP project, but PHP 8.2 reaches end of life on 31 December 2026. Treat 8.2.35 as an immediate security update and plan a tested move to a supported branch.

Does a managed hosting plan guarantee the fix is installed?

No assumption replaces confirmation. Managed providers often deploy infrastructure security updates, but customers should check the provider’s advisory or support response and verify the active package, especially where a site can select among several PHP branches.

Act now, then fix the ownership gap

The immediate task is straightforward: identify the PHP environment, confirm a recoverable backup, apply the vendor’s fixed package, restart affected services, test critical functions and monitor the result. The broader business lesson is that website security depends on clearly assigned responsibility across the application, hosting and server layers.

Once the urgent update is complete, review DanSol’s practical cyber security guide for Tasmanian small businesses to strengthen account access, backups, staff awareness and recovery planning beyond this single alert.