The October 2026 PHP vulnerabilities: who is exposed and what to do this week

On October 21, 2026 the PHP project released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known as php2shell, that allow an unauthenticated web request to run code on the server. Both carry a CVSS 4.0 score of 9.2. Every PHP installation that serves web requests is affected, and the PHP team rates Apache with mod_php as the highest-risk setup because a demonstrated exploit fires before any application code runs. The Canadian Centre for Cyber Security issued alert AL26-026 the same day. On October 26, 2026, CISA added both CVEs to its Known Exploited Vulnerabilities catalog, which means exploitation has been confirmed. US federal agencies must patch by October 29, 2026. If you run a website, a web application, an intranet tool or a vendor appliance built on PHP, this is the week to find it and patch it.

Update October 26: CISA confirms active exploitation

On October 26, 2026, CISA added CVE-2026-109618 (listed as a PHP memory corruption vulnerability) and CVE-2026-109619 (a PHP stale internal request-state vulnerability) to its Known Exploited Vulnerabilities catalog. A KEV listing is CISA's formal statement that a flaw is being exploited in the wild. Under Binding Operational Directive 26-04, US federal agencies must remediate both by October 29, 2026. CISA marks forensic triage as required and use in ransomware campaigns as unknown.

CISA's revised alert goes further than the original. Organisations that cannot update immediately, or that still run PHP 8.1 or older, should take PHP-based systems offline until they can be patched or updated. A web application firewall may provide some protection but is not a substitute for the update. Watch for PHP worker processes launching shells or downloading tools; CISA published a SIGMA detection rule for this on October 23. The Cyber Centre's alert, updated October 23, still described no identified active exploitation, which shows how quickly this moved in five days.

Update October 23: a third CVE the October 21 releases do not fix

The PHP Security Team published another remote code execution vulnerability, CVE-2026-115560, on October 23, 2026. It is not addressed by PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, so a server on one of those releases is patched for php2shell but not for this one. The Cyber Centre added it to AL26-026 as Update 1.

The exposure is narrower. Exploitation requires an uncommon combination of configuration and application behaviour, and applications that do not change the serialization handler at runtime are not exposed. Until a fix ships, the PHP Security Team recommends keeping session.upload_progress.enabled set to 0. That is the same setting already recommended as a stopgap for CVE-2026-109619, so if you applied it on October 21 and left it in place, you need nothing extra. If you removed it after updating, put it back.

What are CVE-2026-109618 and CVE-2026-109619?

Both are memory-safety bugs in the PHP engine itself, not in any one application. The first, CVE-2026-109618, is triggered when a request hits the memory limit at the wrong moment: PHP can be interrupted while its internal request data is only partly set up, and the cleanup that follows treats the half-built data as valid. The second, CVE-2026-109619, is a use-after-free: a fatal error can leave internal state pointing at memory from a previous request, and the next request handled by the same worker reuses it. The PHP Foundation reports full remote code execution was demonstrated on Apache with mod_php on default settings for both, and confirmed on PHP-FPM through application-level code paths for the first.

The disclosure was messy. The CVE numbers leaked on forums around 15:00 UTC on October 20, with a wrong release time and a wrong CVSS score of 10.0. The PHP team pulled the release forward a day, from October 22 to October 21. A researcher's demonstration video was posted by mistake that evening and spread, which the Foundation says accelerated the proof-of-concept exploits that circulated on release day. Both the Cyber Centre and the United States cybersecurity agency CISA said they had not observed exploitation at the time of their October 21 alerts, and both said that could change quickly. It did: CISA confirmed active exploitation with its Known Exploited Vulnerabilities listing on October 26 (see the update above).

How many websites are exposed?

The honest answer is most of the web, and the version data is worse than the headline. W3Techs, which surveys the technology behind the top ten million sites, reports on October 22, 2026 that PHP is used by 69.3% of all websites whose server-side language is known. WordPress alone, which runs on PHP, powers 39.6% of all websites and 58.3% of sites with a known content management system.

The fix only exists for PHP 8.2 and newer. According to the same W3Techs data, PHP 8 accounts for 65.3% of PHP sites, PHP 7 for 26.9% and PHP 5 for 7.7%. Within PHP 8, 15.2% of sites run 8.1 and 5.8% run 8.0, both of which left official support before this advisory. Add those up and roughly 48% of PHP websites are on a branch with no upstream patch at all. Those sites depend on a Linux distribution or a long-term-support vendor backporting the fix, or on an upgrade they may have been putting off for years. PHP 8.2 itself reaches end of life on December 31, 2026, so sites on 8.2.35 have bought weeks, not years.

One more figure from the PHP Foundation puts the workload in context: the PHP security team has published 15 CVEs since July 1, 2026 and handled more than 100 reports that turned out to be invalid, duplicates or not reproducible. The team is small and runs by consensus, and the Foundation calls the months it took to settle a fix for the first bug a structural failure it is now changing.

Why version numbers can mislead you

Debian, Ubuntu, Red Hat and their derivatives backport security fixes without changing the version number. A server reporting PHP 8.2.29 can be fully patched, and a server reporting 8.3.36 can be an unpatched build behind a cache that sets the header. That is why no outside scan can give a reliable yes or no, and why both government alerts tell you to inventory PHP on the server rather than trust what the website advertises. Our free check reads what your site tells the world and tells you plainly which of five situations you are in, then points you to the server-side confirmation.

What should you do this week?

The sequence below follows the Cyber Centre's alert and the PHP project's advisory. Most organisations can finish it in a day if they know where their PHP is.

• Inventory every PHP install, not just the public website. Web mail, wikis, ticketing, intranets, monitoring dashboards and vendor appliances often bundle PHP and are the ones nobody remembers. CISA's alert makes the same point: PHP is frequently embedded in other software.
• Patch internet-facing systems first. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or install the distribution package whose changelog names both CVEs, then restart PHP-FPM or Apache so every worker picks up the new build.
• For PHP 8.1 and older, get a written answer from your vendor on whether a backport exists. If it does not, the Cyber Centre's advice is to take the system off the public internet until it is upgraded. The PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build from source.
• If you cannot update today, apply the PHP project's interim settings: memory_limit set to -1 where applications cannot override it, a low post_max_size (8M without uploads, 32M with), session.upload_progress.enabled set to 0, and on PHP 8.5 fatal_error_backtraces set to 0. Restart every worker. The PHP team is explicit that these reduce exposure to the confirmed paths and do not make an install safe. Keep session.upload_progress.enabled at 0 even after you update: it is also the recommended mitigation for CVE-2026-115560, which the October 21 releases do not fix. CISA's revised advice is blunter: if you cannot update, or you are on PHP 8.1 or older, take the system offline until you can.
• Review web server and endpoint logs for unusual requests and new processes, and report suspected compromise to the Cyber Centre. Now that exploitation is confirmed, look in particular for PHP worker processes that spawn a shell or download tools; CISA's SIGMA rule covers this pattern. The absence of log entries does not prove you were not hit.
• Write down what you did. A one-page record of hosts, versions and dates is what an insurer, a client questionnaire or a CPCSC assessor will ask for next.

What this means for a Canadian SMB

If an agency or hosting company runs your site, send them the advisory link today and ask for the patched version in writing. If you run it yourself, the check and the steps above are enough for one site. If you have several, or you are not sure what runs PHP, that is the point where a managed security provider earns its fee: inventory, confirmation on the server, interim settings where an update has to wait, and the record at the end. HuCortex does this as a fixed-scope engagement that usually takes a day.