A website can be central to customer enquiries while the software behind it receives little attention between updates. In October, two critical PHP vulnerabilities made that gap an urgent concern for Australian and New Zealand businesses. Owners needed to establish whether their websites used PHP, who was responsible for maintaining it and whether the fixes had been applied.
PHP generates content on web servers. WordPress relies on it, as do many other applications. A business can therefore depend on PHP without anyone in the office having chosen it directly or knowing which version the hosting provider runs.
The immediate response is to establish exposure, patch and check for compromise. Beyond that, these vulnerabilities raise a useful design question: how much publicly exposed software does your website actually need?
What happened in October 2026?
The Australian Cyber Security Centre's alert, published on 21 October and reviewed on 22 October, urged organisations to identify PHP, apply updates and monitor for suspicious activity. New Zealand's NCSC followed with advice for small businesses on 23 October, asking owners to contact developers and hosting providers about updates and security checks.
The two flaws are in PHP itself, rather than a particular WordPress plugin:
- CVE-2026-109618 involves memory becoming invalid when PHP encounters an out-of-memory condition. Subsequent request cleanup can process that invalid memory.
- CVE-2026-109619 involves internal state surviving after the memory it refers to has been released. Another request handled by the same worker can then use that stale state.
Both can allow unauthenticated remote code execution: an attacker running code on the server without first logging in. That code runs with the web worker account's permissions; this does not automatically mean unrestricted control of the entire host. Depending on those permissions and the application, consequences could include altered pages, stolen accessible data or disruption.
PHP's guidance covers installations serving web requests, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed. Exploit conditions differ. The PHP team identifies mod_php as the highest risk, with a demonstrated attack before application code runs. The out-of-memory advisory identifies PHP-FPM as susceptible, while stating that a complete FPM exploit had not been demonstrated for that flaw. A successful laboratory exploit also does not establish that a particular business has been compromised.
Fixed versions and subsequent guidance
As checked on 4 November 2026, the PHP project's security announcement lists 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as the fixes. Earlier releases in those branches are affected. Older, unsupported branches need explicit attention: distribution or extended-support vendors may supply backported fixes, but an old version number alone cannot establish patch status. Ask the provider to identify the installed package and its security coverage.
There have been later notices. On 23 October, PHP recommended disabling session upload progress pending a further fix for CVE-2026-115560, involving an unusual combination of configuration and application behaviour. On 26 October it announced Windows package rebuilds, 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1, to address a separate Brotli dependency vulnerability. These notices are available in the PHP news archive. Providers should review the complete current guidance rather than treat the original version list as the whole job.
What is known about exploitation?
The ACSC's reviewed alert states that it was not aware of successful active exploitation in Australia at that time. That is a dated assessment, not a guarantee about subsequent activity.
There is later vendor confirmation of exploitation: Palo Alto Networks' advisory, updated 29 October, reports active exploitation targeting its management interfaces exposed to the internet. The advisory does not identify victim countries, so it cannot establish compromises in Australia or New Zealand. The New Zealand NCSC's 23 October business advisory said it was too early to determine the full impact on New Zealand organisations.
For an affected business, patching and investigation belong together. An update closes a vulnerability; it does not establish whether someone used it beforehand or remove access an attacker has already established.
How much technology does a small-business website need?
Consider a professional services website with a homepage, service descriptions, an about page, contact details, occasional articles and an enquiry form. Most of its content is the same for every visitor.
A dynamic CMS can provide useful editing tools for those pages. It also brings an application that needs to run, an administrative interface to protect and, commonly, a database. Those responsibilities continue between content updates.
My earlier article, Why WordPress Is Outdated for Most Small Businesses, examines that suitability question in more detail. The October PHP disclosures add a concrete operational example: a component can need urgent maintenance even when the business has made no changes to its pages.
A simpler approach is to generate the pages before publication. Content changes pass through a controlled build and deployment process, and visitors receive the finished files. Eleventy is one tool that supports this approach. The important decision is separating content preparation from public delivery; the particular generator comes afterwards.
Dynamic and static delivery: what changes?
A dynamic website executes server-side application code to handle requests. It may use plugins, themes and a database, alongside an administration system. Caching can reduce that work, but does not necessarily remove the application or its exposed endpoints.
A static website serves prebuilt HTML, CSS and JavaScript directly from a web server or content delivery network. If its public hosting does not run PHP, a PHP runtime flaw has no PHP process there to exploit. Retiring the old CMS, database and login endpoints can remove those parts of the public attack surface: the functionality an attacker can reach and try to misuse.
That benefit depends on the whole design. Keeping an old WordPress installation reachable behind a new static front end leaves software to secure. A contact form still needs a processing service, and that service needs protection. External booking, payment and account systems introduce dependencies of their own.
Static sites can still be compromised through hosting access, stolen deployment credentials, vulnerable build dependencies or connected services. DNS, infrastructure updates, backups and recovery arrangements still matter. Simpler architecture reduces particular exposures; it does not eliminate security work.
The next architectural question is what a compromised service can reach. My article on system isolation and network segmentation examines limiting access between business systems, using the reported NSW Health incident as a reason to review those boundaries.
Software updates are only part of the responsibility
For a dynamic website, someone needs to maintain the CMS, plugins, themes and PHP runtime, alongside the hosting environment. Backups need protection and restoration checks. Administrative accounts need appropriate access controls, including multi-factor authentication where available. Logs and alerts need someone who will act on them.
Outsourcing can put that work in capable hands. It still leaves the owner needing a clear agreement about coverage, response times and evidence that the work has happened. “Managed hosting” is too vague if nobody can explain whether it includes PHP updates, application updates and compromise investigation.
As I discuss in outsourced IT and third-party cyber security risk, the practical task is to establish who does what and how it is checked. Ask for confirmation of the fix actually installed, rather than accepting that an update was merely scheduled.
When a dynamic website makes sense
Customer accounts, live transactions, personalised content and complex publishing workflows can justify server-side applications. A well-maintained WordPress site may be an appropriate choice where its editing features and ecosystem meet real requirements.
Some businesses can combine static information pages with a carefully selected booking or payment service. Others need an integrated application. Compare security, privacy, accessibility, reliability, editing needs and ongoing cost across the complete arrangement. Moving functionality to an external API changes who operates it; it does not remove the dependency.
An urgent patch should never wait for a redesign proposal. Make the existing system safe, investigate where necessary, and assess replacement architecture as a separate planned decision.
Five questions to ask your website provider
- Does our website require PHP or another server-side application? Ask which components run publicly and what business requirement each serves.
- Who is responsible for security updates? Include the application, plugins, themes, runtime and host, with agreed response times for critical flaws.
- How do you monitor vulnerabilities and possible compromise? Ask who reviews alerts, what evidence is retained and what triggers investigation.
- Can unnecessary components be removed? Review unused plugins, old installations, administrative interfaces and services, including anything left after a migration.
- Could a simpler architecture meet the same requirements? Include content editing, forms, integrations and recovery in the comparison.
Security begins with architecture
Patching is essential. Choosing which software must remain exposed to the internet is also a security decision, made long before the next advisory arrives.
For a straightforward business website, removing an unnecessary application can mean fewer components requiring emergency attention. For a complex service, the right answer may be a maintained dynamic platform with clearly assigned responsibilities.
Solway Web Consulting starts with what the business needs its website to do, then chooses an appropriate publishing and hosting arrangement. If you want to understand your current exposure or assess a simpler replacement, contact Solway Web Consulting to discuss a website security review.
Tags: security, static-sites, wordpress, small-business, australia