The PHP2Shell Headline Is a Platform Question

Every plugin on your WordPress site is code a stranger wrote, maintains on their own schedule, and can walk away from whenever they like. Edgar Allan's view on this is that this makes platform choice a security decision. The more third-party code your website runs, the more doors your team has to watch, and AI has made it very cheap for someone else to try them all.

If you lead digital marketing at a company running WordPress, you probably got some version of this message from IT last week: are we exposed? 

The trigger was PHP2Shell, a pair of critical flaws in PHP itself (CVE-2026-109618 and CVE-2026-109619) whose details leaked online on October 20, the day before PHP shipped emergency fixes. Both allow remote code execution without logging in, which sits near the top of the list of things you never want a stranger doing to your server. As Jared Malan, Technical Director at Edgar Allan and founder of answer.cloud, put it in our latest Building the Next Web episode: "If you can run code without having to log into that server, you can pretty much do anything."

When Jared, Witt Langstaff, and I sat down to talk about it, none of us knew of a single system compromised through the flaw. That changed within days. watchTowr has since reported exploitation of both vulnerabilities in the wild, and public proof-of-concept code is circulating on GitHub. A theoretical problem became a working one in under a week.

PHP2Shell lives in PHP's core, so your plugin count itself didn’t decide whether you were exposed, and every PHP server needed the patch, including the PHP application our own team dropped everything to fix that week. The episode revealed how fast this can all happen: a flaw can go from footnote to working exploit in days. On a plugin-heavy site, that scary swiftness applies to every plugin you run - each one needs someone keeping watch.

AI Finishes the Homework People Left Half Done

Old flaws used to be safe-ish through obscurity. Finding one took a skilled person, a lot of time, and a reason to bother looking, so plenty of weak spots sat for years in footnotes, forum threads, and research nobody followed up on. Jared described what changed: "you probably have all of these breadcrumbs right up to the vulnerability that the AI can just finish the work that humans had a hard time understanding."

Agents never get bored and never need a reason to do anything. They can read every changelog, every abandoned GitHub issue, and every plugin's source code, then test what they find against every site running that code so very quickly. For a marketing site, the practical meaning is pretty stark: any code you run that nobody has examined closely in a while is now being examined closely by someone or something, and you'd much rather that entity be you.

Door count is Edgar Allan's name for the number of third-party codebases a website runs that your team has to watch, patch, and eventually retire. On WordPress, every plugin adds one, and the lower the number, the less your security depends on strangers keeping their promises.

It's Time to Count Your Doors

Before anyone debates platforms, you’ll want to find out your door count. A plugin inventory is the audit every Edgar Allan migration starts with (our enterprise WordPress to Webflow migration checklist opens with a full site census of third-party tools, integrations, and security dependencies), and it earns the time spent even if you never swap platforms. 

List every active plugin with these four details:

Expect a few surprises, including the pure scale of what’s under the hood of your site. In a 2026 study of 5,000 WooCommerce stores, each had a range of 30-58 active plugins. This is the kind of exercise that turns up the slider plugin from a 2019 campaign that's still switched on, or the form plugin whose developer stopped answering support tickets two years ago. Each one is a door, and the inventory tells you which ones nobody has checked in a long time. It’ll take a couple hours to a day (or with AI assistance, even less), and it’s so worth it.

Faster Patching Buys Time Without Shrinking the Surface

The standard advice after a vulnerability headline is to patch faster, and you should definitely do that. Patching, though, is also a job with no finish line. Someone has to watch advisories for every plugin, test each update against all the others (plugins have a way of disagreeing with each other at the worst possible moment), and ship fixes quickly enough to stay ahead of automated scanners. That someone rarely sits in marketing's budget, even though marketing owns the site.

Witt Langstaff, Edgar Allan's Solutions Architect and AI/Tech Lead, was careful about this on the livestream. WordPress is "a plug-in ecosystem," he said, and "each one of those is a potential vulnerability," though he added right away that not all of them are. That's the right way to see it. Your team is responsible for every plugin, every day, including the ones that are fine most of the time. It’s just that AI-driven scanning has made "most of the time" a much thinner comfort layer than it used to be.

Before your next planning cycle, measure your own number: the hours per month your team or vendor spends watching advisories, testing updates, and shipping patches. That figure is the running cost of keeping things the way they are, and it's worth putting next to the cost of a migration when you make the case to your CIO.

A Managed Platform Handles the Patching So Your Team Can Guard the Keys

Moving to a managed platform like Webflow shrinks the surface instead of forcing you to guard a large one (which is, obviously, harder). There's no plugin layer to maintain, and Webflow handles patches and vulnerabilities at the platform level, which we lay out in our comparison of Webflow and AI-native development. As Witt put it, with Webflow "you don't have all this external code that you have to add in."

A managed platform still leaves real security work for your team to do: admin access and permissions, SSO, the integrations that connect your site to your CRM and analytics, and the forms that collect customer data. No platform is unhackable, and as always, part of the job after a migration is knowing exactly who has the keys and making sure former employees and old agencies no longer do.

For enterprises with stricter requirements, like private servers, data residency, or authentication tied to an internal identity provider, Webflow Custom Hosting covers the gap. NCR Atleos used it to connect Webflow with Microsoft Azure for deployment compliance, and Accel used it for server-side authentication with Okta. We walk through both in our enterprise Webflow agency checklist. 

Oh, and while you're vetting partners, ask the agency for its own SOC 2 report too: Edgar Allan is one of the SOC 2-compliant agencies in the Webflow ecosystem, and that compliance sits separately from the platform's own.

Plan Your Move While the Seas Are Calm

Here’s what I’d recommend: put the platform decision on next year's roadmap, and resist the urge to migrate this month. A rushed migration that breaks redirects and tanks organic traffic is its own crash, only in slower motion. The teams that come through these moments well are going to be the ones that planned the trip before the weather turned, as it were.

For reference, here’s how the phases of an enterprise WordPress to Webflow migration should break down, from our guide on how long a WordPress to Webflow migration really takes:

Note that SEO continuity deserves its own line in the plan, with every existing URL mapped, metadata carried across and rankings watched after launch. If you're comparing partners, our guide to what to look for in a WordPress to Webflow migration agency covers the questions worth asking before you sign anything.

Migrating enterprise sites off WordPress is the most common project the Edgar Allan team runs, and every one starts with the plugin inventory above. If you've worked out your door count and you don't love the number, let's start a project.

Every plugin is a door. Decide how many you want to guard.