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

Attacks are already under way: Patchstack has received reports of active exploitation from multiple hosting partners, and Cloudflare says it is seeing early attacks too.

Two critical vulnerabilities in PHP itself could let attackers run their own code on affected servers. Sites built on WordPress, Drupal, Magento, Joomla, Laravel and other PHP applications are exposed if they run a vulnerable PHP version.

The only confirmed fix is updating PHP. The PHP security team has scheduled an emergency release for 21 October 2026, 14:00 UTC.

Live timeline

• Later on 21 October – Several services, including The SEO Framework and major Japanese platforms, take servers 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). Some early reports said 10.0, but 9.2 is the official rating.
• The flaws are in the PHP interpreter, not in any one application, so any site on a vulnerable PHP version is exposed.
• Details leaked on 20 October, before the coordinated disclosure, and the issue is being called “PHP2Shell”. Security firm watchTowr confirmed the vulnerabilities are real and reproduced one of them. They are reported to allow remote code execution.
• Some companies are taking services offline as a precaution until the patch is out. The developers of The SEO Framework said they took their servers offline, and 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, are expected to follow.
• Cloudflare says PHP sites behind it already have an initial set of WAF rules for the known exploit vectors, available to all customers, including free. Cloudflare’s CTO says it is seeing early attacks emerging and is updating mitigations as new vectors show up. He describes this as a stopgap only. The rules only help if your server accepts traffic exclusively from Cloudflare.
• Affected and fixed versions will be published with the release. Older, end-of-life PHP branches may not receive patches. This is unconfirmed until the release.
• A PHP core developer has said that patching or upgrading PHP is the only mitigation.
• CERT-EU has issued an advisory: https://cert.europa.eu/publications/security-advisories/2026-018/

How to protect your websites

1. Update PHP as soon as the patched versions are out at 14:00 UTC. If you’re on managed hosting, ask your host when they will apply it.
2. Find every PHP install you run (servers, containers, staging sites) so you know what needs updating.
3. If you run an end-of-life PHP version, ask your host about upgrade options now.
4. Avoid unofficial “fix” plugins and copy-pasted snippets. They are not verified and can break your site.
5. If your site is high-risk and you can’t patch right away, consider putting it into maintenance mode or temporarily offline until the update is available.

Partial mitigations (not a fix)

Early analysis points to PHP’s session upload progress feature and to multipart file-upload requests. Some researchers suggest the following until you can patch.

Turn off session upload progress. This feature is on by default:

session.upload_progress.enabled = Off

Apply it in php.ini, .user.ini or your host’s PHP settings, then reload PHP. Upload progress bars will stop working, but uploads themselves still go through.

Block multipart requests where you don’t need them. If you have a WAF or reverse proxy, reject or inspect multipart POST requests to endpoints that don’t accept file uploads. Match loosely on “multipart” in the Content-Type header, case-insensitively, rather than on the exact string multipart/form-data, because attackers can vary the exact formatting. Test first, since this will break legitimate uploads (media libraries, contact forms with attachments, checkout and account pages) wherever you apply it too widely.

These are only partial mitigations and do not stop exploitation. PHP core developers have said the only way to fully mitigate the issue is to update to the new PHP version that patches the vulnerability. Treat these as stopgaps, not a substitute for updating.