PHP Zero-Day Incoming (CVE-2026-109618): What We Know and How to Prepare

This is a developing story. Details below are based on early, unverified reporting and will be updated as official advisories are published.

2026-10-20 23:00 – Initial Post

A critical remote code execution vulnerability in PHP, tracked as CVE-2026-109618 (with a companion flaw, CVE-2026-109619), is reportedly about to be disclosed publicly. According to early reporting, the issue affects every version of PHP from PHP 5 onward. If confirmed, that would put an enormous slice of the internet in scope at once.

I want to be straight with you; as of writing, this is still an evolving situation. No official advisory, patch, or severity score has been published, and the full technical details are not yet public. We are sharing this now because the window to prepare is short, and the organisations that act before disclosure are the ones that patch within hours instead of days.

What we know so far

Here is the current picture, separating what is reported from what is confirmed:

Treat the “all versions” claim with appropriate caution. It originates from early, unverified reporting rather than a vendor advisory. That said, planning for the worst case here costs little and buys you time. The sensible assumption until proven otherwise is that anything running PHP is potentially in scope.

Why the blast radius is so large

PHP is not a niche technology. It still powers a very large share of the world’s websites and web applications. WordPress alone, which is built on PHP, sits behind a huge proportion of the internet, and that is before you count Drupal, Joomla, Laravel apps, bespoke internal tools, and countless line of business systems.

A vulnerability that spans “all versions from PHP 5 onward” is unusual precisely because it ignores the normal safety net. Most serious bugs affect a window of versions, so a reasonably current estate is often fine. If this one truly reaches back to PHP 5, then legacy systems that have been quietly running untouched for years, the ones nobody wants to reboot, are exposed alongside modern, fully patched deployments.

The part that is easy to overlook: PHP does not only run your public website. It frequently sits underneath things you would never think of as “a PHP app”: the admin console of an appliance, a vendor’s web management portal, an SSL VPN login page. That is where this gets interesting for infrastructure teams.

Your WordPress site probably isn’t the real problem

When a PHP vulnerability makes the news, the first reaction for most organisations is to look at their website. That makes sense, because so many sites run on WordPress, and WordPress runs on PHP. But here is the point worth pausing on: your public website is probably not the most sensitive PHP system you own.

If your public website gets taken over, it does not look great. Nobody wants a defaced homepage or an embarrassing headline. But if you have built things sensibly, your public facing website is hosted away from your core infrastructure, and it has no route to your sensitive data or PII. A compromise there is painful, not catastrophic.

The systems that should worry you more are the ones running PHP that can reach sensitive data or perform sensitive functions. Your CRM platform, full of customer records? The web interfaces used to manage your IT infrastructure, your firewalls, your VPNs, your appliances? Those are the places where a PHP flaw stops being an embarrassment and becomes a genuine breach. Spend your attention there first.

The vendor question: what’s running under the hood?

Here is an honest caveat is most IT infrastructure and security vendors do not publicly document what their products run internally. You will rarely find a datasheet that says “our management interface is written in PHP.” So what follows is informed suspicion, not confirmed fact.

When we look at the historic vulnerability reporting, the CVEs, the advisories, the independent security research, a number of well known vendors have shown signs over the years of PHP sitting in their management or SSL VPN web layers. Based on that track record, these are the kinds of products we would be looking at carefully:

• Cisco: several product lines (notably Small Business / RV series routers and some management tools) have had CVEs naming specific .php scripts.
• Palo Alto Networks: the PAN-OS management web interface has a documented history of PHP components.
• Fortinet: mixed. Core FortiOS is largely C/CGI, but other more niche products in the portfolio have shown PHP.
• SonicWall: the SMA / SRA SSL VPN appliances have a well documented history of .php files in the web application.
• Check Point: the Gaia Portal (WebUI) has been described in research as an Apache + PHP stack.
• Smoothwall: historically built on Perl rather than PHP, so a weaker candidate, but worth verifying on your own estate.

To be absolutely clear: none of these vendors has been confirmed as vulnerable to CVE-2026-109618. We are flagging them because, if the “all versions” claim holds and any of these products do use PHP in the way historic reporting suggests, their internet facing and internal management interfaces could be a high value target. That uncertainty is exactly why the next point matters more than ever.

What to do now

You cannot patch a vulnerability that has not been published yet, but you can make sure that when the fix lands, you are ready to move within hours rather than days. Here is the prioritised prep work we are recommending to our customers:

