PHP2Shell explained: what happened, which platforms were hit, and what to do now

We update this page as new facts are confirmed; see the update log near the end.

On October 21, our founder and CEO, Uroš Mikić, got 10 or more messages from clients asking the same two things: are we safe, and are Webflow sites affected?

PHP2Shell is the name for two critical PHP vulnerabilities in the language itself, CVE-2026-109618 and CVE-2026-109619, rated 9.2, that can let an attacker run code on a web server without logging in. PHP fixed them on October 21, 2026, in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Every site on an unpatched PHP version was exposed, whatever CMS runs on top, and the fix is a PHP update applied by whoever runs the server.

What happened with PHP2Shell

PHP announced a critical fix about 18 hours before it shipped. The vulnerability IDs had leaked hours earlier, and Amazon saw an exploitation attempt four days before disclosure. Attempts are confirmed; whether anyone was actually breached is still unclear.

PHP2Shell in plain words

PHP is the programming language running on the server behind WordPress, Drupal, Joomla, Magento and countless custom sites. W3Techs finds it on 69.3% of websites whose server-side language it can detect (October 22, 2026).

PHP2Shell lets one crafted web request corrupt PHP's memory and run the attacker's code with the permissions of the server's PHP process. PHP's advisory says the attack can trigger "before any application code runs", so the CMS on top makes no difference.

The second PHP vulnerability can also disclose worker memory, and code running on your server can reach its files, database and stored credentials. Affected releases date back to PHP 5.4.

Your exposure comes down to the PHP version on your server and who updates it.

How the disclosure unfolded

The PHP Foundation's own account starts in 2024, when a core developer it contracted found the first signs of the out-of-memory problem during an external audit funded by the Sovereign Tech Agency. No exploit path was known, the fix stalled for months, and the Foundation now calls the delay "a structural failure."

Cloudflare had protections live "about 9 hours ahead of public disclosure", Free plans included. Amazon's sensors logged the first attempt on October 17, and hosting partners reported active incidents to Patchstack on release morning.

Whether any of that turned into break-ins is less clear. PHP's security team "did not identify any functional exploits at the time of release/public disclosure." Patchstack's telemetry at 13:57 UTC showed "only probing attacks, with no hard evidence of breaches yet."

As of October 21, "No successful break-ins had been confirmed," per Insurance Business. Sansec's October 22 update adds that "Mass exploitation of PHP2Shell is less likely than we expected on release day."

Uroš put it bluntly: "No one knows who was actually affected, and if someone tells you, they are probably lying. We will probably see the effects of this breach in the following weeks."

Why governments and companies took sites offline

On October 21, the agencies told anyone who couldn't patch to switch systems off. CISA said organizations that "cannot update immediately, or that continue to use PHP 8.1 or earlier unsupported versions, should take PHP-based systems offline until they can be patched or updated."

The FBI gave the same advice, and the UK's NCSC told organizations to "consider taking the system offline" if they couldn't fix it straight away, as Computer Weekly reported.

Plenty did. Computer Weekly's tally includes:

• Finland's government IT agency, Valtori, "as a precautionary measure"
• The Dutch NCSC's own site, Overheid.nl and the Port of Rotterdam
• France's Interior Ministry, which put its sites into preventive maintenance
• Denmark's Kombit, including the national school communication platform
• Edinburgh Council, several BBC program pages and some Wikimedia systems

"So did the whole internet go down? Not really," as Uroš wrote. Cloudflare's rules and early host patches gave the sites on those services a head start.

Which platforms were affected beyond WordPress

Every platform that runs PHP on a server was in scope, because the flaw sits in PHP and fires before the CMS loads. Wiz Research demonstrated code execution before login against default WordPress, Drupal and Joomla installs, and it says every PHP version released in the last decade is affected by at least one of the flaws.

Uroš summed it up: "To get one thing straight: this is not WordPress only or a plugin. This is in the core PHP as a language."

WordPress and WooCommerce

WordPress's security team didn't hedge. Its October 21 notice says the flaws "are not specific to WordPress and affect any server that hosts a PHP application", and "No WordPress update is required or planned for these issues."

Your PHP version sits under Tools > Site Health > Info > Server. On self-managed servers below PHP 8.2, WordPress.org says to consider taking the server offline while you upgrade.

Managed hosts carried most of the load, per The Repository's roundup:

• Automattic: WordPress.com, VIP and Pressable sites were already protected.
• SiteGround: server-level mitigations went out hours before the release.
• WP Engine: mitigations at the CDN layer, with patching finished at 01:19 UTC on October 22.
• GoDaddy: Managed WordPress fully patched, Web Hosting still on mitigations at its last update.

