PHP2Shell: Two Critical PHP Flaws, and the Question Every Business With a Website Should Ask

On 21 October 2026, the PHP project released urgent fixes for two critical vulnerabilities, now widely known as PHP2Shell. PHP runs a large share of the web, including every WordPress site, so this one reaches well beyond technical teams. If your business has a website, it is quite likely affected.

This article covers what we know so far, what has been fixed, and the questions worth asking whoever looks after your website. We will update it as hosts and vendors finish patching.

Update, 22 October 2026 (afternoon): ASD’s ACSC has reviewed its alert and now says it is “not aware of successful active exploitation within Australia” of these vulnerabilities. Its earlier wording said it was not aware of active exploitation at all. Its advice is unchanged: identify PHP in your environment, apply the available security updates and appropriate mitigations, and monitor PHP applications for suspicious activity.

Short answer

• What: two flaws, CVE-2026-109618 and CVE-2026-109619, that PHP says can be exploited remotely by an attacker who does not need to log in. PHP rates both 9.2 on the CVSS v4.0 scale.
• Who is affected: websites and web applications running PHP. According to Tenable’s analysis, the vulnerable code dates back to PHP 5.4.
• The fix: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Updating PHP is the only complete fix. Plugin and theme updates do not fix it.
• Older versions: PHP 8.1 and earlier no longer get updates from the PHP project. Sites on those versions depend on their host or vendor for a backported fix, or need to upgrade.
• What to do: find out which version of PHP each of your websites runs, and who is responsible for updating it. For most small businesses, that is the hosting provider.

What happened

The timeline moved quickly.

• 20 October: The CVE numbers leaked online before the planned release. PHP announced an urgent security release.
• 21 October: PHP published its advisory and the fixed versions, a day earlier than planned because of the leak. The same day, ASD’s Australian Cyber Security Centre issued a critical alert, advising organisations to identify PHP in their environments and prepare to patch. It has since been updated to note that patches are available.
• 21 to 22 October: ABC News reported that several Australian government websites, including cyber.gov.au, had outages while mitigation work went on. Agencies in the Netherlands, Finland, Denmark and France took services offline as a precaution.

Security firms including Cloudflare and watchTowr report attackers trying to exploit the flaws. The PHP project said it had not identified any working exploits when it disclosed the flaws, and code circulating online that claims to exploit them has not been verified. Treat any such code with caution, as some of it may itself be malicious.

Why it matters if you are not “a tech company”

Most small and medium businesses do not run their own web servers. The website sits with a hosting provider, a web developer or an IT provider, and PHP is updated by whoever runs the server. That is exactly why an alert like this is easy to miss: the business owns the risk, but someone else holds the keys to the fix.

We checked our own website the morning after the release. It runs on managed hosting, and Site Health showed it one version short of the fix. When we asked, our host confirmed it had already applied interim mitigations, was rolling out the patched builds from its upstream supplier, and that the site sits behind Cloudflare’s web application firewall. That is a good answer. But it took a deliberate question to get it, and many businesses would not know who to ask.

Update, 23 October 2026: our host has since confirmed the fix is in place. Site Health still shows PHP 8.3.35, because the platform supplier backported the security fixes into its existing PHP package rather than moving to 8.3.36. This is common with managed hosting (CloudLinux and cPanel’s EasyApache packages work this way), so a version number that has not changed does not necessarily mean a site is unpatched. If your site shows an older version, ask your host whether the fix has been backported, and get the answer in writing.

How Cloudflare’s protection fits in

If your website sits behind Cloudflare, you have an extra layer of protection while patches roll out. In its blog post on the PHP vulnerabilities, Cloudflare says:

• it began deploying protective firewall rules at 3:02 am UTC on 21 October, around nine hours before public disclosure
• the rules are in the Free managed ruleset, so free-plan customers are covered without doing anything
• paid-plan customers have matching rules in the Cloudflare Managed Ruleset, and should check those rules are set to block
• an additional rule on all plans can block a malicious response from the server before it reaches the attacker
• attackers have already tried modified payloads to get around the rules, and Cloudflare is updating them as new techniques appear

Cloudflare is clear that its firewall is defence in depth, not a substitute for the PHP update. Its advice is to patch as soon as possible, and if your host manages PHP, to ask your host to apply the fix.

Questions to ask your host or web developer

1. Which version of PHP is each of our websites running?
2. Has it been updated to a fixed version (8.5.12, 8.4.27, 8.3.36 or 8.2.35), or patched by your platform supplier?
3. If not yet, when will it be, and what interim mitigations are in place?
4. Is our site behind a web application firewall, and is it blocking these attacks?
5. If we are on PHP 8.1 or older, what is the plan to upgrade?
6. Will you tell us if you see any sign the site has been compromised?

If you manage your own servers, PHP’s advisory lists interim settings that reduce exposure (including disabling session.upload_progress and changing how the memory limit is set), with restarts of all PHP workers afterwards. PHP is explicit that these reduce the risk but do not make an installation safe. The update is the fix.

