Critical PHP Security Update: Patch Your Website Now
The PHP project released emergency fixes on 21 October 2026 for two critical vulnerabilities that can allow an unauthenticated attacker to run code on a web server. If your website, portal, online store or internal application uses PHP, this is a runtime update—not a routine CMS plugin task.
The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The PHP project says updating is the only complete mitigation. WordPress has issued an urgent notice, Australia's cyber security authority has published a critical alert, and businesses should verify the live server version rather than assume a host or platform has already completed the work.
This guide is written for business owners, website managers, operations teams and technology decision-makers who need a clear response: find every exposed PHP workload, establish who controls the runtime, patch through a controlled emergency change, test the customer journeys that matter, and retain evidence that the production workers are actually running a fixed build.
Why this PHP security issue is trending now
Both vulnerabilities were publicly disclosed with fixes on 21 October 2026. They are tracked as CVE-2026-109618 and CVE-2026-109619 and each carries a critical CVSS v4.0 score of 9.2.
The urgency comes from the position PHP occupies in the stack. An attacker does not need a WordPress administrator account or an application login to reach the vulnerable runtime in the confirmed scenarios. The PHP advisory covers web-serving installations such as PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The project considers risk highest for mod_php, where unauthenticated remote code execution was demonstrated before application code begins.
The Australian Signals Directorate's Australian Cyber Security Centre has classified the issue as critical and told organisations to identify PHP, apply the official patches and monitor affected environments. That turns a developer release note into a business continuity task for any organisation operating a public PHP website or application.
What business owners need to know
The application brand does not determine exposure; the live PHP runtime and hosting architecture do.
Two critical flaws
CVE-2026-109618 and CVE-2026-109619 can lead to unauthenticated remote code execution under affected conditions.
Four fixed branches
Patch to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, using the package supplied by your trusted platform or operating-system vendor.
CMS updates are separate
WordPress says no WordPress core update is required for these flaws. The vulnerable layer is PHP itself.
Evidence matters
Confirm the version used by live workers after the deployment and restart; a ticket status or control-panel selector alone is not enough.
Which websites and applications should be checked?
Start with every internet-facing service that may execute PHP. This commonly includes WordPress and Drupal websites, custom PHP applications, customer or supplier portals, booking systems, form processors, campaign microsites, ecommerce extensions, legacy administration tools and vendor appliances that bundle PHP.
Do not limit discovery to websites your marketing team actively edits. Old subdomains, retired campaign sites, staging environments exposed to the internet, inherited hosting accounts and small internal tools published through a gateway are frequent blind spots.
The practical test is not “Which CMS do we use?” It is “Which public or connected workloads run a vulnerable PHP build, who can patch each one, and how will we prove the fixed runtime is live?”
Why updating WordPress or Drupal is not enough
A CMS, its plugins and its themes run above the PHP runtime. Applying the latest WordPress or Drupal release remains good security practice, but it does not replace this PHP patch.
WordPress explicitly says the vulnerabilities are not specific to WordPress and that no WordPress update is required or planned for them. For a WordPress site, you can inspect server details under Tools → Site Health → Info → Server. The value must then be checked against the fixed release for its branch.
Drupal sites require an additional compatibility decision. Supported Drupal versions accept different PHP ranges, and modules can depend on particular extensions or packages. Patch within the current compatible branch first where possible, then plan a branch upgrade if the site is on an unsupported or short-lived runtime.
Custom applications need the same runtime fix plus regression tests around their own framework, dependency set and PHP extensions. A runtime-only emergency change can still expose deprecated behaviour or extension mismatches, so testing should focus on the business journeys most likely to fail.
Fixed PHP versions and support decisions
| PHP branch | Minimum fixed release | Business action |
|---|---|---|
| 8.5 | 8.5.12 | Patch immediately and verify the deployed worker version. |
| 8.4 | 8.4.27 | Patch immediately and complete application smoke tests. |
| 8.3 | 8.3.36 | Patch immediately and monitor application and server errors. |
| 8.2 | 8.2.35 | Patch now, then plan a supported-branch move before security support ends on 31 December 2026. |
| 8.1 or older | No upstream point release | Confirm a vendor backport or move to a supported branch; a one-off source backport is not a long-term support plan. |
Use the package or image supplied by the platform, operating-system vendor or hosting provider responsible for your environment. A version string can include vendor-specific backports, so ask for the advisory or package reference that proves the two CVEs are addressed.
First establish who owns the PHP runtime
The fastest safe response depends on the hosting model:
- Managed hosting: the provider may patch and restart PHP for you. Request written confirmation of the affected service, package or image, fixed version, deployment time and verification method.
- Cloud platform or container service: identify the base image, runtime layer and deployment owner. Rebuild from the patched image, deploy through the normal release path and replace all running instances.
- Virtual private server: the server owner must update packages, restart the relevant web or PHP workers and verify every pool or site.
- Shared or inherited environment: map all sites on the account before changing the runtime. One legacy application can block an otherwise straightforward branch upgrade.
- Unclear ownership: treat that as a risk in its own right. Escalate to the host, previous developer or a technical takeover partner immediately.
Do not let responsibility sit between the web agency, managed-service provider and internal IT team. Name one incident owner and one person authorised to approve the emergency change.
Move from inventory to verified protection
A seven-step emergency patch plan
1. Build the exposure list
List production, staging and legacy websites; their domains and subdomains; hosting accounts; PHP branches; server interfaces; operating systems or container images; and named owners. Prioritise public systems that accept uploads, forms, logins or ecommerce traffic.
2. Confirm the live runtime
Use the CMS health screen, hosting panel, deployment metadata or server command appropriate to the environment. Record the result before and after the change. Check separate worker pools, command-line jobs and containers rather than assuming they all use one PHP build.
3. Protect recoverability
Take a current database and file backup, confirm where it is stored, and make sure the team knows how to restore it. Capture the current package list, image digest or infrastructure configuration so the change is auditable.
4. Test compatibility where time allows
Use a representative staging environment with the same PHP branch, extensions and application build. The objective is not an exhaustive redesign; it is to expose fatal errors, extension incompatibility and broken business paths before production.
5. Patch and restart
Install the fixed vendor package or deploy a rebuilt image. Restart or replace every affected PHP worker so long-running processes cannot continue on the vulnerable build.
6. Run business-focused smoke tests
Test the homepage, key landing pages, login and administration, search, forms, uploads, checkout or payment hand-off, booking, API integrations, webhooks, scheduled jobs, transactional email, image processing and caching.
7. Verify and monitor
Independently confirm the live PHP version, record the evidence, review server and application logs, and monitor error rates, failed jobs, WAF events and unusual account or file activity.
What should be tested after the PHP update?
Prioritise revenue, customer service and data capture. A short, explicit checklist is more useful than asking someone to “click around”.
- Public pages return successfully and render without missing assets.
- CMS login, editing, preview and publishing work for an authorised user.
- Contact, quote, registration and upload forms submit and deliver their notifications.
- Product, cart, checkout, payment return and order confirmation paths complete.
- Search, filters, personalisation and server-side rendering return expected results.
- CRM, booking, analytics, marketing and fulfilment integrations receive test events.
- Scheduled tasks, queues, imports, exports and backups run successfully.
- Image resizing, PDF generation and email delivery work with the installed extensions.
- Error logs show no new fatal errors, deprecation floods or repeated worker restarts.
Record who performed each test, the time, the environment and the result. This turns the emergency change into reusable evidence for the next platform audit.
What if you cannot patch immediately?
The PHP project is clear that its configuration mitigations are incomplete. They can reduce specific attack paths but do not make an affected installation safe. Use them only as temporary, technically reviewed measures while the fixed runtime is being deployed.
If the application cannot move to a fixed version, establish whether a trusted operating-system or LTS vendor has supplied a backport for the exact package you run. Obtain the package identifier and advisory reference; do not treat a general “we patch our servers” statement as sufficient.
Where neither a fixed build nor the documented temporary mitigations can be applied promptly, the UK NCSC advises considering taking the system offline until it can be fully mitigated. For a revenue-critical service, that decision should involve the business owner, hosting owner and security lead, with a controlled maintenance page or traffic block ready.
If a service remained exposed and you suspect exploitation, preserve logs and evidence before rebuilding or cleaning the environment. Rotate relevant credentials, inspect for unauthorised files or persistence, and bring in incident-response expertise if the team cannot confidently assess compromise.
Questions your provider should answer today
Make the response specific enough to verify, not merely reassuring.
Exposure
Which of our domains, applications, worker pools, containers or managed services run PHP, and which server interface do they use?
Remediation
Which package, image or vendor backport fixes both CVE-2026-109618 and CVE-2026-109619, and when was it deployed?
Verification
Were all affected workers restarted or replaced, and how was the live runtime version independently confirmed?
Monitoring
What logs, WAF events, file changes, crashes or account activity were reviewed for evidence of attempted or successful exploitation?
Compatibility
Which CMS, plugins, frameworks, extensions and business journeys were tested after the change?
Lifecycle
If the service remains on PHP 8.2 or older, what is the dated plan to move it onto a branch with ongoing upstream support?
A practical 48-hour response for an SME
Hours 0–4: establish facts
- Name the incident owner and technical owner.
- Inventory internet-facing PHP workloads and identify the live branch.
- Open a priority ticket with each hosting or platform provider.
- Separate fixed, scheduled, blocked and unknown systems.
Hours 4–12: prepare and patch
- Confirm backup and rollback readiness.
- Patch a representative staging environment where available.
- Run the critical-path test list.
- Deploy the fixed package or image and restart affected workers.
Hours 12–24: verify production
- Confirm the live runtime version independently.
- Repeat the customer-journey smoke tests in production.
- Review logs, WAF activity, errors and scheduled jobs.
- Record versions, times, approvals and test evidence.
Hours 24–48: close gaps
- Escalate unknown, unsupported or vendor-blocked systems.
- Assess any service that remained exposed for signs of compromise.
- Schedule the move from PHP 8.2 or an older branch.
- Add the discovered sites, owners and dependencies to the permanent asset register.
The 48-hour window reflects Australian cyber guidance for critical vulnerabilities in online services and internet-facing servers. It is a prioritisation benchmark, not a reason to delay a patch that can be safely applied sooner.
Turn this emergency into better website governance
The immediate objective is a fixed PHP runtime. The longer-term lesson is that website security depends on infrastructure ownership as much as CMS administration.
After the incident, keep a simple register containing each domain, application owner, hosting provider, CMS or framework, PHP branch, deployment method, backup owner, monitoring route and support expiry. Add a recurring review for unsupported runtimes, stale staging sites and environments that no longer have a clear maintainer.
For managed services, define the evidence you expect after a critical update. For custom applications, keep a reproducible build and a representative test suite. For inherited or neglected websites, commission a technical takeover audit before the next security release forces another emergency discovery exercise.
Questions business and website teams are asking
Sources Checked
- PHP project: Critical remote code execution vulnerabilities and fixed releases
- PHP project advisory: CVE-2026-109618
- PHP project advisory: CVE-2026-109619
- WordPress.org: Critical PHP Security Release
- ASD's ACSC: Critical vulnerabilities in PHP
- UK NCSC: Critical security issue affecting PHP
- PHP project: Supported versions
- ASD's ACSC: Patching applications and operating systems
- WordPress.org: Site Health screen
- Drupal.org: PHP requirements
Sources were accessed on 22 October 2026. Security guidance and vendor packages can change quickly; confirm the current PHP and platform advisories before making production changes.