PHP2Shell: Two Critical PHP Flaws, and What They Mean for Your Legacy Applications

October 26, 2026Aravind Naidu, Partner / CTO, ToolTwist12 min readEngineering

Last week the PHP project disclosed two critical vulnerabilities in the language runtime itself. Nicknamed PHP2Shell, they are tracked as CVE-2026-109618 and CVE-2026-109619, and both carry a CVSS 4.0 score of 9.2. Under the right conditions, an attacker with no credentials can run their own code on a server that processes PHP web requests.

This is not a flaw in a plugin or a single framework, so updating your application code will not fix it. The PHP runtime has to be updated. That is straightforward if you are on a supported version with a working deployment pipeline. It is a much harder week if you are one of the many organisations still running a business-critical application on PHP 5, 7 or 8.1, where the original developers have moved on and nobody is quite sure what an upgrade would break.

This article summarises what is publicly known as at 26 October 2026 and what to do now. If you already know you need help, skip to how ToolTwist can help. We can run a PHP exposure check for you this week.

What was disclosed

Both bugs are memory-safety flaws in how PHP handles errors during a request:

CVE-2026-109618 is an out-of-memory condition. When PHP bails out part-way through setting up a request, shutdown can later treat the half-initialised data as valid, which corrupts memory.
CVE-2026-109619 is a stale-state problem. Request data survives after its memory has been freed, and a later request on the same worker reuses it. Beyond code execution, this can also leak the contents of PHP worker memory, which may include passwords, tokens and API keys.

The vulnerabilities were found and reported by researchers, and details leaked ahead of the planned release. The PHP project published fixes on 21 October 2026.

Who is affected

Any PHP installation that serves web requests, including Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. The PHP project regards mod_php as the highest risk. The UK's National Cyber Security Centre (NCSC) puts it plainly: any version of PHP is affected, and older, unsupported versions carry the most risk.

Exploitation is not trivial. It depends on memory layout, the build and how requests are scheduled, which is why the score reflects high attack complexity. Public proof-of-concept scripts are circulating all the same, and the PHP project reports a demonstrated remote code execution path against mod_php with default limits that triggers before any application code runs.

Fixed versions

PHP branch	Fixed in
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

Linux distributions often backport fixes while keeping the old version number, so check your vendor's advisory rather than relying on php -v alone.

PHP 8.1 and earlier are outside regular upstream support. The PHP project has published limited source-level backports for 7.4, 8.0 and 8.1 only, which helps if you build PHP yourself or your distribution ships them. Anything older than 7.4 will not receive a fix from the PHP project. Qualys estimates that around 71% of PHP installations with a detectable version are on end-of-life branches from 5.4 to 8.1. For those systems, a supported version is the only complete remedy.

Is it being exploited?

The honest answer is that reporting is mixed, and it has shifted over the week.

Cloudflare reports attack traffic against its customers following the leak, including attackers changing their payloads to try to evade its protections.
CISA's alert, last revised on 23 October, said it had not observed successful exploitation in the wild at the time of publication.
Palo Alto Networks' Unit 42 reported post-compromise activity at a European government agency running a vulnerable PHP application, then retracted the link on 25 October, saying it could not confirm that the initial access was through these CVEs.

The sensible reading is that scanning and attempted exploitation are real, confirmed successful exploitation is still being established, and the window to patch before it becomes routine is short. Palo Alto Networks' Cortex Xpanse telemetry counted more than 22 million potentially exposed instances.

On 23 October the PHP project published an advisory for a separate remote code execution issue involving the session upload progress feature. It affects fully patched releases, including 8.5.12, and is expected to be fixed in the next regular release. It requires an unusual combination of configuration and application code. Cloudflare's WAF rules cover known exploit attempts, but only where session.upload_progress.name is left at its default. Treat it as something to track, and apply the interim mitigations below.

What to do this week

The NCSC, CISA and the PHP project give consistent advice. In order:

Find every PHP installation. Include internet-facing servers first, but also containers, build images, shared hosting, staging environments, and PHP bundled inside other products such as control panels and CMS appliances. If you use Plesk, for example, update Plesk itself. The Dutch NCSC maintains an inventory of affected third-party products that is worth checking against your vendor list.
Patch the runtime. Move to a fixed version, or a vendor build that includes the backport. Restart or redeploy every worker afterwards, and confirm the version actually serving web traffic, not just the one on the command line.
If you cannot patch yet, apply the interim mitigations. The PHP project's guidance includes disabling session.upload_progress.enabled at the server level (a restart is required, and ini_set() or .user.ini is not sufficient), setting fatal_error_backtraces=0 on PHP 8.5, enforcing tight request-size and upload limits at the web server or proxy, blocking multipart requests if the application does not use them, and using container or cgroup memory limits as an availability boundary. On PHP-FPM, pm.max_requests=1 closes the stale-state path if you can wear the performance cost. These reduce exposure. They do not replace the fix.
Use a web application firewall as a second layer. Cloudflare, Palo Alto Networks and others have shipped rules. Cloudflare itself stresses that a WAF is defence in depth, not a substitute for patching.
If you run PHP 8.1 or earlier and cannot upgrade, take the system offline or isolate it. CISA says organisations in this position should take PHP-based systems offline until they can be patched or updated. The NCSC says to consider it when mitigations are not possible or will take too long.
Hunt for signs of compromise. Look for PHP worker processes spawning shells, downloading tools or making unexpected outbound connections, and for new or modified PHP files in web-writable directories. CISA has published a SIGMA detection rule. If a system was internet-facing and unpatched while the proof-of-concept code was circulating, assume you need to check, and rotate any credentials that were available to that PHP process.