What this looks like in ISO 27001 terms

An alert like this tests whether an information security management system works in practice. It touches several Annex A controls at once.

For organisations working to the Essential Eight, the patch applications strategy expects vulnerabilities in internet-facing services to be patched within 48 hours when they are assessed as critical by the vendor or working exploits exist. PHP2Shell meets that threshold, so the 48-hour clock applies to whoever is responsible for patching, including your host.

The common gap we see is the second row. Many asset registers list laptops and software subscriptions, but not the websites, the hosting account behind each one, or who is contractually responsible for keeping the server patched. Our article on the earlier ASD alert about compromised CMS websites explains why a website belongs on the asset register, and the same lesson applies here. For managed IT providers, we covered a similar situation in what to ask your MSP after an earlier ASD alert.

PHP2Shell is part of a wider pattern. AI is finding vulnerabilities faster than most patch processes were designed to handle. Our article on AI in cyber security looks at what that means for patching and where AI tools help on the defensive side.

Update, 26 October 2026: Node2Shell, the same problem in a harder place

On the same day as the PHP release, the Node.js project fixed ten vulnerabilities, four of them rated high. The one drawing attention, CVE-2026-111497, which researchers at Imperva have nicknamed Node2Shell, is an out-of-bounds write in the Brotli compression library that Node.js bundles. Node.js says malformed compressed input can lead to a crash, disclosure of memory or remote code execution. Google, which maintains Brotli, rated it 9.2 on the CVSS v4.0 scale.

The fixed versions are Node.js 22.23.4, 24.22.1 and 26.12.1. End-of-life versions, including Node.js 20, will not be fixed. Imperva has published a working proof of concept. CISA lists no known exploitation, and we have not seen an ASD alert.

What makes this harder than PHP2Shell is where the vulnerable code lives. Brotli is a library used inside other software: Bun and Google’s Python Brotli package also bundle it, Envoy has been named as affected, and Express 5 and body-parser 2 can decode Brotli request bodies. Plenty of businesses run Node.js without knowing it, inside a booking platform, a website builder or a vendor’s appliance. That stretches the question beyond “which of our sites run PHP?”:

• Does your asset register reach components? Knowing the servers and subscriptions is not enough when the risk sits in a library inside them (controls 5.9 and 8.8).
• Who watches advisories for software you did not write? And how will your suppliers tell you when a component in their product is affected (5.19 to 5.22)?
• Is unsupported software on the register with a decision? Node.js 20 will never be patched, so it needs a recorded decision to upgrade, isolate or accept the risk (8.8, and risk treatment under clause 6.1.3).

Our articles on software supply chain security and on running a vulnerability management process cover how to set this up.

Practical steps now

• List every website and web application your organisation runs, including microsites, booking pages and old campaign sites.
• Ask the questions above of each host, developer or IT provider, and record the answers.
• Check your Cloudflare or firewall settings if you manage them yourself.
• Update your asset register with the hosting provider and patch owner for each site, if it is not already there.
• Record it. Your response to this alert is good evidence for control 8.8 at your next internal audit or certification audit.

PHP2Shell: FAQs

Is WordPress affected?

WordPress runs on PHP, so WordPress sites are exposed through the server’s PHP version. Updating WordPress, plugins or themes does not fix it. The PHP version on the server has to be updated.

My site is behind Cloudflare. Am I safe?

Better protected, but not finished. Cloudflare’s rules block known attack patterns, and it says attackers are already trying to get around them. The PHP update is still required.

How do I check my PHP version?

In WordPress, go to Tools > Site Health > Info > Server. Otherwise, your hosting control panel or your web developer can tell you.

My site still shows an older PHP version. Is it vulnerable?

Not necessarily. Many hosts and Linux distributions backport security fixes into their existing PHP packages without changing the version number, so a site can show 8.3.35 and still be patched. The only way to know is to ask your host whether the fix for CVE-2026-109618 and CVE-2026-109619 has been applied or backported.

Who is responsible for patching?

Whoever runs the server, which for most small businesses is the hosting provider. Your organisation still owns the risk, so it is worth confirming in writing.

How Streamline can help

Streamline helps organisations build ISO 27001 information security management systems that hold up when an alert like this lands, with asset registers that include websites and hosting, supplier arrangements that make patching responsibilities clear, and a vulnerability management process that works in practice. If you would like to talk through how your organisation handles alerts like this, get in touch.

Sources: PHP security advisory, 21 October 2026; ASD’s ACSC, Critical vulnerabilities in PHP; Cloudflare, PHP vulnerabilities WAF protection; Tenable, php2shell FAQ; ABC News, 22 October 2026.

Published 22 October 2026 | Facts checked 22 October 2026 | Next review when hosts finish patching or ASD updates its alert | Jurisdiction: Australia and international | Sources: PHP security advisory (21 Oct 2026), ASD ACSC alert, Cloudflare