Reviewed on October 25, 2026. This article covers the October 21 PHP security releases and the October 23 follow-up notice. Check the linked vendor advisories for subsequent changes.
A WordPress dashboard can show no pending updates while the server underneath it still needs an urgent security patch. PHP2SHELL is a clear example: the vulnerable component was PHP, the runtime that executes WordPress.
For site owners, the immediate task is to confirm the hosting environment has received the relevant fixes. Then review the everyday controls that help prevent, detect and recover from other incidents.
What happened with PHP2SHELL?
PHP2SHELL refers to critical memory-safety vulnerabilities in PHP, including CVE-2026-109618 and CVE-2026-109619. They concern out-of-memory handling and stale internal state between requests. Under exploitable conditions, an attacker can execute code without signing in.
The PHP Foundation's account explains that public circulation of the identifiers on October 20 disrupted disclosure. The release was brought forward from October 22 to October 21. The reported severity was CVSS 4.0 9.2; early claims of 10.0 were incorrect.
The Foundation describes demonstrated attacks involving Apache with mod_php and confirms an application-level route on PHP-FPM. A different web server setup is not a reason to assume a site is unaffected.
Researchers also demonstrated disclosure of sensitive process memory. Their research overview explains why impact can extend beyond visible website changes.
Were websites actually attacked?
AWS reported exploitation attempts in its MadPot honeypots dating to October 17, before public disclosure, and more attempts around the release. It also said it was unclear whether those early attempts would have succeeded against real systems.
An observed attempt, a laboratory demonstration and a confirmed production compromise are different findings. Do not turn reports of scanning into a claim that every WordPress site was hacked. Equally, a lack of visible damage does not establish that a particular installation was safe.
Apply the PHP fix, not just WordPress updates
The October 21 upstream releases addressing the original two CVEs were:
| PHP branch | Security release |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Use the latest appropriate patched release or vendor package available for your environment. These are the incident's original fixed versions, not a recommendation to remain on them indefinitely. See the official PHP notices.
PHP 8.1 and older are outside normal upstream support. Some vendors supply backports; PHP also supplied limited source backports for 7.4, 8.0 and 8.1. Obtain an explicit vendor patch statement and plan a supported upgrade.
A WordPress plugin update cannot replace a PHP runtime patch. A firewall rule may reduce exposure, but it is not equivalent to fixing the runtime. CISA's October 21 bulletin urged immediate patching and advised taking affected systems offline when they cannot be patched or updated promptly.
Include the October 23 follow-up
PHP subsequently published a session-upload-progress notice concerning an unusual configuration and application behavior, tracked as CVE-2026-115560.
The October 23 notice recommends setting session.upload_progress.enabled=0 until the next regular bugfix release, with an exception for applications that never change the session serialization handler at runtime. Ask your administrator to assess and apply the guidance.
This is a PHP/server configuration task, not a WordPress snippet. Relevant settings must take effect before request parsing, and workers need restarting. Do not assume the October 21 version check alone closes every follow-up concern.
Ask your host for evidence
Begin with Tools → Site Health → Info in WordPress to inspect the server information. The Site Health documentation explains this view. It is a useful inventory tool, not a certificate that a particular vulnerability is resolved.
The PHP binary used in a terminal can differ from the runtime serving your domain. A server can also have several PHP versions, pools and containers. Ask about the actual website, staging copies and other PHP applications attached to the account.
Here is a message you can send your hosting provider:
Please confirm which PHP package/build is serving my domain, whether it includes the fixes for CVE-2026-109618 and CVE-2026-109619, and how you have addressed the October 23 guidance for CVE-2026-115560. Please also confirm that affected workers were restarted and that staging environments were checked.
Linux vendors may backport a fix without displaying the newest upstream version number. The exact package and vendor security notice matter. The Swiss NCSC advisory also emphasizes restarting affected services and checking the version actually running.
Keep the answer in your maintenance record. “We use a firewall” or “WordPress is up to date” does not answer the patch-status question.
Keep WordPress secure after the emergency
PHP2SHELL is one incident. A useful maintenance routine covers the rest of the website too.
Keep a small, maintained software inventory
Track WordPress, active plugins, themes, PHP and hosting components. Remove unused plugins and themes after checking dependencies. Download software from trusted sources; avoid modified “nulled” packages.
Assign someone to act on security notices. Use a normal testing schedule for routine changes and an expedited process for urgent fixes. Back up, test critical journeys and verify the public site afterward. My WordPress update workflow covers that process.
Limit powerful access
Use unique accounts and strong, unique passwords. Give each person the minimum role they need, and remove access when their involvement ends. Enable two-factor authentication for administrators through a maintained solution, and for hosting, domain and email accounts where supported.
Store recovery codes securely. Protecting WordPress login while leaving the hosting account or password-reset mailbox weak leaves another route into the same business.
Keep files and credentials under control
Use HTTPS and encrypted administration connections. Avoid globally writable permissions. Keep backups, environment files and database exports outside publicly accessible directories.
Ask your developer whether dashboard file editing should be disabled and whether uploads can be prevented from executing PHP without breaking the application. The WordPress hardening handbook covers permissions, trusted software, access and related controls.
Make recovery a tested capability
Keep database and file backups in a separate, access-controlled location. Test a restore into an isolated environment and decide how to preserve new orders or inquiries during recovery.
A backup that has never been restored is an assumption. A documented restore test tells you what works, what is missing and who can bring the site back.
Monitor changes that deserve attention
Review new administrator accounts, unexpected file changes, unusual outbound connections, repeated server errors and abnormal resource use. Route alerts to someone who will investigate them.
A security plugin can help with monitoring and WordPress-specific controls. Its dashboard does not prove that every server component is patched or that no compromise has occurred.
If you suspect a compromise
Contact the hosting provider or incident responder promptly. Preserve relevant logs and a snapshot before cleanup where possible, and isolate the affected environment to limit further exposure.
Investigate the timeline and scope rather than deleting the first suspicious file and declaring success. Restore or rebuild from a verified clean source, fix the entry point, then revoke exposed credentials and sessions from a trusted device. Review backups before restoring them; an old backup can contain the same malicious changes.
WordPress's hacked-site recovery guide provides a starting point. A clean scanner result alone is not proof of recovery, and installing a patch does not remove a backdoor that was already planted.
For a business website, keep a short record of what was found, what changed and how recovery was verified. That record makes the next decision easier and prevents the same uncertainty returning months later.
If you need help confirming PHP patch status or establishing ongoing WordPress maintenance, tell me about your website. The useful outcome is a verified update, clear ownership and a recovery process you can rely on.
Last updated Oct 25, 2026