The Repository counts WP Engine, Pressable and Patchstack among its sponsors. WooCommerce stores follow the same rule, and our rundown of WordPress security issues covers who patches what more broadly.

Drupal

Drupal was the first platform where Wiz confirmed unauthenticated code execution, on August 20. Drupal's PSA leaves no room for doubt: "Updating to a PHP release containing the patch to these vulnerabilities is the only complete mitigation."

If you manage PHP yourself, you apply the update, and "If your host manages it, follow their communications for timing and any required action." Keeping PHP current is part of what Drupal costs to run, as our Drupal vs Webflow comparison notes.

Joomla

Wiz also showed code execution before login against the default Joomla image. We found no Joomla project advisory as of October 22, and the fix is the same as everywhere else, a PHP update from your host or server owner.

On shared hosting, get two things in writing: the PHP version your site runs and the date it was patched.

Magento and Adobe Commerce

Sansec, an ecommerce security firm, reports that Calif showed an attacker without a login can run code on Magento 2.4.9, and it warns that "you cannot fix PHP2Shell from within your store code."

Taking a checkout offline stops revenue by the hour, so Sansec's October 22 advice matters: "You do not need to take your store offline. Update PHP anyway." Until then, it suggests blocking multipart/form-data requests at the web server and placing a test order afterward, since "Some stores submit cart or checkout forms as multipart."

We found no Adobe bulletin for PHP2Shell as of October 22, so Adobe Commerce cloud merchants should ask Adobe support to confirm their PHP build.

Other PHP apps around your website

PHP also runs much of the software around a website, from webmail and file sharing to billing portals and wikis. Calif's list, as reported by Sansec, includes MediaWiki 1.46.2, Roundcube 1.7.4, phpMyAdmin 5.2.3, Nextcloud 35.0.1, Laravel 13.11, Symfony 8.1 and WHMCS.

Laravel and Symfony power custom-built apps, so a custom PHP app is in scope with no CMS involved. CISA puts the hidden part well: "PHP is often a component of other software and prevalence may not be directly observable."

Ask IT for a list of every system running PHP, and patch the internet-facing ones first.

Managed hosts and control panels

Your hosting model decided day one. When a host runs PHP for you, it carries the patching job, and when your team runs the server, your team does.

Plesk, a hosting control panel, rebuilt the PHP packages it ships, and its notes show three very different situations:

• PHP 8.2 to 8.5: fixed in 8.2.35, 8.3.36, 8.4.27 and 8.5.12
• PHP 7.4, 8.0 and 8.1: fixed only in builds dated October 21, 2026, so the version number proves nothing
• PHP 5.6, 7.2 and 7.3: no fix listed, with paid extended support as the suggested route

The long tail is big. W3Techs counts 26.9% of PHP sites on PHP 7 and 7.7% on PHP 5, versions the PHP project no longer patches.

PHP gave Linux distributions and LTS vendors the patches in advance, which helps explain why some hosts patched within hours while others waited. Owning that job after launch is part of what WebOps is.

Platforms that don't run on PHP

Hosted platforms whose core services don't run on PHP had nothing for customers to patch. Webflow's Trust Center statement says "Webflow's core services are not built on PHP and are not affected." It adds that its team is assessing "non-production related systems that use PHP", and that "No action is required from customers."

Sanity works differently. Content lives in Sanity's hosted Content Lake, and the front end is a separate app, usually built in Next.js or Astro, as our guide to what Sanity is explains.

Exposure on a Sanity build depends on what that front end runs on, and we found no Sanity statement on PHP2Shell as of October 22. That split is the idea behind headless vs traditional CMS setups.

Moving off PHP hands the patching job to a vendor or to whoever runs your front end. Every stack still has patch days.

What to do now if your site runs on PHP

Update PHP first and confirm it with whoever runs the server; nothing you change inside the CMS fixes the flaw.

Find your PHP version and who patches it

WordPress shows your PHP version in Site Health, hosting control panels list it under their PHP settings, and your host or agency can confirm it in writing. Distributions and Plesk backport fixes without changing the number, so ask for the build date or the changelog entry that names both CVEs.

Who patches depends on how you host:

• Hosted platforms: the vendor
• Managed hosting: the host
• Shared hosting: the host, on its own timeline
• Your own server or cloud: your team or agency

Questions to ask your host or agency today

Paste these into an email as they are:

1. Which PHP version and build is our site on, and when was it last updated?
2. If we run PHP 8.1 or older, where does our fix come from, and when do we move to a supported version? PHP 8.2's own security support ends on December 31, 2026.
3. Were all PHP workers restarted after the update?
4. Does our site sit behind a web application firewall (WAF), and does the server accept traffic only through it?
5. Have you checked our logs back to October 17 for signs of compromise?
6. Which of our other tools run PHP, such as webmail, file sharing or billing?

