PHP Vulnerability 2026: What Site Owners Do Now

The PHP vulnerability disclosed on 21 October 2026 is really two flaws, CVE-2026-109618 and CVE-2026-109619, and either one can let an attacker run code on a server without logging in. The only complete fix is to update PHP itself to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 and restart every PHP worker. Updating WordPress, a theme or a plugin does not change the PHP your host is running.

This is part 1 of The Web After PHP2Shell, a six-part Ambeltek series on what this week means for how websites are built and run. It is written for owners, marketers and developers who need to know whether they are exposed and what to do next. Every fact below was checked against PHP’s own announcements and the GitHub advisories on 23 October 2026, and where sources disagree we say so. The story is still moving, so treat this as a dated snapshot.

On this page

• What happened between 17 and 23 October
• What is the PHP vulnerability in plain terms?
• Which PHP versions are fixed?
• Are you exposed? A five-minute check
• Is the PHP vulnerability being exploited?
• Do the partial mitigations work?
• How many sites run PHP that cannot be patched?
• Your patch plan for this week

What happened between 17 and 23 October

PHP’s security team gave advance notice on 20 October of a release scheduled for Wednesday 21 October at 14:00 UTC, covering two vulnerabilities that both score CVSS v4.0 9.2. The notice reserved the right to ship early if details became public or exploitation appeared. Details did leak. watchTowr reports that information circulated online on 20 October, ahead of the planned 22 October disclosure, and that it confirmed the flaws were real.

The timeline of the attacks is less tidy than the timeline of the fix. Sansec’s write-up records Cloudflare reporting early attacks at 07:43 UTC on 21 October, more than six hours before the patch. Help Net Security adds that Amazon Threat Intelligence says its honeypot logged an exploitation attempt on 17 October, four days before disclosure, from an address tied to a commercial anonymization service. How that actor obtained the details is unknown.

Who found the flaws is also layered. Cybersecurity Dive credits researchers at Wiz and Calif, with AI models involved in the work. Wiz’s own account says it found the first bug on 19 August with AI tooling and reported it to PHP on 24 August. Part 2 of this series, AI security vulnerabilities, covers why that matters for everyone who runs a site.

The scale is why this reached the front pages. W3Techs reports PHP on 69.3% of websites whose server-side language is known. Pinboard, parts of Wikipedia, 4chan and Something Awful went offline temporarily, NBC News reported, and Cybersecurity Dive lists the Finnish government and the Dutch House of Representatives among those who disconnected sites.

What is the PHP vulnerability in plain terms?

Both flaws are about what PHP does when a request goes wrong. A request can hit a fatal error partway through, most often by running out of memory. The PHP advisories describe what that leaves behind.

• CVE-2026-109618 (out-of-memory corruption). Memory exhaustion can interrupt PHP while internal request data is only partly set up. Cleanup code then treats that half-built data as valid.
• CVE-2026-109619 (stale global state). Internal state that belongs to one request survives after its memory has been freed. A later request handled by the same worker can use it before PHP resets it.

The GitHub advisory for CVE-2026-109618 classes it as a use-after-free (CWE-416), a memory safety fault in PHP’s C engine, not a mistake in anyone’s website code. That distinction drives most of what follows. Wiz says the flaws sit in PHP itself, so even a minimal “Hello World” script on an affected version could be vulnerable, and it demonstrated unauthenticated code execution against the default container images of WordPress, Drupal and Joomla.

The affected runtimes are the usual ones: PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed and FrankenPHP. PHP’s announcement says the risk is highest for mod_php, where a demonstrated exploit lets one unauthenticated request trigger the attack before any application code runs.

Which PHP versions are fixed?

Four supported branches have fixed releases. Older branches do not, which is the uncomfortable part for anyone running a site they have not touched in years.

Sources: php.net announcements, php.net supported versions and the watchTowr FAQ. The watchTowr finding on PHP 7.3 and older is its own, not a PHP project statement.

Two cautions. First, distribution packages often carry a fix under an older version number, so ask the vendor whether the fix is in your build, not just what the number says. Second, 8.2.35 is a real fix with a short shelf life: 8.2 stops receiving security fixes in about ten weeks.

