The critical PHP vulnerabilities of 21 October 2026: what website owners must do today

On 21 October 2026 the PHP team published a critical security release: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two flaws, CVE-2026-109618 and CVE-2026-109619, which under the right conditions let an attacker with no account at all run code on the server. If your website, store or application runs on PHP (WordPress, Laravel, Symfony, PrestaShop, Magento, Drupal or custom code), this article explains what happened, who is affected and what to do today, not next week.

What was released on 21 October 2026

Four fixed versions are available on php.net: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both vulnerabilities are rated critical with a CVSS 4.0 score of 9.2 out of 10. Researchers nicknamed the pair "php2shell", because they turn a plain HTTP request into access to the server.

• CVE-2026-109618, memory corruption when `memory_limit` is hit: if PHP runs out of memory at the wrong moment, partially initialised internal data is treated as valid and memory gets corrupted. On Apache with mod_php, an unauthenticated request can trigger it before your site's code even runs.
• CVE-2026-109619, stale internal state: a fatal error at the wrong point leaves internal structures pointing at freed memory. A later request handled by the same worker can reuse that state and, in the conditions the reporter demonstrated, execute code.

These bugs are not new: they have been in the PHP engine for many years. What changes today is that they are public.

Why the urgency is real

Several things make this release more pressing than a routine security update. The CVE identifiers leaked on 20 October, the day before publication, which forced the PHP team to bring the release forward. A research firm accidentally published a video of its proof of concept, which has since been copied and shared. And a container image containing the fix was published a few hours before the coordinated release, which lets anyone compare fixed and vulnerable code. In short, attackers have material to work with.

At the time of publication, neither the PHP team nor CISA (the US cybersecurity agency, which issued an alert the same day) had observed exploitation in the wild. That is reassuring for the next few hours, not the next few weeks: automated campaigns that scan the internet for unpatched servers usually follow this kind of announcement quickly.

Who is affected

According to the official announcement, every PHP installation that serves web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is rated highest on Apache with mod_php, where exploitation was demonstrated with default settings. PHP-FPM, the most common setup with Nginx, is also affected through paths that go through application code.

In practice, you are affected if you run any of these:

• A WordPress, WooCommerce, PrestaShop, Magento, Drupal or Joomla site.
• A Laravel, Symfony or CodeIgniter application, internal or public.
• An intranet, CRM or business tool written in PHP, even one reachable only from your offices.
• Shared hosting or a VPS with a cPanel or Plesk control panel.
• Third-party software that bundles PHP (some monitoring, ticketing or invoicing tools).

The versions that will not get a fix

PHP 8.1 and earlier (8.0, 7.4, 7.3 and older) are no longer maintained by the PHP project and receive no official fix. Minimal backports were made available for people who build PHP from source, and some Linux distributions and extended-support vendors ship the fix in their packages. For most sites, though, the answer is clear: move to a supported version. CISA goes further and recommends taking offline systems that cannot be patched. We cover the process in PHP 8.1, 8.0 or 7.4: how to upgrade.

What to do today

1. Inventory everything that runs PHP: sites, applications, internal tools, third-party software. Forgotten sites (an old blog, a landing page from 2019) are the most dangerous, because nobody watches them.
2. Identify the version of each installation: php -v on the command line, Site Health in WordPress, or the PHP manager in your hosting panel.
3. Update to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, starting with internet-facing sites. The guide how to update PHP on your server covers each hosting type.
4. Restart PHP-FPM or Apache after the update, then any long-running PHP processes (queue workers, daemons), which otherwise keep the old version in memory.
5. Verify that the version served is the fixed one. Note that some Linux distributions apply the fix without changing the version number; in that case the package changelog is the reference.
6. If you cannot update right away, apply the temporary measures below and schedule the update for today.

Temporary measures if the update has to wait

The PHP team is explicit: only the update is a complete fix. The following settings reduce exposure to specific attack paths without making the installation safe.

• `session.upload_progress.enabled = 0`, in php.ini or the FPM pool configuration, then restart every worker. This blocks the confirmed paths for CVE-2026-109619, not other variants. Do not rely on ini_set() or a .user.ini file.
• `memory_limit = -1` set at server level (php_admin_value), combined with a low post_max_size (8 MB without file uploads, 32 MB with) and a memory limit at the container or cgroup level. This narrows CVE-2026-109618 without closing it. Do not use RLIMIT_AS or RLIMIT_DATA, which cause exactly the allocation failure that is vulnerable.
• On PHP 8.5 only, fatal_error_backtraces = 0 blocks the confirmed path through fatal error backtraces.
• A web application firewall (WAF) can filter some known malicious requests. It is a layer, not a fix.

Hiding errors with error_reporting, display_errors or the @ operator does not help. On shared or managed hosting, do not change these settings yourself: ask your host whether they have applied the 21 October release.

What the PHP Foundation is doing

In its post of 21 October, the PHP Foundation explains how it is strengthening the language's security: an ecosystem security team created in May 2026, new hires for report handling and engine hardening, external audits under way (after the Quarkslab audit of 2024), automated analysis and research programmes funded by industry players. Since 1 July the team has published 15 CVEs and triaged more than a hundred invalid or duplicate reports. The Foundation is asking companies that build on PHP, hosting providers and cloud platforms to fund this work on a sustained basis.

For site owners, the conclusion is simple: PHP's security is improving, and the pace of security releases will probably stay high. A site without an update process falls further behind with every announcement.

How we handle this alert for our clients

For sites and applications under our managed services, the inventory already exists, versions are known and PHP updates go through a staging environment before production. An alert like this one is handled within the day, with every site checked afterwards. If nobody is looking after your site and you do not know which PHP version it runs, get in touch: we check and update exposed sites first.