Two critical vulnerabilities in PHP have created an urgent patching priority for organizations operating websites, web applications, appliances, and other products that depend on the widely used scripting language.
The vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively referred to as PHP2Shell, can allow an unauthenticated attacker to execute code remotely. PHP rates both vulnerabilities 9.2 under CVSS 4.0 and warns that every unpatched PHP installation serving web requests is at risk.
That makes this more than another item for the next routine patch window. Remote code execution can give an attacker control over a vulnerable server. From there, the attacker may be able to deploy malware, steal data, establish persistence, disable security tools, or use the server as a route into the wider environment.
Organizations should update affected systems immediately, starting with internet-facing services. They should also investigate whether an attacker reached a vulnerable system before it was patched. Closing the vulnerability does not remove persistence or malicious code already present.
What are the PHP2Shell vulnerabilities?
Both vulnerabilities affect PHP’s handling of memory during web requests, but they involve different failure conditions.
CVE-2026-109618 involves memory corruption during out-of-memory handling. A threat actor can use specially crafted uploads to interrupt a request while internal request data is only partially initialized. That interruption causes an improper cleanup, which may cause invalid data to be treated as valid.
CVE-2026-109619 involves stale internal state that remains after its underlying memory has been freed. A later request processed by the same worker may use that state before PHP’s normal initialization resets it.
The result can be unauthenticated remote code execution. The PHP project lists PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed among the affected ways of serving web requests. It considers mod_php the highest-risk configuration because a demonstrated attack can run before any application code executes. That means application-level authentication and security checks may never get an opportunity to intervene.
Which PHP versions are safe?
The PHP project released emergency updates on October 21, 2026. Organizations should update to one of the following versions:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35 (Reaches end of life on December 31st)
Earlier releases in those branches are affected. PHP 8.1 and older no longer receive regular updates from the PHP project. Some Linux distributions and long-term-support vendors may provide backported fixes, and the PHP security team has made minimal source backports available for PHP 7.4, 8.0, and 8.1. Organizations using an older branch should confirm support with their vendor and plan migration to a supported version rather than assuming a legacy installation is protected.
Inventory must extend beyond servers where administrators knowingly installed PHP. Third-party applications, containers, appliances, management interfaces, and network products may embed their own PHP runtime. Those components may require a product-specific update rather than a direct PHP upgrade. NCSC-NL has created an operational repository to help identify potentially affected software, although it cautions that the inventory remains incomplete.
Do not treat temporary mitigations as a fix
The PHP advisory provides steps to reduce exposure when an organization cannot update immediately. These include changes to memory and upload limits, disabling session.upload_progress, restarting every worker, and adjusting a PHP 8.5 backtrace setting.
These measures address known attack paths, not the underlying vulnerabilities. PHP states that an update is the only complete solution. CERT-EU advises organizations that cannot patch promptly to consider isolating internet-facing applications from public networks until the fix has been applied and verified.
Any temporary mitigation should be tested, documented, and replaced by the appropriate update as soon as possible. If a vulnerable service cannot be patched, isolated, or safely mitigated, taking it offline may be less damaging than allowing an unauthenticated path to server compromise to remain exposed.
Patching must be followed by investigation
Security teams should not assume that applying the update returns a system to a known-good state. Public technical details and proofs of concept increase the likelihood of rapid scanning and exploitation. CERT-EU warned on October 21 that initial proofs of concept had begun circulating.
After patching, teams should verify that every PHP worker and container has restarted on the fixed build. They should review web server, reverse proxy, application, endpoint, and network telemetry for activity that predates remediation.
Investigation should look for unexpected child processes, modified application files, web shells, new scheduled tasks or accounts, suspicious outbound connections, unusual credential access, and security-control changes. If compromise is suspected, isolate the affected system, preserve evidence, rotate exposed credentials, and rebuild from a trusted baseline where necessary.
Limit what a compromised PHP process can do
Patching closes the vulnerabilities. Zero Trust controls can reduce what an attacker is able to do before every instance is updated and limit the impact of future application vulnerabilities.
A web-facing PHP process generally needs access only to the files, processes, credentials, and network services required to operate its site. It should not have unrestricted authority to launch shells or administrative tools, alter unrelated files, read broad stores of sensitive data, or connect anywhere on the internal network or internet.
- Application Allowlisting can prevent unapproved executables and scripts from running.
- Ringfencing™ can restrict how an approved application interacts with files, child processes, and network resources.
- Privileged Access Management can remove unnecessary standing administrative rights, while storage and network controls can limit access to sensitive data and destinations.
These controls should be paired with EDR and centralized telemetry. Prevention can interrupt post-exploitation activity, while detection provides the evidence needed to identify abnormal behavior, establish scope, and contain systems that may already be compromised.
This is a backstop, not an alternative to patching. The durable approach is to update the vulnerable software, investigate for prior access, and enforce least privilege so a compromised web process cannot automatically become a gateway into the broader business.
Frequently asked questions
What is PHP2Shell?
PHP2Shell is the collective name used for CVE-2026-109618 and CVE-2026-109619. Both are critical PHP vulnerabilities that can permit unauthenticated remote code execution on systems serving web requests.
Which versions fix PHP2Shell?
The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Organizations using vendor-maintained packages should confirm that the vendor’s build includes the backported security fixes.
Are PHP 8.1 and older versions affected?
Yes. PHP 8.1 and older are affected and no longer receive normal security updates from the PHP project. Some distributions and LTS vendors may provide fixes, but upgrading to a supported PHP branch is the safer long-term response.
Can a web application firewall stop PHP2Shell?
A web application firewall or proxy rule may reduce exposure to known request patterns, but it should not be treated as a complete fix. Attack paths can change, and the PHP project states that updating is the only complete solution.
What should organizations do after patching PHP?
Confirm that all workers, containers, and embedded runtimes use a fixed build. Then review historical telemetry for exploitation, investigate suspicious activity, rotate potentially exposed credentials, and rebuild compromised systems from trusted baselines.