Are you exposed? A five-minute check

Start with one question: does any server behind your site run PHP? WordPress, Drupal, Joomla, Magento, Laravel, Symfony, phpMyAdmin and most hand-built brochure sites do. Then follow the first branch below that applies.

To find your version, check the PHP version selector in your hosting control panel. In WordPress, Tools, Site Health, then the Info tab, then Server, shows it. A command-line php -v can report a different version from the one that serves web requests, so trust the web-serving value. On a managed host, send the support team three questions: which fixed build is installed, whether every PHP worker was restarted afterwards, and whether your plan uses mod_php.

If you run your own servers and want to test them, Help Net Security reports that Searchlight Cyber released an open-source scanner, php2shell-scanner, on 22 October that checks hosts for both CVEs. Run it only against systems you own or are authorised to test.

Is the PHP vulnerability being exploited?

Yes, but how widely is disputed, and the accurate answer changed during the week. As of 23 October the public record looks like this:

• watchTowr says its honeypot network observed exploitation, and notes that CISA had not added either CVE to its Known Exploited Vulnerabilities catalogue as of 22 October. It attributes the exploitation only to its own observations, with no named threat actor.
• Cloudflare and Amazon each reported attempts before the fix shipped, as covered above.
• Sansec’s 22 October update says mass exploitation is less likely than first expected. It reports that public proof-of-concept exploits mostly fail against a default PHP install and usually need an application-level local file inclusion bug as a stepping stone.
• Kevin Beaumont, quoted by Help Net Security, expects a mass of incidents. Wiz called the flaws among the most severe ever found in PHP.

Do not read “less likely than feared” as “safe to wait”. Sansec’s finding is about how easy a public exploit is to run, not about whether private, better-tuned exploits exist. The sensible reading is that patching remains urgent, that panic shutdowns are probably unnecessary where a host has already patched, and that the picture will keep changing. On 23 October PHP also added an informational advisory about session upload progress, with a full advisory for a third identifier, CVE-2026-115560, promised with the next release.

Do the partial mitigations work?

They reduce exposure to specific attack paths. PHP is explicit that only an update is a complete solution. The PHP announcement lists the interim measures:

A web application firewall adds another layer without replacing the patch. Help Net Security quotes Cloudflare’s CTO as saying its rules are available to all customers, including free plans. Treat any firewall rule as a stopgap that buys you hours, not a reason to defer the update.

How many sites run PHP that cannot be patched?

More than most owners assume. W3Techs splits PHP sites by major version, and more than a third are on branches that are out of support.

Estimates of the exposed population vary widely and have not been reconciled. Cybersecurity Dive reports a range from more than 1.3 million vulnerable sites (one researcher) to 22.6 million exposed instances (Palo Alto Networks), and says Cisco estimated that roughly half of internet-facing instances run versions too old to receive the fixes. NBC News reports that Censys counted nearly 55 million web properties running PHP, with no clear count of how many had updated. Treat these as order-of-magnitude figures, not measurements.

Your patch plan for this week

Most of the risk sits in the first day, but the longer tail is where small sites get hurt.

If you manage sites for others, the website maintenance tasks checklist is a good place to turn this into a recurring routine, and WordPress SEO covers the platform most affected.

Where the PHP vulnerability leaves your website

For most owners the immediate job is narrow: confirm the fix is installed, restart, rotate secrets where it applies, and retire PHP versions that cannot be patched. That is a day of work, not a rebuild, and nothing here shows that PHP as a language has failed. Part 3, is PHP dead, takes that question on directly.

The longer job is deciding how much code you want running on a public server at all. Static vs dynamic website tests whether pre-built sites really are safer. If you ever need to take a site down to patch it, website maintenance mode explains how to do it without losing search visibility. The series ends with the future of web development after this week.

If you would rather depend on less server-side code, Ambeltek’s web development service builds sites on Astro, which publishes pre-built pages by default. It is not the right fit for every project, and the static vs dynamic article says where it is not. For the practical background on how a build moves from brief to launch, see our web development process guide, and for what it should cost, how much does a website cost.