The Australian Signals Directorate's Australian Cyber Security Centre has issued a critical PHP alert before the scheduled release of security patches. For businesses running WordPress or other PHP applications, the immediate work is finding out what is running and who will update it. There is no need to wait for technical details to make those checks.
Developing story: This article was first published on 21 October 2026, ahead of the scheduled PHP security release. Details may change as official technical information becomes available.
PHP sits underneath many websites, often outside the part their owners manage themselves. That makes the warning significant even for a business whose website appears to be working normally. It does not establish that every PHP installation is remotely exploitable, or that a particular website has been compromised.
What the Australian warning actually says
The ACSC alert, published on 21 October, says disclosure is scheduled for 01:00 AEDT on Thursday 22 October 2026. It identifies CVE-2026-109618 and CVE-2026-109619 through media reporting, while noting that official technical details were not yet public.
The ACSC understands that PHP versions from PHP 5 onwards may be affected. That is a provisional assessment of potential scope, rather than a confirmed affected-version matrix. At the time of its alert, the ACSC was not aware of active exploitation. Its advice is to identify PHP installations, prepare for patching and monitor for malicious activity.
Separately, the PHP security team's advance announcement confirms two critical vulnerabilities, each rated 9.2 under CVSS v4.0. The scheduled release time of 14:00 UTC on 21 October converts to 01:00 AEDT the following morning. PHP says it may release earlier if vulnerability details become public or evidence of active exploitation emerges. Check for updates before the scheduled release time too.
The PHP announcement leaves affected and fixed versions, and the technical explanation, for the release itself. A severity score alone cannot tell an administrator whether their particular configuration is exploitable.
WordPress updates and PHP updates are different jobs
WordPress requires PHP to run its server-side application. Updating WordPress Core, themes and plugins does not, by itself, update that underlying runtime. A dashboard showing no outstanding WordPress updates can still leave the hosting environment needing attention.
On shared hosting, the provider generally controls PHP packages and the available runtime versions. A managed WordPress service may handle that work too, but the service agreement matters. Ask which PHP runtime your site uses, whether the provider has assessed this alert and how it will confirm the relevant fix has reached your account.
On a VPS, responsibility may sit with the business, its developer or a separate server administrator. Confirm whether your hosting agreement covers PHP security patches or whether your administrator needs to apply them. “The hosting is paid for” tells us very little about who monitors security releases after hours.
This is a PHP warning with implications for WordPress, rather than confirmation of a new flaw in WordPress Core. The earlier WordPress template-handling vulnerability involved a different component and its own exploitation conditions.
Look beyond the main website
The inventory should include PHP contact forms, custom applications, e-commerce software, administrative interfaces and containerised services. An old application on a forgotten subdomain deserves attention even if the current marketing website uses something else.
A site built with static HTML, Node.js or Python is not automatically affected because PHP happens to be installed elsewhere on the server. The relevant questions are whether an application executes PHP, whether vulnerable functionality is reachable and what conditions the official disclosure establishes. Another application on that machine may still create exposure.
I would check the actual request path rather than rely on the technology named in a website proposal. A static frontend can submit a form to a PHP endpoint. A cached WordPress homepage does not prove its dynamic routes are inaccessible.
Exploit reports need careful reading
CERT-EU's advisory discusses possible remote code execution, explicitly referring to leaks in its summary. That is a serious reported consequence, but the initial PHP announcement does not yet provide the technical conditions needed to establish exposure for an individual installation.
iTnews reports that alleged vulnerability details and two proof-of-concept exploits appeared before coordinated disclosure. It also says it had not independently confirmed that those proofs of concept worked. Their circulation adds urgency, but does not establish that attacks have succeeded.
Premature disclosure can narrow the time defenders have to prepare. It can also put incomplete or incorrect technical advice into circulation. Proposed mechanisms and unofficial fixes still need verification.
Tenable’s report reproduces a 21 October statement from Cloudflare CTO Dane Knecht reporting early attacks and describing its firewall mitigations as a stopgap. That is a report of attack activity, not confirmation that targeted systems were compromised. The original social post could not be retrieved directly for this article.
The ACSC's statement describes what it knew when it issued the alert. Keep checking for updates and preserve relevant logs as further reports emerge.
What website owners and technical teams should do now
- Inventory PHP installations and versions. Include production, staging, scheduled jobs, appliances and containers. Check the runtime serving the application; a command-line PHP version may differ from the web runtime.
- Identify public-facing PHP applications. Record the host, application owner and maintenance contact. Check secondary domains and older services as well as the main site.
- Confirm the hosting provider's arrangements. Ask who applies runtime patches, whether a restart or account-level change is required, and how completion will be verified.
- Monitor official release and vendor guidance. Follow PHP and the security advisories for the distribution or product actually supplying your packages. Avoid selecting a purported fixed version from an unattributed post.
- Prepare recoverable backups and a maintenance procedure. Know how to check the application after the update and who can address a failure. If a rollback restores vulnerable software, reassess whether the service can remain publicly accessible.
- Review and preserve logs. Look for unusual requests, unexpected application errors, file changes or processes. These are general investigation leads, not confirmed indicators for these CVEs. Escalate suspicious findings rather than assuming patching resolves a possible compromise.
- Apply verified fixes promptly when available. Confirm the running service uses the patched package, complete any vendor-required restarts and test important functions such as logins, forms and checkout.
Distribution packages need particular care. Ubuntu, Debian and other distributions may backport a security fix while retaining the upstream version number. The Debian security FAQ explains why a package can look old while containing the relevant fix. Compare the complete package revision and changelog with the applicable vendor advisory. Do not assume that a backport for these vulnerabilities exists until the vendor confirms it.
For Docker deployments, updating the host operating system does not necessarily replace PHP inside an application container. Docker recommends rebuilding images to incorporate updates. Obtain or rebuild an image containing the verified fix, redeploy it and check what the running container actually contains. Merely restarting an old container does not give it a new runtime.
Where immediate remediation is not feasible, the UK NCSC advises considering taking the system offline until it can be fully mitigated. CERT-EU similarly recommends considering isolation of internet-facing applications. That requires a decision about the service's exposure and business impact; an unverified configuration change should not be treated as equivalent to a confirmed fix.
Patching also needs to remain separate from investigation. As the Mathspace incident illustrated, closing a vulnerability does not establish whether someone used it beforehand.
What happens after disclosure
This article will be updated after official technical details and patched packages become available. The next report needs to establish the affected configurations, the fixed releases and whether authoritative evidence changes the exploitation picture. Distribution packages and container images will need checking alongside upstream PHP releases.
Before the release, confirm who will check the PHP advisory and arrange the update. Ask them to verify the running PHP version or package revision afterwards and test the site’s main functions.