• Inventory your PHP estate. Identify every server, container, and application running PHP, and note the version on each. You cannot protect what you have not mapped.
• Decide what comes off the wire. Determine whether any applications should be temporarily removed from service to protect the business and its data, and get prior approval from your senior leadership team. Focus first on internet facing web apps and any sensitive internal systems, including network device management portals.
• Patch to the latest now. Get current on the newest supported release to get used to the process and minimize any jumps you need to make between versions. At time of writing (check for known issues) you probably want to be targetting 8.2.34, 8.3.35, 8.4.26, or 8.5.11.
• Plan upgrades and decommissions. Anything on an unsupported version needs a plan to either upgrade or retire it. To be fair this was the case before you read this post.
• Build a prioritised patch list. Work out what you patch first when the fix drops, the most sensitive and most exposed systems, and the order for everything else.
• Prepare to patch fast. Line up maintenance windows now and confirm your test and deployment process so you can roll an update out within hours of release.
• Reduce exposure. Don’t expose php-cgi directly, restrict admin and internal endpoints, and make sure your WAF rules are current.
• Review plugins and frameworks. Update CMS plugins and themes (e.g. WordPress) and remove anything unused.
• Watch for the announcement. Monitor php.net, your OS vendor’s security notices, and our updates.
• Lean on your firewall. Ensure TLS decryption is enabled and watch for your firewall vendor releasing IPS signatures to protect against the CVE.

The bottom line

We don’t yet know the full scope of CVE-2026-109618, and we don’t yet know which vendors will turn out to be affected. What we can say is that the fundamentals matter more than ever.

There are a few key security controls at play here, and they are exactly the ones we routinely find companies missing when we run a SURE assessment against them:

• Know your inventory. Plenty of organisations, especially those on a Cyber Essentials journey, keep a solid inventory of their hardware but forget their applications and the sub applications hidden inside them. You cannot protect what you did not know was running PHP.
• Don’t expose sensitive systems to things that do not need access. Management interfaces should not be reachable from the general network, let alone the internet. This is Zero Trust and Assume Breach in practice, not just words on a slide.
• Patch regularly. Keeping the lights on should always come before projects. Routine patching also keeps your team well practised in the steps involved, so when a real emergency lands they already know how to respond when things go wrong.
• Be ready to make the hard call. Sometimes the best thing you can do is take a system offline temporarily until a patch is ready. Work out now how your business would cope if you had to do that, rather than deciding under pressure on the night.
• Make your firewall earn its licence. Your firewall vendor will often release an IPS signature before the software vendor issues a patch. The catch is that your firewall can do nothing with it unless it is configured to decrypt the traffic flow. If it is not, why are you paying for that next generation firewall licence?

Get even a few of these right and a PHP flaw buried in a management portal becomes far harder for an attacker to reach, both for this CVE and for the next unknown one after it.

This is a developing situation, and we will update this post as official advisories and patches are released. If you would like help inventorying your PHP estate, locking down your management interfaces, or preparing a rapid patch plan, get in touch. We would rather help you prepare now than respond later.

2026-10-21 07:45 – Update

More detail is now available this moring:

• Severity is confirmed as critical. Both CVE-2026-109618 and its companion CVE-2026-109619 are rated CVSS v4.0 9.2 by the PHP security team. Some early reports quoted 10.0, but 9.2 is the figure the PHP team has given.
• The patch has a firm slot. The PHP security release is scheduled for today, 21 October 2026, at 14:00 UTC (15:00 BST). Pre release reporting points to fixed versions of 8.5.12, 8.4.27, 8.3.36 and 8.2.35, but confirm those against the official release notes before acting. The team has reserved the right to ship earlier if details leak further or exploitation begins.
• Not every version gets a fix. This is the big one. Official fixes are expected only for the supported PHP 8 branches (8.2, 8.3, 8.4 and 8.5). PHP 7.x and earlier, along with the end of life 8.0 and 8.1 branches, are not expected to receive an official patch. If you are running one of those, upgrading or isolating the system is now your only real option, not a nice to have.
• Expect exploitation fast. Researchers at Sansec expect mass exploitation to begin within roughly 15 minutes of the patch going live, so your grace period will be tiny. A working exploit tool, reportedly dubbed PHP2Shell, has already leaked. No in the wild exploitation had been confirmed at the time of writing.

The practical takeaway has not changed, it has just become more urgent. Know what you are running, get supported versions patched the moment the release lands, and get anything unsupported off the wire. We will keep updating this post as the official release notes and version numbers are confirmed.

2026-10-21 10:30 – Update

I have created a short video that talks through some of the content in this post.

2026-10-21 12:45 – Update

The story has moved from researcher chatter to official government guidance, which is a meaningful shift.

