In this guide
Updating WordPress is not the same as updating PHP. PHP2Shell concerns the server runtime that processes requests. Ask your host to identify the PHP build actually serving each website and endpoint, apply the appropriate security package, restart the affected workers and confirm the result with evidence.
PHP released fixes for CVE-2026-109618 and CVE-2026-109619 on 21 October 2026. CISA added both to its Known Exploited Vulnerabilities catalogue on 26 October. The advice is no longer just a precaution against a possible future attack. Treat an exposed, unpatched installation as an urgent hosting issue. PHP advisory · CISA’s official catalogue data.
What needs patching?
The two advisories describe remote-code-execution vulnerabilities involving out-of-memory handling and stale request state. They affect PHP itself, not one particular theme or plugin. PHP names web-serving installations including PHP-FPM, Apache with mod_php, CGI, FrankenPHP and LiteSpeed. A site can therefore need a runtime patch even when its content-management system is current. PHP’s affected-environment guidance.
For the two PHP2Shell vulnerabilities, these were the first fixed upstream releases in the maintained branches:
| PHP branch | First upstream fixed release | What to verify |
|---|---|---|
| 8.2 | 8.2.35 | The installed package and active web worker |
| 8.3 | 8.3.36 | The installed package and active web worker |
| 8.4 | 8.4.27 | The installed package and active web worker |
| 8.5 | 8.5.12 | The installed package and active web worker |
Use a newer appropriate fixed release when available. Distribution vendors may backport security fixes without adopting the same upstream version number; ask for the vendor advisory and exact package revision rather than judging the short version string alone. Older branches need an upgrade or a documented maintained-vendor fix, not an assumption that “PHP 8” is sufficient. PHP advisory: memory corruption · PHP advisory: stale state · Vendor package guidance.
An HTML website can still depend on PHP
A business owner may reasonably describe a site as “HTML, not WordPress” and still have a PHP contact form, website-audit tool or small integration behind it. Check the entire application, not just the file used for the homepage.
There is a useful example in the retained UVs Digital Hub source: the public pages are HTML/CSS/JavaScript, while the website-audit feature calls /api/website-audit.php. Inspecting that source proves a PHP dependency exists. It does not establish the version installed on the hosting server, whether it was patched, or whether an attacker ever reached it.
Inventory the main domain, subdomains, staging copies, customer portals and scheduled jobs. Assign an owner to each. A hosting account with several applications may have different runtime settings for different domains.
Five pieces of evidence to request from your host
A reply saying “everything is updated” is difficult to act on. Ask for a small, specific record:
- The affected service: the hostname, application and PHP handler or pool.
- The installed fix: the package version, distribution revision and advisory covering the two CVEs.
- The running process: confirmation that the web-serving workers were restarted or replaced after installation.
- The functional test: the important journeys checked after the change, with timestamps and results.
- The security follow-up: who reviewed exposure and relevant logs, and what remains unresolved.
A command-line version check is useful, but it is not sufficient on a server with several PHP installations. The administrator should compare it with the runtime used by the actual web application. Do not publish a phpinfo() page containing server configuration just to make the check easier.
Please confirm the PHP build currently serving our domain and PHP endpoints, the package revision that fixes CVE-2026-109618 and CVE-2026-109619, and whether the active web workers were restarted. Please include any separate session-upload-progress or Windows dependency actions that apply, plus the functional checks completed afterwards.
Keep the follow-up issues separate
Session upload progress
PHP’s 23 October note describes a separate, unusual configuration-dependent path tracked as CVE-2026-115560. It advises disabling session.upload_progress.enabled until the next regular bugfix release where the stated conditions apply. The note describes switching the session serializer at runtime before starting the session; it does not say every patched application has the same exposure. Have the host assess the actual configuration against the advisory. PHP’s session-upload-progress note.
Windows builds and Brotli
On 26 October, PHP released rebuilt Windows packages carrying a Brotli dependency fix: 8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1. The -1 identifies the package rebuild; the PHP runtime version itself is unchanged. A check that records only the runtime number can therefore miss the dependency update. PHP’s Windows build announcement.
Keep a separate line in the change record for each issue. “PHP2Shell patched”, “session configuration reviewed” and “Windows dependency package checked” are different conclusions. They should not be merged into a vague “server safe” label.
Test the business workflows after the patch
Choose tests that reflect what the site actually does. A homepage opening successfully is not proof that a form, payment callback or scheduled job still works.
| Workflow | Practical test | Acceptance evidence |
|---|---|---|
| Website enquiry | Submit an approved test enquiry through the normal form. | Correct confirmation and the expected internal destination. |
| Audit or API tool | Use an approved test URL; also test a rejected input. | Valid response format, helpful error handling and no unexpected server errors. |
| Login or portal | Sign in with a test account and exercise a permitted action. | Sessions, permissions and saved changes behave as intended. |
| Uploads | Test an allowed file and a deliberately invalid file in a safe environment. | Allowed use works; the existing restrictions remain enforced. |
| Scheduled processing | Run or observe a controlled job. | The job uses the intended runtime and records a valid outcome. |
Use test data and accounts you control. Do not create genuine customer invoices, send unwanted emails or exercise destructive operations just to check whether the server responds. Agree how to remove test records afterwards.
A patch is not an incident-clearance report
CISA’s catalogue records exploitation of both PHP2Shell vulnerabilities. That does not prove a particular business was compromised, but it is a reason to ask about the period before patching rather than closing the issue on a version screenshot alone. CISA KEV records, added 26 October 2026. Canada’s official 27 October update corroborates both KEV additions.
Have the responsible security team assess suspicious activity, unexpected file changes and relevant logs. Preserve evidence and follow the organisation’s incident process when there is a concern. Do not delete suspicious files first and then ask someone to determine what happened.
Likewise, a firewall rule or disabled feature is not equivalent to installing a fixed runtime. Temporary mitigations have limitations and can affect availability. Use the maintainer’s guidance with the hosting team rather than copying emergency configuration changes into production without a plan. PHP’s mitigation caveats.
Common questions
Does updating a WordPress plugin fix PHP2Shell?
No. Plugin updates and runtime updates address different layers. Confirm the PHP package with the hosting provider even when WordPress, its theme and its plugins are current.
Do we need to rebuild our website?
Not simply because PHP needs patching. Start with the runtime, dependencies and compatibility checks. A rebuild is a separate decision; it should not be sold as the default response to a server update.
Can a website ZIP include the PHP security patch?
A normal HTML/PHP application ZIP contains application files, not the hosting provider’s PHP runtime. Uploading new website files does not install a new PHP engine. The hosting update and the website deployment need separate evidence.
What should the business keep after the work?
Keep the affected-host list, package evidence, change timestamp, test results, responsible contacts and outstanding actions. These are useful operational records, not a certification that every future vulnerability has been prevented.
Make the maintenance scope specific
UVs Digital Hub can help define the website workflows and integrations that need retesting while your hosting team handles runtime updates. Send the affected domains, hosting arrangement and current provider response. Do not send passwords, private keys or customer data. See our website maintenance service and website audit checklist.
Sources checked 31 October 2026. This is a defensive maintenance checklist, not an assessment of a particular live server. The package observation concerns retained UVs source files only. Hosting patch status and any suspected compromise require verification in the actual environment.