The bigger lesson: end-of-life runtimes are a standing liability

PHP2Shell is a sharp reminder of something that is easy to defer. When a runtime reaches end of life, every future vulnerability becomes permanent. There is no patch coming, and the choices narrow to upgrading, isolating or accepting the risk.

Many organisations we speak to are in exactly this position. A business-critical application was built a decade or more ago on PHP 5 or 7, it still works, and the original developers have moved on. Upgrading the runtime in place often breaks deprecated functions, old framework versions and unmaintained dependencies. There is no test suite to tell you what broke. So it waits, until a week like this one.

How ToolTwist can help

We build and maintain software for enterprises, ISVs and regulated teams in Australia, the Philippines and across Asia-Pacific. We hold a SOC 2 Type 1 attestation for our delivery process, we run PHP, Node.js and Java estates for clients on GCP and AWS, and we have spent the last two years using AI-assisted methods to move old codebases onto supported stacks faster than a conventional rewrite.

Here is what that looks like for PHP2Shell, in the order you will need it.

This week: a PHP exposure check

A fixed-scope engagement of three to five business days. You get:

An inventory of PHP across your estate. Servers, containers, build images, shared hosting, and PHP bundled inside control panels, CMS appliances and vendor products. We confirm the version that is actually serving traffic on each one, not the one php -v reports.
A risk-ranked list. Each installation classified by exposure (internet-facing or internal), handler (mod_php, FPM, CGI), branch (supported, backport-only, or no fix available) and business criticality.
Mitigations applied, not just recommended. For anything that cannot be patched inside the week, we apply the PHP project's interim configuration, put request and upload limits in place at the proxy, and confirm WAF rules are in block mode.
Compromise triage. We run CISA's SIGMA rule and the published indicators across your exposed systems, check web-writable directories for new or modified PHP files, and review outbound connections from PHP workers. If we find something, we tell you straight away and work alongside your incident response provider. We are not a forensics firm and will not pretend to be one.
A credential rotation list. Every secret that was available to a PHP worker on an exposed system, so you can rotate them in a known order.

To start, we need read access to your hosting, a list of domains and hostnames you believe run PHP, and one person on your side who can approve configuration changes. Most clients can give us that in a day.

This month: patch, contain and stop this happening again

Once the immediate exposure is known, the next step is making sure the next runtime CVE is a rebuild, not a crisis. Depending on where you are, this covers:

Runtime upgrades on supported branches. Moving 8.2 and later to the fixed releases, with a smoke test that proves the application still works, and a rollback path.
Containerising the PHP workloads that cannot yet be upgraded. A pinned, reproducible image with the interim mitigations baked in, memory limits enforced at the cgroup level, and a least-privilege service account. A runtime patch then becomes an image rebuild and a redeploy, not a server-by-server change.
A deployment pipeline you can trust under pressure. Build, test and deploy automated so that a security release goes out in hours, with an audit trail of what changed. This is the same change-management discipline our own SOC 2 controls require.
WAF, segmentation and egress control. Rules in block mode, PHP hosts separated from databases and internal services, and outbound connections from web workers restricted so a compromised worker has nowhere to go.
Logging, alerting and a runbook. Worker process monitoring, file integrity checks on web roots, and a short incident response runbook for PHP workloads that your team can follow at 2am.
Runtime and dependency monitoring. End-of-life dates tracked for every language runtime, framework and major library in your estate, with alerts well before they lapse.

This quarter: get off end-of-life PHP for good

For the application that cannot be upgraded in place, we migrate it. We offer two paths, and we are honest about which one fits.

Upgrade to supported PHP on a current framework such as Laravel or Symfony. The right choice when your team knows PHP, the codebase is coherent, and the business logic is worth keeping as-is.
Rebuild on a modern TypeScript and Node.js stack. The right choice when the framework is abandoned, the application needs to change anyway, or you want one stack across your estate.

Either way, the method is the same, and it is where AI-assisted engineering makes the biggest difference:

Characterise the existing system. We use AI tooling to read the whole codebase, document what it actually does, and extract the business rules that nobody has written down. We describe this in When the Code Becomes the Spec.
Pin current behaviour with tests. Before changing anything, we generate characterisation tests against the running application, so the migration has a definition of done that is not "it seems to work".
Stabilise first. Patch or isolate the current system so there is no pressure to cut over before the new one is ready.
Migrate in slices. Route by route, module by module, with the old application retired behind a proxy as each slice goes live. There is no big-bang cutover, and the business keeps running throughout.

We have used this approach to move an AWS Amplify and Lambda application to Next.js in a fraction of the original build time, and to rebuild our own web designer on a current stack. Both are written up in Old Gauges: Migrating Frameworks with AI and ToolTwist website Designer, rebuilt with AI. The economics are different from a traditional rewrite, which is usually why the migration never got funded in the first place.

Who this is for

CTOs and engineering leads with an internal team that is already fully committed. We plug in alongside your people, take the exposure check and the containment work off their plate, and leave them focused on the roadmap.
Businesses running a critical application whose developers have left. You know it is on old PHP. You do not know what it would take to fix. We can tell you within a week, with a costed plan rather than a vague warning.
Managed service providers and technical support companies with dozens of client sites on PHP. We can run the exposure check across your client base and handle the remediation under your brand, so you are the one who called your clients first rather than the one who got the call.

Talk to us

If you are not sure where PHP is running in your organisation, or you already know that an ageing application is overdue for attention, book a call. Tell us roughly how many hosts you have and what you think they are running. We will come back within one business day with a scope for the exposure check, and we can start this week.

Sources

This article reflects public information as at 26 October 2026. The situation is changing quickly, so check the primary sources above for the latest guidance.