• The UK NCSC has issued an advisory. The National Cyber Security Centre is urging UK organisations to prepare for immediate updating of systems using PHP. Its recommended actions line up closely with ours: identify every system running any version of PHP and prioritise the internet facing ones, monitor those systems for malicious activity, apply updates as they land, and keep watching for updates from third party vendors whose appliances and services bundle PHP. That last point is exactly the infrastructure exposure we flagged earlier in this post.
• The NCSC is openly raising the offline option. Where immediate remediation is not feasible, the NCSC says organisations should consider taking the system offline until it can be fully mitigated. When a national cyber authority puts that in writing, the pre approval conversation with your directors is worth having today, not after the patch drops.
• The EU is sounding the same alarm. An EU agency has warned that websites may need to be taken offline while PHP prepares its patches, as reported by Reuters. Two major authorities independently reaching the same conclusion tells you how seriously this is being treated.
• Timing, restated. The NCSC confirms the PHP release is scheduled for today, 21 October 2026, at 15:00 BST (14:00 UTC), and may come earlier.

Since that guidance landed, the picture has sharpened further, reported by Reuters:

• Early attacks may already be emerging. Cloudflare CTO Dane Knecht said on X that the company is seeing early attacks emerge and is pushing firewall rules as a stopgap, while stressing that this is a stopgap only and you should patch the moment PHP releases the fix. Australia’s ACSC says it is not yet aware of active exploitation, so treat this as early and evolving rather than confirmed mass exploitation. Either way, the window is closing.
• A third national agency has weighed in. The Australian Cyber Security Centre has issued guidance mirroring the NCSC and CERT-EU: identify your PHP systems, prepare to patch, and monitor applications for signs of malicious activity.
• The breadth is being spelled out. Security firm Huntress notes that PHP quietly powers WordPress, Drupal, Joomla and Magento, along with shared hosting, control panels and plenty of software that does not advertise that it runs PHP. That is the same under the hood exposure we have stressed throughout. GoDaddy warns the flaws could lead to data theft, website defacement or full system compromise.
• WordPress owners, read this. Wordfence warns that WordPress automatic updates will not apply this fix, because the flaw is in PHP itself, not in WordPress. If you run WordPress, find out now who is responsible for updating PHP on your hosting, because it will not patch itself.

The thread running through the PHP team, the NCSC and the EU is consistent. Get your inventory done, be ready to patch the moment the release lands, and be prepared to pull exposed systems offline if you cannot patch in time. If you have not had the offline conversation with your leadership yet, have it today.

Sources for this update: NCSC: critical security issue affecting PHP and Reuters: EU agency warns websites may need to be taken offline.

2026-10-21 14:20 – Update

With the official patch still pending, code claiming to exploit these vulnerabilities is now circulating publicly, and a demonstration exploit chain known as php2shell has been shown off ahead of the release. A note of caution: security vendors including Tenable have not verified that the circulating code actually works against either CVE, and they warn that unverified exploit code often carries malware, so this is not an invitation to go looking for it or run it.

The takeaway is simpler and more urgent than the detail. Working exploit material is appearing before the fix is even out, which is the worst possible sequencing for defenders. Patch the moment the release lands, and keep exposed systems restricted or offline until you can.

2026-10-21 14:45 – Update

The fix is out. PHP has released 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and all PHP users are strongly encouraged to update immediately. Both CVE-2026-109618 and CVE-2026-109619 are confirmed as critical flaws allowing unauthenticated remote code execution.

• Who is most at risk. Every PHP install serving web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP rates the risk highest for mod_php, where a demonstrated exploit lets an unauthenticated request trigger the attack before any of your application code even runs.
• What the two bugs are. CVE-2026-109618 is an RCE via out of memory corruption. CVE-2026-109619 is an RCE via stale global state, where internal data from one request can survive and be misused by a later request handled by the same worker. Full technical detail is in PHP’s GitHub security advisories.
• Unsupported versions, with a twist. PHP 8.1 and older no longer receive updates from the PHP project, as expected. But given the severity, the PHP security team has published minimal source backports for 7.4, 8.0 and 8.1 to help those building from source or without an LTS vendor. This softens our earlier note. If you are on one of those versions you do have a path, but you will likely need to apply a backport or lean on your distribution rather than a standard update.
• Two practical gotchas. Linux distributions and LTS vendors were given the patches in advance, so check your vendor for packages before assuming you must build from source. And if you rely on the volunteer maintained rpms.remirepo.net, note it will not carry the update today, so switch to distribution packages or build from source.

If you genuinely cannot update right away, PHP has published interim hardening measures that reduce exposure to specific attack paths, but it is explicit that these are not a complete fix and only an update makes an installation safe. Those settings are set out in the official release notes and advisories.

The bottom line: the fix is here, exploit material is already circulating, and researchers expected mass exploitation within minutes of release. This is now firmly a patch now situation. Identify your PHP, apply the update everywhere it runs, and prioritise anything internet facing and anything running mod_php.

Sources for this update: PHP official release and the advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp.