A data centre corridor lined with server racks

php2shell: what CISOs need to do about this week's critical PHP flaws

On Wednesday 21 October, the PHP project released emergency updates for two critical vulnerabilities in the PHP engine itself. Both can let an attacker who has no login run their own code on a web server. Proofs of concept are already circulating, and the PHP Foundation's message is short: if you run PHP, update now.

PHP still sits behind a huge share of the web. As the PHP Foundation puts it, that includes "government services, online stores, banks, media sites, and much of the software that businesses rely on every day." So this is not a niche developer issue. It is an estate-wide risk, and it lands on the desks of CISOs and the CIOs who own the infrastructure.

What happened

The flaws, CVE-2026-109618 and CVE-2026-109619, have been nicknamed "php2shell". Each carries a CVSS v4.0 score of 9.2. They are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

The first is a memory corruption bug in how PHP handles running out of memory. If a request hits PHP's memory limit at exactly the wrong moment, PHP can leave half-built internal data behind and later treat it as valid. The second involves stale state: after certain errors, a PHP worker can keep pointing at memory from an earlier request, which a later request can then use.

Both live in code that almost every request touches, which is what makes them serious. According to php.net, every PHP installation that serves web requests is at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP team considers mod_php the highest-risk set-up, with a demonstrated exploit where a single unauthenticated request triggers the attack before any application code runs.

The release was brought forward by a day. The two CVE numbers began circulating online on 20 October, so the PHP project published its advance notice early and moved the release from 22 October to 21 October. The Foundation explains that releasing immediately would have left many users without an easy way to update while distributors were still packaging the fix. CERT-EU says technical details are now being discussed publicly and early proofs of concept have begun to circulate, which "raises the likelihood that attackers are already exploiting the vulnerabilities." Vercel's security bulletin goes further, reporting that working public exploits are available and that exploitation attempts have been seen across the industry.

Who is exposed

The short answer is anyone running PHP to serve web traffic. That includes the platforms built on it. Vercel notes that WordPress, Drupal, Laravel and Magento are affected when they run on a vulnerable PHP runtime. The flaws are not in those products. They are in the PHP engine underneath, which is why updating your application code or plugins does not fix the problem.

The harder group to deal with is older PHP. Versions 8.1 and earlier no longer receive updates from the PHP project. AWS's bulletin lists PHP 5.4 to 8.1 as end of life with no planned upstream fix, and says migration to a supported branch is required. Because of the severity, the PHP security team has published minimal source backports for PHP 7.4, 8.0 and 8.1 for organisations that build from source, and some Linux distributions and long-term support vendors offer backported fixes. But if your estate still has old PHP, this is the week that stops being a technical debt item and becomes an active risk.

There is also the PHP you do not know you run. CERT-EU points out that many commercial and open-source products use PHP behind the scenes and could be affected even if they never expose a PHP installation directly. It recommends a list maintained by the Dutch National Cyber Security Centre (NCSC-NL) on GitHub to help identify third-party software that embeds PHP.

What to do now

1. Patch, and check the patch landed. Updating to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 is the only complete fix. Linux distributions and long-term support vendors received the patches in advance, so check your vendor's packages. For containers, Vercel's advice is to rebuild with an updated PHP base image and redeploy, then confirm the deployment actually serving traffic is running the patched runtime. Patching a developer laptop does not count.

2. Find the forgotten estates. Marketing microsites, old campaign pages, intranet tools, partner portals and that one internal app nobody has touched since 2019. These are the places old PHP tends to hide. Start with anything facing the internet.

3. Make a decision on end-of-life versions. For every system on PHP 8.1 or older, choose: migrate, get a backported fix from a vendor, or take it off the internet. It is also worth flagging that PHP 8.2 itself reaches end of life on 31 December 2026, so anything on 8.2 needs an upgrade plan too.

