The enterprise risks of open-source CMS platforms

It's a permanent, compounding maintenance obligation that someone on your team owns, whether they know it or not.

That's the real question for a fintech, healthtech, cybersecurity, or govtech company running a security review on its marketing website. Not "has WordPress been breached," but "who, specifically, owns every layer of this stack, forever." If nobody can answer that cleanly, the platform decision isn't finished, no matter how good the last design review looked.

Why is open-source CMS risk ongoing instead of a one-time fix?

The risk isn't that your CMS will get breached tomorrow. It's that security becomes a recurring operational line item: tracking vulnerabilities, testing patches, auditing plugins, managing hosting, and producing evidence that all of it happened on schedule.

Patchstack's "State of WordPress Security" report found 11,334 new vulnerabilities disclosed across the WordPress ecosystem in 2025, a 42% increase year-over-year, with 91% of them in plugins rather than WordPress core itself. That's not one incident to remediate. That's a volume of new disclosures your team, or your agency, or whoever still has admin access from two redesigns ago, has to triage every single week. The number went up 42% in a year, and there's no reason to expect it flattens out next year.

This is the frame we bring into every conversation about platform choice, whether we're running a Webflow build for a SaaS marketing team or migrating a company off WordPress entirely. The platform decision isn't "which CMS has better features." It's "whose job is it to carry this workload indefinitely, and can that person actually do it." For a small marketing team under pipeline pressure, the honest answer is usually no one, which is exactly the gap a managed, closed platform like Webflow is built to close.

Why does CMS risk extend beyond the CMS itself?

An open-source deployment is never one product. It's the CMS core, a theme, plugins, the PHP or JavaScript runtime, the database, the hosting server, and every form, CRM, and analytics integration bolted on top. Each one is a separate place a vulnerability, misconfiguration, or stale dependency can live.

Saying "we run WordPress" doesn't describe your security posture any more than saying "we have a car" describes whether the brakes work. The question your security team actually needs answered is who owns patching for each layer, and how fast the organization can detect and fix a problem when one shows up in any of them. Most marketing-owned WordPress sites can't answer that past the CMS core itself.

PHP2Shell shows what platform-level risk actually looks like

PHP2Shell is a live example of why architecture, not just patching discipline, determines how big your incident response has to be. What matters here is the pattern it exposes.

A company running an open-source CMS on PHP had to go check the PHP runtime version, the CMS version, every plugin and theme, the hosting configuration, server-side libraries, custom code, and connected environments, then look for indicators of compromise across all of it. That's not a patch. That's an audit. Webflow's security trust center states its core services aren't built on PHP and weren't affected by the PHP2Shell vulnerabilities it was tracking, and that it assessed its own non-production PHP-based systems and addressed what it found. The lesson isn't that every PHP site got owned. It's that the size of your response is a function of your architecture, decided long before the vulnerability existed.

Plugins turn your CMS into a supply-chain problem

The extensibility that makes open-source platforms appealing is the same thing that fills production with third-party code nobody on your team wrote or fully understands. Plugins introduce vulnerabilities patched later than the core, abandoned packages with no maintainer, excessive admin permissions, and dependencies that are genuinely hard to inventory. Patchstack's 91%-in-plugins figure isn't a coincidence, it's the direct result of this dynamic at ecosystem scale.

The useful question for an enterprise buyer isn't "does this CMS support plugins." It's whether your organization can maintain an accurate, current list of what's installed, who maintains each piece, and how fast any of it can be pulled or patched. Companies migrating off WordPress after years of accumulated customizations often can't answer that, which is part of why our WordPress-to-Webflow migration work treats the audit of what's actually running as step one, not an afterthought.

What changes when a managed platform owns the infrastructure

A closed, managed platform shifts the weight of infrastructure security to the provider instead of your marketing team or whichever agency last touched the site. Webflow maintains SOC 2 Type II compliance and ISO 27001 certification, and runs a formal vulnerability-disclosure program, backed by Enterprise-tier controls like SSO, SCIM and just-in-time provisioning, audit-log API access, and managed hosting and SSL.

None of that makes a site risk-free. But it gives your security team something concrete to point to in a review instead of a patchwork of plugin changelogs and an agency's word that updates happened. We walk through this tradeoff in more depth on why Webflow fits B2B marketing teams, including where Webflow's compliance posture genuinely helps and where it doesn't, like the fact that Webflow isn't built to store regulated patient data, so health-information forms still need to route to a compliant tool regardless of platform.

