Est. 2019
Est. 2019
Last Updated:
October 23, 2026
Parth Gaurav
Founder & CEO
.webp)
It is not exposed if it runs on Webflow, which has no PHP server for anyone to patch.
The rest is what it means for your marketing calendar this week, and what it says about the platform you're betting your pipeline on.
PHP2Shell is the name security researchers gave to two critical vulnerabilities in the PHP interpreter itself, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. Both allow an unauthenticated attacker to execute code remotely on a server running a vulnerable PHP version, with the privileges of the web worker handling the request. That's the worst-case category for any vulnerability: no login required, no social engineering, just a request to a server running the wrong PHP version.
The two flaws sit in different parts of PHP's request handling. CVE-2026-109618 involves memory corruption during out-of-memory handling, and CVE-2026-109619 involves stale request-specific state getting used after the underlying memory has already been freed. Rapid7's October 2026 writeup on the vulnerabilities names PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed as affected ways PHP serves requests, which tells you this isn't a quirk of one hosting setup. It's a flaw in the interpreter that sits underneath whatever CMS or framework your site is built on.
The PHP project shipped emergency patches on October 21, 2026: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. If your stack is on PHP 8.1 or older, there is no official fix coming. Security bodies pushed organizations hard enough that a lot of sites went into maintenance mode that same day rather than stay live and unpatched.
Run this check before anything else, because the CMS name on your login screen isn't the thing that matters. The question is whether PHP is executing requests anywhere behind your site.
You're exposed, and need to confirm a patch, if your site runs:
You're not exposed to PHP2Shell as a customer-side vulnerability if your site runs:
Here's the part that trips teams up. Updating WordPress core to the latest version, or updating every plugin, does nothing for PHP2Shell. The vulnerability is one layer below the CMS, in the interpreter that executes the PHP code, not in the PHP code itself. We've had this exact conversation with marketing leads who assumed "we're fully updated" meant they were covered, and the honest answer was: updated to what? The CMS, sure. The PHP runtime underneath it, nobody had checked.
A Webflow marketing site doesn't hand the customer a PHP runtime, a PHP-FPM process, or any server for the marketing team to maintain. The site runs on Webflow's hosted infrastructure, not on a PHP application server your team owns and keeps current. There's no PHP installation in the project to patch, because there's no PHP installation in the project.
That's a structural fact about the architecture, not a security feature Webflow bolted on in response to this specific CVE. Hosted platforms like Webflow, Framer, Squarespace, and Wix were never exposed to PHP2Shell for the same reason none of them were exposed to the last major PHP CVE, or the one before that: there's no PHP server on the customer's side of the line.
This doesn't mean a Webflow site has zero security surface. Account access, SSO and team permissions, third-party scripts, form endpoints, and integrations into HubSpot or Salesforce all still need attention, and those systems carry their own security responsibilities regardless of what platform renders your homepage. What disappears is one specific, recurring category of emergency: the "patch the PHP runtime across every environment before the exploit gets weaponized" fire drill.
The pattern behind PHP2Shell isn't new, and it's not really about PHP being badly written. It's about where the patching obligation lands. When a critical PHP CVE drops, the fix chain runs through the hosting provider, the operating system package, the PHP runtime version, and the CMS application, four layers, and a two-to-six-person marketing team usually only has visibility into one of them: the CMS dashboard.
In our work migrating marketing teams off WordPress, this is the conversation that comes up almost every time something like this happens: the team that owns the pipeline number doesn't own the server, doesn't own the hosting contract, and often doesn't know which PHP branch they're on until someone asks. That's not a failure of diligence. It's what happens when a platform's architecture assigns a systems-administration job to people hired to run campaigns.
A VP of Marketing carries a number tied to leads and demos. They were never going to be the person who tracks PHP's release branches, and most hosting plans don't make that tracking easy either. Telling organizations to take unpatched sites offline is the right call from a security standpoint, but it's also a signal that the responsibility for knowing and acting on a PHP CVE within hours was sitting with people who had no practical way to carry it.
Most comparisons between WordPress and Webflow get argued on editing experience, plugin ecosystems, or design flexibility. PHP2Shell reframes the comparison around a different question: which responsibilities does your team want to own, and which do you want a platform provider to own on your behalf?
A PHP-based CMS can be the right call when you need deep customization, a specific plugin ecosystem, or infrastructure control nothing else offers, but that choice comes bundled with an operating model you have to actually staff: runtime patching, dependency updates, vulnerability monitoring, backups, access control, and incident response. If nobody on your team signed up to own that model, the risk doesn't go away. It just sits there until a day like October 21, 2026 makes it visible.
A hosted platform trades some of that infrastructure control for removing the patching obligation entirely from your side of the relationship. Neither option is automatically safer in the abstract. The difference PHP2Shell exposes is whether the responsibility was ever explicit, staffed, and tested, or whether it was quietly inherited by a marketing team that bought a website as a project and got handed a server to maintain along with it.
If your site runs on PHP, your first move isn't a redesign conversation. Get the exact PHP version from whoever owns hosting, confirm the PHP2Shell patch or an equivalent vendor backport has been applied, ask whether the server was checked for signs of compromise before the patch went in, and inventory any other PHP services, staging environments, or legacy domains sitting on the same account. If "the host handles it" is the only answer anyone can give you, that's worth writing down, because it's the same answer that will show up at the next critical PHP CVE.
If you've already concluded you'd rather not own this category of risk going forward, a WordPress to Webflow migration is the direct path off it, and it's work we've done 14-plus times, with 30-plus platform migrations overall preserving the rankings and pages those sites had already earned. We also recently walked through the rest of the diligence question in our look at whether Webflow is a safe bet for a B2B startup's website, which covers the broader security and reliability picture beyond this one CVE.
PHP2Shell didn't touch Webflow sites because Webflow customers never had a PHP server in the first place, which is the whole point: the safest response to a critical infrastructure vulnerability is not owning the infrastructure it lives in. Once you see the patching obligation as something that was quietly assigned to your marketing team rather than something you chose, every future "critical PHP vulnerability patched" headline reads differently. If you're ready to find out what moving off PHP actually involves for your specific setup, book a discovery call and we'll walk through what a migration would look like for your site.
No. Updating WordPress core or plugins addresses WordPress's own code, not the PHP interpreter underneath it. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) is a vulnerability in PHP itself, patched in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Your host or engineering team needs to confirm the PHP runtime version separately from any CMS update.
No. Webflow sites don't run a customer-managed PHP server, so there's no PHP installation for PHP2Shell to exploit on the customer's side. Other hosted platforms without a customer-facing PHP runtime, like Framer, Squarespace, and Wix, were never exposed for the same structural reason.
PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, released October 21, 2026, patch both CVE-2026-109618 and CVE-2026-109619. PHP 8.1 and older branches do not receive an official fix, so sites on those versions need to upgrade the PHP branch itself, not just apply a point patch.
Yes, the CMS name doesn't change the exposure. Magento, Drupal, and Joomla all run on PHP, so if the underlying server uses an affected PHP version and serving method (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, or LiteSpeed), the site needs the same runtime-level patch as a WordPress or custom PHP site.
PHP2Shell alone isn't a reason to migrate, it's a reason to find out who owns your next critical patch. If this is the second or third time your team has scrambled over a PHP CVE with no clear owner, that's a signal about the platform's operating model, not just this one vulnerability, and worth weighing against what a WordPress to Webflow migration actually involves.
Last Updated:
October 23, 2026
