PHP2Shell concerns two critical vulnerabilities in PHP, the runtime beneath WordPress, Drupal, Joomla and many custom business applications. Updating an application alone does not repair defects in that runtime. Researchers demonstrated attacks against deployments of several major content management systems. Wiz’s research explains the findings.
On October 21, PHP issued emergency updates for CVE-2026-109618 and CVE-2026-109619. Both can allow remote code execution without authentication under exploitable conditions. Server owners should prioritize assessment and patching. See PHP’s release announcement.
For a business running an older customer portal, accounting integration or internal application, the immediate questions are practical: who owns the server, which PHP build is serving it, and can someone verify a fix without disrupting operations?
Need help with an older PHP application? Discuss a server security and upgrade review with Root.
On this page
What is PHP2Shell, and which servers need attention?
The two vulnerabilities concern what happens when PHP request processing goes wrong.
CVE-2026-109618 involves out-of-memory handling. An interrupted operation can leave internal data partly initialized. Cleanup may then treat that unfinished data as valid, creating memory corruption that can lead to code execution. A demonstrated Apache mod_php attack reaches this condition before application code runs. Read the out-of-memory advisory.
CVE-2026-109619 involves stale state between requests. PHP workers commonly serve successive requests. Internal references can survive after memory from an earlier request has been released. A later request may access that invalid state before initialization clears it, creating a use-after-free condition. Read the stale-state advisory.
PHP identifies Apache with mod_php as the highest-risk configuration. Other deployments, including PHP-FPM, php-cgi, FrankenPHP and LiteSpeed, also need assessment. Exploitability depends on the configuration and reachable code paths. Official scope and release guidance.
The potential impact includes exposed process memory containing passwords, tokens or API keys. What an attacker could reach afterward depends on the application’s privileges and connections. Wiz documents these risks.
How a longstanding problem became an emergency
The PHP Foundation says work following a 2024 security audit revealed signs of the out-of-memory issue. Exploitation was initially theoretical, while proposed fixes raised compatibility, performance and extension concerns. Limited specialist capacity and a stalled decision process delayed progress.
Concrete exploitation reports from Calif and additional researchers in 2026 accelerated remediation. The Foundation also reports confirmed application-level PHP-FPM attack paths; running Nginx with PHP-FPM does not settle the exposure question. Read the Foundation’s account.
For administrators, recurring crashes and memory errors deserve investigation. An apparent availability problem may have security implications that are not yet understood.
Which PHP versions contain the emergency fixes?
These are the upstream emergency releases announced on October 21. This article reflects guidance reviewed on ; check current vendor advisories before making changes.
| PHP branch | Patched release |
|---|---|
PHP 8.2 | 8.2.35 |
PHP 8.3 | 8.3.36 |
PHP 8.4 | 8.4.27 |
PHP 8.5 | 8.5.12 |
Install the applicable fixed release or a later security release. PHP 8.1 and older are outside upstream support. Vendor-maintained packages may receive backported fixes; obtain confirmation covering both CVEs for the exact package build.
A practical PHP2Shell remediation plan
1. Find the PHP runtime serving each application
Inventory production, staging, forgotten subdomains and internal services. Record the hosting provider, package source, application owner and deployment method. A command-line version check alone may miss different runtimes assigned to websites, PHP-FPM pools or containers.
2. Prepare and apply the update
Agree on a maintenance window, recovery plan and essential application checks. Apply the vendor update and restart or replace affected workers. For containers, rebuild and redeploy every affected replica. Include the image or deployment definition so the next release does not restore a vulnerable runtime.
3. Verify the running service
Confirm the build actually handling web requests through an administrative check. An updated package on disk does not establish that all workers were replaced. Remove temporary diagnostic pages after use, and retain the package details and verification result.
4. Test the business workflows
Check sign-in, forms, uploads, customer portals, checkout and scheduled jobs where applicable. Review errors after deployment. Record what passed and who accepted the change; “updates completed” leaves the next administrator with too many unanswered questions.
5. Investigate suspicious activity separately
Patching does not prove a server was never compromised. Unexpected file changes, unfamiliar processes, unusual outbound connections and abnormal worker failures warrant investigation. These observations are leads, not proof of PHP2Shell exploitation. Preserve relevant evidence if compromise is suspected and coordinate containment, credential review and recovery.
What if an immediate patch is not possible?
Temporary controls address particular attack paths. They do not replace the update. PHP’s guidance includes tighter request limits and resource isolation. Removing PHP’s own memory limit does not eliminate every allocation-failure path and requires careful external resource controls; applying that change casually can create an availability problem. Review the official mitigation limits.
Disabling session upload progress blocks confirmed session-related paths, but other stale-state variants remain. Hiding warnings does not repair the underlying defect. PHP explains these limitations.
Document the scope and owner of any interim measure, its application impact and the deadline for patching.
Get an older PHP server reviewed before the next emergency
A legacy application often stays in service because it performs a job the business cannot easily replace. Its owner needs a workable upgrade plan with dependencies, costs and operational constraints made clear.
Root Managed Services can help server owners, businesses and system administrators assess PHP environments and implement fixes. A scoped review can cover:
- Exposure and ownership: runtimes, hosting arrangements, reachable applications and responsibility for updates.
- Patch and compatibility planning: vendor support, extensions, integrations, testing requirements and a recovery path.
- Architecture and access: application isolation, service accounts, database permissions and sensitive-data access.
- Verification and handover: evidence of the running fix, application test results and outstanding upgrade work.
Explore our server administration services, cybersecurity services and infrastructure consulting. We can work with an existing administrator or help a business establish clear ownership for an aging environment.
Request a PHP and legacy server review
Tell us which applications matter, where they are hosted and any maintenance constraints. If you do not know the PHP version, we can discuss how to establish it. Root will help define the review scope and next steps.
The button opens an email draft. Share a brief environment summary; do not send passwords, patient information or other sensitive records.
Questions from business owners and administrators
What should we provide for an initial assessment?
Start with application names, the hosting provider, known software versions and the person responsible for maintenance. Describe critical workflows and acceptable downtime. A complete inventory is useful, but uncertainty about an old server is itself a reason to arrange a review.
Can our existing administrator stay involved?
Yes. Root can help review architecture, plan changes and validate results alongside your administrator. Agreeing on access, responsibilities and change approval at the start keeps the work accountable.
Does patching mean we need to replace the whole application?
That decision should follow a compatibility assessment. Separate the immediate security fix from longer-term modernization. A useful review identifies what can be patched now, what needs testing and which unsupported dependencies need a migration plan.
Sources and further reading
Official advisories establish affected behavior and remediation. Additional reporting offers context and may reflect different publication dates.
- PHP: October 21 emergency security release
- PHP: CVE-2026-109618 advisory
- PHP: CVE-2026-109619 advisory
- PHP Foundation: Security release background
- Wiz Research: PHP2Shell technical findings
- Sansec: PHP2Shell assessment and mitigation guidance
- BleepingComputer: PHP ships emergency patches for PHP2Shell
- Dead Neurons: PHP2Shell explained