Choose open source if, skip it if

Open-source CMS platforms are a reasonable choice for some companies. They're the wrong default for others. The decision comes down to who's actually staffed to run the ongoing security workload, not which platform has more plugins.

Choose open source if:

• You have internal engineering that owns CMS patching as a named responsibility, not a side task
• You already run continuous vulnerability monitoring and a maintained plugin inventory
• You have staging, rollback, and a documented incident-response process in place
• Security staff sit in on architecture decisions for the marketing site, not just the product
• Budget exists for ongoing maintenance, not just the initial build

Skip it if:

• Marketing owns the site but can't ship a page without a developer
• Nobody can name who currently patches the server or audits the plugins
• The agency or developer who built it is no longer reachable
• You're heading into a security review and need a clean answer, not a long one
• The site supports regulated products, enterprise sales, or compliance-sensitive messaging
• Campaign speed matters and every change still routes through engineering

The question that actually settles the debate

The comparison your security team should be running isn't open source versus proprietary in the abstract. It's self-managed attack-surface responsibility versus managed platform responsibility, and which one your current team can actually sustain. Patchstack's 11,334-vulnerability year isn't a reason to panic about WordPress specifically. It's evidence that the patching burden on any open-source stack grows every year, regardless of how careful the last team was.

The risk was never a single breach, it's an ongoing operating cost dressed up as a one-time platform choice. Once you see it that way, the decision stops being about features and starts being about who's staffed to carry the weight indefinitely. If you're heading into a security review and need a straight answer about what your current platform is actually costing you to defend, book a discovery call and we'll walk through what moving to a managed stack would change for your team specifically.

Frequently asked questions

Is Webflow secure enough for fintech or healthtech companies?

Webflow maintains SOC 2 Type II compliance and ISO 27001 certification with Enterprise-tier controls like SSO, SCIM provisioning, just-in-time provisioning, and audit-log API access, which covers most of what a marketing-site security review asks for. That removes the infrastructure layer as a blocker for most fintech and healthtech teams. It is not built to store regulated patient or financial data, though, so health-information forms and anything touching cardholder data still need to route through a HIPAA- or PCI-compliant tool separately, regardless of which CMS hosts the surrounding site. Flag that routing requirement to your security team up front, not after the review starts.

What makes open-source CMS platforms riskier for enterprise buyers?

The risk isn't the CMS core itself, it's the accumulated stack around it: themes, plugins, runtime versions, hosting configuration, and integrations, each maintained by a different party or nobody at all. Patchstack's 2025 data found 91% of newly disclosed WordPress ecosystem vulnerabilities were in plugins, not core, which is where most unmonitored risk accumulates.

How often are new WordPress vulnerabilities disclosed?

Patchstack recorded 11,334 new vulnerabilities across the WordPress ecosystem in 2025, a 42% year-over-year increase, according to its "State of WordPress Security" report. That volume means vulnerability triage is a continuous task, not a periodic one, for any team running a self-managed WordPress site.

Does moving to Webflow eliminate the need for security review?

No, and no managed platform does. Moving to Webflow narrows the infrastructure your team has to directly administer, replacing the plugin-and-server layer with a provider that carries SOC 2 Type II and ISO 27001 certification. That gives your security reviewers concrete evidence to point to instead of a patchwork of plugin changelogs and an agency's word that updates happened. What doesn't go away: access governance for who can edit the site, integration security for every CRM and form tool connected to it, and incident response planning. Those stay your responsibility regardless of which platform hosts the CMS.

What is PHP2Shell and why does it matter for CMS platform choice?

PHP2Shell refers to a set of vulnerabilities in PHP-based environments that forced companies running PHP-dependent CMS platforms to audit their entire stack, runtime version, plugins, server libraries, and connected systems, for exposure. It's a live example of how platform architecture decides the size of your incident response before any specific vulnerability appears.

Sources

• Patchstack, 2025 — "State of WordPress Security" data: 11,334 new vulnerabilities disclosed in 2025, a 42% year-over-year increase, 91% in plugins.
• Webflow Trust Center — SOC 2 Type II, ISO 27001 certification, vulnerability-disclosure program, and PHP2Shell impact assessment.