Major security alert: PHP vulnerable to critical RCE, attacks ongoing

PHP has released the fix. Update now.

PHP has released security updates for two critical vulnerabilities that can allow unauthenticated remote code execution. All PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers the risk highest for mod_php, where an unauthenticated request can trigger the attack before any application code runs. Sites built on WordPress, Drupal, Magento, Joomla, Laravel and other PHP applications are exposed if they run a vulnerable PHP version.

PHP updates are out

Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

• PHP security advisory
• PHP downloads
• Advisories: CVE-2026-109618 and CVE-2026-109619

Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages. If you rely on the volunteer-maintained rpms.remirepo.net, PHP says it will not have updates today and urges switching to distribution packages or building from source.

PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, so contact your vendor or upgrade to a supported version. For people building from source, PHP’s security team also provided minimal backports for PHP 7.4, PHP 8.0 and PHP 8.1.

Live timeline

• 13:57 UTC – Shortly after PHP’s update, our telemetry shows only probing attacks, with no hard evidence of breaches yet. This is expected to change as details of the security update go public. Updating is absolutely necessary.
• 13:52 UTC – PHP releases PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing both vulnerabilities.
• Earlier on 21 October – As a precaution, services including Dutch government sites DigiD and MijnOverheid, The SEO Framework and major Japanese platforms go offline until the patch is released.
• 07:43 UTC – Cloudflare’s CTO says Cloudflare is seeing early attacks and has deployed initial WAF rules for known exploit vectors.
• 07:34 UTC – Multiple active exploitation incidents reported to Patchstack by hosting partners.
• 20 October – Details leak ahead of coordinated disclosure. The PHP security team announces the 21 October release.

What we know

• The two flaws are tracked as CVE-2026-109618 and CVE-2026-109619. The PHP security team rates both Critical (CVSS v4.0 9.2).
• CVE-2026-109618: Out-of-memory handling can interrupt PHP while internal request data is only partially initialised. Request cleanup may then treat the invalid data as valid.
• CVE-2026-109619: Request-owned internal state can survive after its memory has been freed. A later request handled by the same worker may use that stale state before normal initialisation resets it.
• The flaws are in the PHP interpreter, not in any one application, so any site on a vulnerable PHP version is exposed.
• Wiz Research, which reported the bugs to PHP, says every PHP version back to 5.4 is affected by at least one of the issues. It demonstrated unauthenticated remote code execution against the latest WordPress, Drupal and Joomla container images, and says even a simple “Hello World” app on a vulnerable PHP version can be exploited. It also demonstrated reading PHP worker memory, which can contain passwords, tokens and API keys, without achieving code execution. Wiz says PHP’s patch fixes the underlying problem, including other variants.
• Details leaked on 20 October, before the coordinated disclosure, and the issue was called “PHP2Shell”. Security firm watchTowr had confirmed the flaws were real before the release.
• Several organisations took services offline as a precaution until the patch was out:
  • Dutch broadcaster NOS reports that DigiD, MijnOverheid, the Dutch House of Representatives’ website, Tweakers and the Dutch National Cyber Security Centre’s own site were among those offline.
  • Japanese outlet ITmedia reports emergency maintenance at several major services, including Kodmon, Shadowverse: Worlds Beyond and Sakura Rental Server, believed to be linked to this vulnerability. It adds that others, including BASE and Xserver, were expected to follow.
  • The developers of The SEO Framework said they took their servers offline.
• Cloudflare says PHP sites behind it have an initial set of WAF rules for the known exploit vectors, available to all customers, including free. It describes this as a stopgap only. The rules only help if your server accepts traffic exclusively from Cloudflare.
• CERT-EU has issued an advisory, and the UK’s National Cyber Security Centre has issued an alert urging organisations to update immediately.

How to protect your websites

1. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to your vendor’s patched package.
2. Find every PHP install you run (servers, containers, staging sites, and appliances or third-party software that bundle PHP) so you know what needs updating.
3. If you run PHP 8.1 or older, contact your vendor for a backported fix or upgrade to a supported version.
4. Avoid unofficial “fix” plugins and copy-pasted snippets. They are not verified and can break your site.
5. If you can’t update right away and your site is high-risk, consider taking it offline or into maintenance mode until you can. The UK’s NCSC gives similar advice.

If you can’t update immediately

Only an update is a complete fix. PHP lists the following measures, which reduce exposure to specific attack paths but do not make an installation safe. The advisories above have the full details.

For CVE-2026-109618 (out-of-memory corruption):

• Set memory_limit=-1 in a way applications can’t override, such as php_admin_value in the FPM pool or Apache configuration. Check that no pool, directory or application setting puts a finite limit back. An underlying allocation failure can still reach the vulnerable path.
• Set a low post_max_size: 8M if you don’t need file uploads, 32M if you do. Keep upload_max_filesize below it. Consider also enforcing limits on request size, field count and multipart part count at the web server or proxy.
• Use a container or cgroup limit as an availability boundary, preferably one that kills only the affected worker. Don’t use RLIMIT_AS or RLIMIT_DATA, as these can cause the vulnerable allocation failure.

For CVE-2026-109619 (stale global state):

• Set session.upload_progress.enabled=0 and restart every worker. Use php.ini, an FPM pool or server configuration, not ini_set() or .user.ini. This blocks the confirmed session paths but not other variants.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks only the confirmed fatal-backtrace path.
• Remove invalid or deprecated settings applied per request that emit diagnostics before initialisation. Hiding diagnostics with error_reporting, display_errors or @ does not help.
• Fix attacker-reachable fatal errors and execution timeouts.

Signs your server may have been targeted

The flaws act below the application layer, so application logs may show little. Wiz Research suggests watching for:

• Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses.
• Unexpectedly large or malformed PHPSESSID cookies in responses.
• Unexplained PHP worker restarts.

These signs can guide an investigation but are not proof either way. If you see them, you still need to update. Also treat the server as potentially compromised, and consider rotating credentials it holds, because the flaws can also expose memory contents.

Further reading

• PHP Foundation: today’s security release
• Wiz Research write-up
• Cloudflare: WAF protection for the PHP vulnerabilities