Question 4 matters because, as Patchstack notes, Cloudflare's rules "only help if your server accepts traffic exclusively from Cloudflare." A good answer to the list is a version, a date, and a yes to restarts and log checks.

If you can't patch today

CERT-EU's advisory says organizations that can't patch "should consider isolating internet-facing applications from public networks until a fix is applied and verified." A WAF alone is a stopgap, and Cloudflare tells its customers to patch "even with WAF protections."

By October 22, Sansec judged that the public exploits need specific server conditions, so for most sites a fast patch matters more than downtime.

If you do go offline, keep it short and serve a 503. Google's crawling documentation says "5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling" and that indexed URLs "are preserved in the index, but eventually dropped", with crawling recovering once pages return 2xx. A short, planned outage costs far less than a compromised server; post a status note elsewhere so customers know why.

Check for signs of compromise

Amazon's advice is to "Start investigations from the earliest known exploitation, not from the disclosure date", which means October 17, and to "measure patch and mitigation timelines in hours" for critical internet-facing flaws. Ask your host or developer to look for:

• Unusual upload requests followed by memory errors or bursts of HTTP 500 responses (Wiz)
• Unexpected processes or new files on the server (Amazon)
• PHP worker processes launching shells or downloading tools (CISA)

If anything looks wrong, isolate the server, keep the logs, rotate the passwords and API keys it holds, and report it; in the US, the FBI points organizations to a field office or IC3. Our guide for when your WordPress site was hacked covers recovery.

Is PHP2Shell a one-off?

Uroš asked the obvious question in his post: "In the AI age, who was able to find this?"

Several teams found it independently. Calif, OpenAI's Codex Security team and Wiz Research reported the flaws, and the disclosure site credits Google's Gemini team with working alongside PHP's security team on discovery, coordination and patch checks. Wiz says it used "Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol", and that "Frontier models were critical to making this process practical."

Anthropic's Claude Mythos is part of the story too. The PHP Foundation scanned PHP with Mythos through Alpha-Omega earlier in 2026, and its post doesn't say whether that scan surfaced these bugs. The first signs of the problem came from a human developer in 2024.

A pattern is forming. Three months earlier, wp2shell was a code execution chain before login in WordPress core itself, found with OpenAI's GPT 5.6 Sol and exploited in the wild.

In the same week as PHP2Shell, and unrelated to it:

• Node.js shipped fixes for 10 vulnerabilities, including a high-severity code execution bug.
• GitLab patched a CVSS 10.0 flaw in self-managed versions going back to 2014.
• Railway paused deployments after a security incident and told customers to revoke the environment variables stored with it.

Uroš believes this is just the start, and he has a warning for teams building fast with AI: "Don't trust that your data is safe by vibecoding a website or a platform if you don't have previous development experience. You can cause real damage to your organization."

We read it the same way. As AI shortens the time from bug to exploit, the question for a marketing team is who patches within hours, and that answer belongs in the website plan.

Should you move off PHP?

Not this week. Patch first, then decide who you want carrying the patching job, since every stack needs someone to carry it.

We build on Webflow and Sanity, so weigh our view with that in mind.

Stay where you are if your host or engineer patched within hours, if your build leans on plugins or WooCommerce, or if your site already runs PHP 8.3 or newer and someone clearly owns its updates.

Start planning a move if nobody owns the server behind your marketing site, if you're still on PHP 8.1 or older and face an upgrade project anyway, or if you took the site offline this week and lost leads.

If you move, we'd look at two non-PHP directions:

• Webflow suits marketing-led sites where you want the vendor to run hosting and patching. Its statement this week is quoted above, and its customers had nothing to do.
• Sanity suits teams that want structured content across channels and have developers to own the front end. The content backend is hosted, and the front end's updates stay with your team.

Neither one makes you unhackable. Account security, custom code and third-party scripts stay your job on both, and a headless front end has its own patch days, as the Node.js release the same week showed.

To compare options, start with Webflow vs WordPress, Sanity vs WordPress, our list of WordPress alternatives and our CMS migration guide. If you've already picked a direction, our migration guides for WordPress, Drupal and Joomla cover the move to Webflow, and our Sanity team covers headless builds.

If this week has you rethinking the site, start with what a rebuild should fix beyond the stack. Our free AI website audit scores your site across 10 strategy dimensions in under two minutes, and if you want a second opinion on Webflow, Sanity or staying put, we're happy to talk it through.

Update log

• October 22, 2026, 17:50 CEST: first published.

PHP2Shell FAQ