PHP2Shell is the name being used for critical PHP vulnerabilities disclosed on 21 October 2026. If your website runs PHP, the immediate question is whether the runtime serving your visitors has the security fixes. Updating a plugin or seeing a green firewall dashboard does not answer that question.
PHP2Shell affects the PHP runtime underneath websites and can enable unauthenticated remote code execution. PHP has released fixes in 8.2.35, 8.3.36, 8.4.27 and 8.5.12, and you should confirm a fixed release or a documented vendor backport in the actual web-serving environment. Keep defensive controls enabled, but do not treat a WAF or a temporary configuration change as a replacement for patching.
Status checked: 21 October 2026, 17:15 UTC. This guide reflects the published fixes, rather than the earlier announcement that a release was still pending. Check the linked advisories again before making changes because vendor packaging and response guidance can develop quickly.
PHP2Shell: what has actually been confirmed?
The PHP security team identifies two flaws that can permit remote execution without a login. Its official advisory says web-serving PHP installations are at risk and highlights Apache with mod_php as the highest-risk configuration. The runtime, build and request-handling environment matter to exploitability.
| Identifier | PHP’s description | Practical concern |
|---|---|---|
| CVE-2026-109618 | Out-of-memory corruption during request cleanup | Invalid request state can be used when PHP handles an allocation failure |
| CVE-2026-109619 | Stale request-owned global state | A later request on the same worker can encounter references to released memory |
Both advisories carry a CVSS v4.0 score of 9.2. Read the primary reports for CVE-2026-109618 and CVE-2026-109619 rather than relying on a social post’s proposed workaround.
This is a reason to act promptly, not evidence that every PHP website has already been compromised. A critical vulnerability, an attempted attack and a confirmed intrusion are different findings. Your response should establish which of those applies to your own systems.
Which PHP versions fix PHP2Shell?
The supported-branch security releases published today are listed below. The version table is a starting point for checking an upstream installation. Distribution packages can carry fixes under a different package revision.
| PHP branch | Security release fixing both vulnerabilities |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
These releases are confirmed in the PHP release announcements . Ask a distribution or hosting vendor for its security notice and the exact installed package revision if it uses backported fixes. A version string alone can misclassify a patched vendor package or an outdated bundled runtime.
PHP 8.1 and older no longer receive normal upstream updates. PHP has also supplied minimal source backports for 7.4, 8.0 and 8.1, but these are not a restoration of ongoing support. Establish an accountable vendor-supported fix or an upgrade plan. The PHP support table explains current branch support.
Check containers, embedded PHP installations and appliances separately. The NCSC-NL operational guidance specifically warns that updating host PHP does not necessarily update those runtimes.
Are WordPress, Laravel and other PHP websites affected?
Start with the interpreter executing the application. A WordPress site, a Laravel application and a custom PHP portal can share an outdated runtime even though their application code is entirely different. Installing the latest theme, plugin or framework release does not install a PHP runtime security fix.
For managed hosting, ask which PHP version or patched package is serving each site, whether the change has reached every node, and whether workers have been restarted where required. Request evidence from the hosting platform rather than interpreting an application update notification as confirmation.
For self-managed systems, include secondary sites, administrative interfaces, old virtual hosts and preview environments in the inventory. A production application may be updated while an older site remains publicly reachable on the same infrastructure. Record an owner and a remediation decision for each exposed environment.
Do not infer that an unused upload form makes a deployment safe. PHP’s advisories describe runtime request-processing paths. The application features a visitor sees are not a complete exposure assessment.
How to patch and verify the runtime that serves visitors
Establish what is actually running
Identify the web server integration, runtime package or container image, configuration source and service owner. Relate that inventory to the hostname customers use. An engineer checking the wrong host can produce a convincing but irrelevant version report.
These read-only commands identify the command-line installation and its configuration:
1php -v
2php --ini
They do not prove what PHP-FPM, Apache or another web-serving integration is running. Use authenticated hosting information or a controlled administrative check to establish the serving runtime. Do not leave a public diagnostic page exposing configuration and environment details.
For a container deployment, verify the image and application instance actually receiving traffic, not only the replacement image in a registry. Include all instances behind the load balancer and any separate worker services in the change record.
Apply the supported fix and test the application
Use the maintained package source or image supplier’s documented update procedure. Record the installed revision and the vendor notice covering both CVEs. Plan service restarts or instance replacement according to the deployment rather than assuming that downloading a package changes running processes.
Preserve relevant logs before disruptive changes. Keep a verified backup and a recovery plan, then test representative application flows after the update. Login, sessions, checkout, uploads and background processing are useful candidates where the application uses them.
Complete the change by checking the serving runtime again. Keep evidence of which instances were updated, when traffic moved, and who accepted the application checks. A deployment job marked successful is useful evidence, but it is not the whole verification.
Does Cloudflare WAF protect against PHP2Shell?
Cloudflare reports deploying PHP2Shell WAF protections for Free and paid WAF customers and observing attack traffic. Its announcement describes protections that consider request and response information. It also explicitly advises customers to patch PHP despite those protections.
For an individual website, confirm that the relevant traffic actually passes through the protected service and that applicable rules are enabled. Review exceptions, bypass rules and any separately reachable origin. Those are deployment checks, not a claim that Cloudflare’s announcement guarantees protection for every possible route to your application.
Keep WAF event data as part of the investigation. A blocked request can establish that a rule matched that request. It cannot certify that an origin was never reached another way or that an earlier intrusion did not occur.
Use the WAF as another defensive layer while completing the runtime update. Do not postpone the PHP fix merely because the dashboard is recording blocked attempts.
Temporary mitigations are not a complete PHP2Shell fix
If patching is temporarily blocked, follow the current PHP advisories with the engineer or provider responsible for the system. The stale-state advisory
explains why disabling session.upload_progress.enabled must happen before request parsing and requires worker restarts. It specifically warns against relying on ini_set() or FPM .user.ini for this purpose.
That change blocks confirmed session-related paths, not every variant. PHP 8.5 also has separate guidance concerning fatal_error_backtraces. Copying a short configuration snippet from a forum is not evidence that both vulnerabilities have been addressed.
The out-of-memory advisory describes different controls, including request limits and changes to memory-limit handling. These have resource and availability implications. Review the full instructions for the actual deployment rather than casually removing memory boundaries on a live server.
Where exposure cannot be reduced acceptably before patching, discuss restricting public access to the affected application. Document the temporary measure, its limitations, the responsible owner and the planned permanent fix. A workaround should have a removal or review condition, not become an undocumented permanent setting.
What should you monitor after checking exposure?
Begin with a baseline and preserve the time window that matters. Correlate web requests with PHP, web server and host events rather than treating a single unusual request as a complete diagnosis. Where logs are missing, record that limitation explicitly.
| Observation | Investigation question |
|---|---|
| Unexpected PHP worker exits or memory failures | Did application behaviour change, and which requests were handled nearby? |
| New or modified executable files | Was there an approved deployment or an unexplained write? |
| Unexpected child processes or outbound connections | Does the web worker have a legitimate reason for that activity? |
| WAF matches and origin access records | Which requests were blocked, and which routes reached the origin? |
| Changes to accounts, scheduled jobs or secrets | Can each change be tied to an authorized operator? |
These are investigation prompts, not PHP2Shell-specific indicators or proof of compromise. Normal operations can produce similar symptoms. Equally, an absence of alerts does not prove that an unpatched system was safe.
If evidence suggests an intrusion, preserve it and arrange incident handling alongside patching. Updating the interpreter does not remove persistence, undo stolen credentials or establish what data was accessed. Treat those as separate questions in the response plan.
Frequently Asked Questions
What is the PHP2Shell exploit? PHP2Shell refers to the PHP vulnerabilities tracked as CVE-2026-109618 and CVE-2026-109619. They concern memory handling in the runtime and can allow unauthenticated remote code execution. They are not simply a WordPress plugin defect.
Which versions should I check for the PHP2Shell patch? The supported-branch fixes released on 21 October 2026 are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. For distribution backports, obtain the vendor advisory and confirm the exact patched package revision installed in the serving environment.
Does updating WordPress fix PHP2Shell? Updating WordPress alone does not update the PHP interpreter underneath it. Keep application maintenance current, but separately verify the PHP runtime security fix with your hosting provider or the engineer responsible for the server.
Is a site behind Cloudflare automatically safe? Cloudflare reports WAF protections, but your traffic path, applicable rules and origin exposure still require checking. Keep the protections enabled and patch PHP. A firewall dashboard is not proof that the runtime is fixed or that no earlier compromise occurred.
Is disabling session upload progress enough? No. PHP describes that measure as blocking confirmed session-related paths, not every variant. It must be applied at the appropriate configuration layer with worker restarts. Updating to a fixed runtime or a verified vendor backport remains necessary.
Can I test a public exploit against my live website? Prefer version, package and configuration evidence for the initial check. If validation requires exploit testing, arrange it under explicit authorization in a controlled environment with isolation, monitoring and a recovery plan. Do not run unreviewed exploit scripts against production.
Does installing the patch prove the server was not compromised? No. Patching addresses the runtime flaws, while incident assessment examines prior activity, persistence, credentials and possible data access. Keep those workstreams connected and record the limits of the evidence available.
Need help checking, monitoring or patching your PHP website?
We can help establish which PHP runtimes serve your websites, assess exposure, review available logs and defensive controls, and plan the required patch or supported upgrade. If the environment needs continued observation, we can agree a monitoring scope, alert ownership and an escalation process around the risks identified.
Our application security service supports assessment and investigation, while our server security service covers the hosting and configuration boundary. We can work with your hosting provider to verify vendor fixes, coordinate changes and document post-update application checks.
The useful outcome is a clear record of what was checked, what was patched, what remains uncertain and who owns follow-up. We do not promise a clean bill of health from a version string or a single scan. Scope and availability are agreed before work begins.
Contact us for a PHP2Shell exposure check, security monitoring or patching support . Include your hosting arrangement, affected domains, known PHP versions and the person authorized to approve changes. Please do not send passwords or access tokens in the initial enquiry.