PHP2Shell: what happened, what to do now and how to be ready next time

If you run a website or web application, you may have seen the news about two serious flaws in PHP, which the security industry has taken to calling PHP2Shell (an industry name, not PHP's). In brief: a fix has been available since 21 October, the safe response is to find where PHP runs and update it, and a server that was exposed and unpatched should be checked as well as fixed.

Eastpoint's own work is in .NET, TypeScript and JavaScript, React and Next.js. We are covering this because the right response, and the preparation that makes it easier, is the same for any runtime. This article is as of 8 November 2026.

It has three parts: how this came about, what to do now, and how to be ready next time. A technical box in part two is for whoever looks after your servers.

1. How it came about

PHP's security team published two flaws on 21 October 2026, CVE-2026-109618 and CVE-2026-109619. Each lets an attacker who can reach a PHP web server run commands on it without logging in, and PHP rated each 9.2 on the CVSS v4.0 scale, which is in its critical band.

Both are memory-safety flaws. PHP's engine is written in C, where the programmer manages memory by hand, and some mistakes in that handling can be turned into control of the program.

• CVE-2026-109618: if the server runs out of memory at an awkward moment, PHP can be interrupted while the data for a request is only partly set up, and the clean-up that follows treats it as valid.
• CVE-2026-109619: state belonging to one request can survive after its memory has been freed, and a later request handled by the same worker process may use it.

The researchers who found them reported them privately, as is normal; PHP's advisories credit several teams, including Wiz and Calif. watchTowr reports that details leaked on 20 October ahead of a planned 22 October disclosure, and that exploitation was seen from 21 October, the day the fixes came out. PHP's advance notice of 20 October announced a release for 21 October, and the fixes arrived that day. watchTowr is a secondary source, so treat its timeline as a good lead rather than a record.

On 26 October the US agency CISA added both flaws to its Known Exploited Vulnerabilities catalogue. On 28 October it added a Linux kernel flaw, CVE-2026-46300, noting that it can be chained with the PHP flaws to plant a web shell and run commands as the most privileged user. Put plainly, attackers are using these flaws.

2. What to do now

The UK's NCSC set out its actions on 21 October. In plain terms:

1. Find all your PHP. Start with anything reachable from the internet. The NCSC is explicit that you should not limit the search to old versions.
2. Update PHP, internet-facing systems first, and update the server's operating system too. Its Linux kernel fix closes CVE-2026-46300, the flaw attackers chain with these to take full control of the server.
3. If you cannot update yet, apply the temporary measures PHP has published, or consider taking the system offline until it is fixed.
4. If a system was exposed and unpatched, check it for signs of compromise, including backdoors. The NCSC suggests an NCSC-assured incident response provider if you lack the skills in-house.
5. Ask your suppliers. Appliances, hosting panels and packaged products often bundle PHP, and their vendors have to issue the update.

Patching closes the hole. It does not remove anything already planted. So our advice, in line with the NCSC's, is that a server which was internet-facing and unpatched at any point from 20 October, when the details leaked, should be treated as possibly compromised until someone has checked it. That is a calm precaution rather than a cause for alarm, and checking is the way to settle it.

Technical box: versions and settings (as of 8 November 2026)

• Fixed versions, per PHP's security announcement: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all released on 21 October. Check php.net for anything newer.
• PHP 8.1 and older get no official release. PHP's security team published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and long-term-support vendors backport fixes. Check with your vendor, or upgrade. watchTowr (a secondary source) reports that 7.3 and older, including PHP 5, are also affected and have no official fix, although some commercial support vendors sell fixes for them.
• PHP 8.2 reaches end of life on 31 December 2026.
• Highest risk: Apache with mod_php, where PHP's advisory reports a working exploit with default input and memory limits. PHP-FPM is not safe either: PHP's CVE-2026-109619 advisory reports a working exploit against PHP-FPM as well as mod_php.
• Restart every PHP worker after updating or changing settings.
• No setting fully mitigates the flaws. For CVE-2026-109619, the advisory's main partial measure is shown below. It must be set in php.ini, the FPM pool or server configuration, not with ini_set() or an FPM .user.ini file.

session.upload_progress.enabled = 0

A related issue, CVE-2026-115560, was covered by an informational advisory on 23 October, which recommends the same setting. The PHP security advisories list the other partial measures, such as limiting request size.

3. Being ready next time

There will be another one, in PHP or elsewhere. The NCSC has written about preparing for a "vulnerability patch wave", advising organisations to patch internet-facing systems first, apply updates faster and by default, and replace technology that can no longer be patched. These habits make the difference:

• An inventory. A list of every runtime and framework you use, its version, and whether it faces the internet. This was the first step above, and the hardest to do in a hurry.
• Supported versions only. Once a version is out of support, a flaw like this gets no official fix. That is the point of our article on what out of support means, and the same logic applies to .NET, as in our piece on .NET 8 and 9 reaching end of support.
• A patch process with a target time. For example, critical fixes on internet-facing systems within a few days. It only works if releases are repeatable and tested, which is where dependency updates and a reliable release pipeline come in.
• Monitoring that would show something unusual. Our piece on monitoring and alerting covers this.
• Layers of defence. Least privilege for each server, separation between systems, limited internet exposure, and perhaps a web application firewall. A firewall can reduce risk but it is a partial measure, not a cure.
• A named person accountable, and a named backup. When the news breaks, someone should already know the question is theirs. Your auditors and insurers will ask similar things, as we describe in what an auditor or insurer will ask.

A sensible first step

Build the inventory first. List every application and server, the runtime and version each uses, and which are reachable from the internet. Note the person responsible for each, and mark any that are on an unsupported version or that you cannot find an owner for.

For an independent view of how a bespoke system of your own is looked after, see what a software health audit covers; our software care page explains how we approach the work.