4. Ask your suppliers and hosts. Who manages PHP for each service? The answer varies more than people expect. AWS's bulletin is a useful example of how responsibility splits. AWS says its own services are not impacted and it has updated managed options such as Elastic Beanstalk platforms. But AWS Lambda has no managed PHP runtime, so customers running PHP in custom runtimes or containers must update it themselves, and running Lightsail instances cannot be updated in place: customers need to create new instances from updated blueprints. The same question applies to every hosting provider, agency and SaaS supplier you rely on.

5. Use interim measures, but do not rely on them. If you cannot patch straight away, php.net and CERT-EU set out configuration changes that reduce exposure to specific attack paths. They include setting memory_limit to -1 at an administrative level, lowering post_max_size, disabling session upload progress and restarting every worker. Both are clear that these do not make an installation safe. Web application firewall rules can buy time too: Vercel deployed protections before public disclosure and AWS is updating its AWS WAF PHP managed rule group. Both stress that this does not replace patching.

6. Isolate what you cannot fix. CERT-EU advises considering isolating internet-facing applications from public networks until a fix is applied and verified. CERT/CC adds network segmentation, running PHP with the minimum privileges it needs, and watching for unusual PHP process behaviour.

Not just PHP

PHP was not the only runtime shipping security fixes this week, although the other updates are separate issues, not versions of php2shell.

Node.js released 22.23.4, 24.22.1 and 26.12.1 on 21 October. The most severe fixes are rated high, including a flaw in Node's Brotli decoder that the project says permits remote code execution.
Python shipped expedited releases (3.15.1, 3.14.9 and 3.13.17) on 21 October to bundle an updated certifi, the package many Python applications use for trusted certificates. Python's security team rated the certifi update critical: it removes root certificates from a certificate authority whose intermediates were revoked after a key compromise. The advice is to upgrade certifi and rebuild container images.
Go released 1.27.3 and 1.26.10 on 19 October, blocking trust in a small set of intermediate certificates over concerns about a specific certificate authority, and recommended upgrading immediately.
Java received Oracle's quarterly Critical Patch Update on 20 October, with 55 new security patches for Oracle Java SE, 49 of which may be remotely exploitable without authentication. Oracle also issued a separate Java security alert that distrusts a set of intermediate certificates.
Ruby released 4.0.9, 3.4.12 and 3.3.13 on 23 October, fixing bugs in its regular expression engine that could lead to remote code execution in applications that compile patterns supplied by users.

The common thread is that runtimes are infrastructure. They sit underneath almost every application, and they need the same patch discipline as operating systems.

Inspired's take

The board-level lesson here is not really about PHP. It is about how fast the ground is moving under software everyone takes for granted.

The PHP Foundation's own account is unusually candid. Early signs of the memory problem were found in 2024, but a fix stalled over difficult trade-offs, which the Foundation calls "a structural failure, caused by both the security team's decision process and its lack of resources." The full impact only became clear after reports from Calif, OpenAI and Wiz between August and September this year. AI-assisted research is also changing the volume. The PHP security team has published 15 CVEs since 1 July and worked through more than 100 reports that turned out to be invalid, duplicates or impossible to reproduce. As the Foundation says, "Tools now find bugs faster than ever, for defenders and attackers alike."

For CISOs, that suggests three questions for the board:

Can we list every runtime we depend on, and every version? As we wrote on Wednesday about AI agents, you cannot protect what you cannot count. Software inventories need to go below the application layer.
How quickly can we patch something critical across the whole estate? Not just the systems we run, but the ones our suppliers run for us. If the honest answer is weeks, that is the gap to close.
Are we investing in the open source we rely on? The PHP Foundation is asking companies that build on PHP to sponsor its security work at a level that reflects how much they rely on it. That is a fair question for any organisation whose revenue runs through open source code.

php2shell will be patched, and most organisations will get through it. The ones that do it quickly will be those that already knew where their PHP was.

Join the conversation

How did your team handle this week's PHP release, and did it turn up any systems you did not know about? Share your experience in the comments, and join fellow security leaders at our next CISO summit to compare notes.