Quick answer
The fix must cover the PHP runtime serving web requests and any processes that remain running. Updating only the CMS does not patch the runtime. Confirm the effective version, the vendor package and the additional measures specified in the official advisories.
The disclosure of critical PHP vulnerabilities required a swift response from those running production websites and applications. At WordPane Cloud, we applied the fixes across all customer servers in our solutions from the first day they became available. We also addressed the additional advisory published on October 23.
- Identify web runtime
- Verify the patch and mitigation
- Restart and test
- Record evidence
What happened with PHP
On October 21, 2026, the PHP project published fixes for CVE-2026-109618 and CVE-2026-109619. Both can allow unauthenticated remote code execution in affected environments.
The advisory covers installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project identifies mod_php as the highest demonstrated risk. The review therefore needs to consider the PHP installation used by the server, as well as the installed CMS.
WordPane Cloud’s response
From day one, we brought the fixes to customer servers in WordPane Cloud solutions. Our response also covered the additional October 23 advisory, identified as CVE-2026-115560.
This work takes place in the layer that runs applications. Updating WordPress, a plugin or a theme is a different task from fixing the server’s PHP installation. Maintaining a website involves both layers.
For people maintaining a store, a portal or several client websites, this response reduces the need to track every technical advisory to request infrastructure remediation from our team.
The October 21 fixes and the additional advisory
The October 21 advisory lists PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 as releases fixing the initial two flaws. Linux distributions may also deliver backported fixes while retaining the base version number. Verification should consider the vendor’s package.
The October 23 advisory concerns an uncommon combination of session configuration and application behaviour. It was not resolved by the October 21 updates. Until the next regular release, the PHP project recommends disabling session.upload_progress.enabled in the relevant environments and restarting workers. As of this article’s publication, that measure remains relevant to the additional advisory.
What still matters for your application
The PHP fix addresses the vulnerabilities disclosed in that layer. Maintaining application code and its components remains necessary.
- Keep your CMS, plugins, themes and dependencies up to date.
- Review administrator accounts and access permissions.
- Keep recovery copies and check that they can be restored.
- Investigate unexpected changes, new files or unusual errors.
October 30 update: what changed in the alert
The Canadian Centre for Cyber Security update reports active exploitation of CVE-2026-109618 and CVE-2026-109619 and their inclusion in CISA’s Known Exploited Vulnerabilities catalog on October 26. This reinforces the priority of patching affected environments. It does not establish that any specific server was compromised; that requires investigation of the environment itself.
The additional CVE-2026-115560 advisory has its own conditions. The PHP advisory describes mitigation involving session.upload_progress.enabled and restarting workers. A list of versions fixing the first two vulnerabilities must not be treated as automatic proof that the third has been addressed. Consult the advisory for each identifier.
How to check a fix without confusing CLI and application
A server can have several PHP versions installed. Running php -v in a terminal reports the version of that executable; the website may use a different PHP-FPM pool or module. Verification must identify the application, its selected version, the service handling HTTP and the installed package version.
Distributions can backport patches: the base version may look old while the package already contains the fix. Compare the complete package identifier with the vendor advisory. Do not publish a publicly accessible phpinfo page to demonstrate the fix: it can unnecessarily reveal paths, modules and configuration. Keep the verification record private.
- Identify server, domain, web runtime and validation manager.
- Check the PHP advisory and the patched package distributed by the vendor.
- Confirm the update and reloading or restarting of the necessary processes.
- Test login, sending files, session and essential application routines.
- Record the date, effective version and evidence in the maintenance ticket.
Applying a patch and investigating an incident are different tasks
Patching addresses exposure to the vulnerability being fixed, but does not necessarily remove changes made before the patch. If there are signs of compromise, preserve logs and examine files, accounts, scheduled tasks and access records. Restoring a backup without addressing the cause of the exposure can put the same vulnerable condition back into production.
In WordPane, confirmation of a server must be obtained by the support with the identification of the environment. The article records the already communicated institutional response and public recommendations; it does not replace an individual integrity report or forensic analysis.
Questions about your environment?
If you are a customer and need to confirm the response for a specific server, open a dashboard ticket and identify the environment you want us to check. Our team can guide verification according to its configuration.
This article records our response to the October 2026 incident. The references below let you follow the PHP project’s original advisories and any further updates.
Talk to our team about your server
Sign in to the dashboard to open a ticket and ask about your application environment.
Open a support ticketConsult panel documentation
