Webflow security after PHP2Shell: what a hosted site takes off your patch list.

Webflow security works differently from a WordPress or other PHP site: a site hosted on Webflow gives your team no PHP installation, plugin, or server to patch, so the PHP2Shell flaws fixed on October 21, 2026 add nothing to your own patch list. This post is for marketing leads and founders at B2B SaaS companies who own the marketing site, including teams facing an enterprise security review, and it reflects the facts as of October 2026.

What happened with PHP2Shell in October 2026?

PHP2Shell is the name given to two critical vulnerabilities in PHP itself, CVE-2026-109618 and CVE-2026-109619, which the PHP project fixed on October 21, 2026. Both are rated 9.2 on CVSS v4.0, and both can let an attacker run code on a web server without logging in.

The timeline moved fast. On October 20, the PHP security team announced an emergency release for 14:00 UTC the next day and said it might ship earlier if details became public or attacks appeared. Details did leak. Cloudflare says it "observed attack traffic targeting our customers" before the official release and deployed web application firewall (WAF) rules for all plans, including free ones.

The two advisories describe memory-safety bugs in how PHP handles fatal errors:

• CVE-2026-109618 (RCE via OOM corruption). When PHP runs out of memory early in a request, it can leave request data half-initialized, and cleanup later treats it as valid. The advisory says this can lead to unauthenticated remote code execution as the web worker account, validated against mod_php with default limits.
• CVE-2026-109619 (RCE via stale global state). Request-owned state can survive after its memory is freed, so the next request on the same worker can use it. Confirmed paths run through PHP 8.5 fatal error backtraces and session upload progress, validated against mod_php and PHP-FPM.

Researchers at Wiz, among the credited reporters, say they first reported the issues to PHP in August 2026. They also say they confirmed unauthenticated remote code execution against the latest WordPress, Drupal, and Joomla container images, and that "even a simple 'Hello World' application" on an affected version can be vulnerable.

Why do PHP vulnerabilities put WordPress sites at risk, and is WordPress secure?

PHP vulnerabilities like these sit below the application, so every WordPress site, plugin, and theme inherits them from the server. Cloudflare puts it plainly: updating website code or plugins alone does not fix these flaws, because they are in the PHP runtime.

That is a large surface. W3Techs reports that PHP is used by 69.3% of websites whose server-side language it can identify (October 21, 2026). Among those PHP sites, 27.0% run PHP 7 and 7.7% run PHP 5, versions the PHP project no longer supports. Those sites get no upstream fix and depend on a host or vendor that backports one. Here, outdated software means the language itself, not only an old plugin.

PHP2Shell is also the second emergency of its kind for WordPress sites in 2026. On July 17, 2026, WordPress 7.0.2 fixed a REST API batch-route confusion and SQL injection chain that led to remote code execution in WordPress core. Both of these WordPress vulnerabilities came from the core software and the language under it, not from a plugin. Plugin vulnerabilities still matter as well, because every one of the third party plugins on a WordPress site adds code that runs on the server.

So, is WordPress secure? WordPress can be run securely with good security practices, but someone has to own every layer: the server, PHP, WordPress core, themes, plugins, logins, and backups. When that owner is a strong managed host, most of the stack is covered. When it is a marketing team with a one-off developer, the gaps show up exactly in weeks like this one.

The question for a B2B SaaS marketing lead is less "is WordPress secure?" and more "who on my side applies security updates when PHP needs an emergency patch?" If the answer is unclear, that gap is the biggest risk to your site security.

Is Webflow secure against PHP vulnerabilities?

For the site itself, yes in the sense that matters to your team: Webflow is a completely managed hosting platform, so there is no PHP version, plugin, or server configuration on your Webflow site for you to find and update. Webflow's help center says the managed hosting means "you don't have to worry about scalability, site downtime, or applying security patches."

Webflow describes its hosting environment as combining AWS infrastructure with Cloudflare's global CDN. On its hosting page, it says, "We continuously monitor for new security vulnerabilities and deploy updates automatically," and that customers have "no updates to run, packages to install, or capacity planning." Unlike WordPress, a Webflow site does not install server plugins: a WordPress plugin cannot run in Webflow, so features come from built-in settings, integrations, or custom code that runs in the browser.

Two caveats keep this honest:

1. Webflow does not publish which server software runs its platform, and it had not posted a statement on PHP2Shell when this was written. The accurate claim is about responsibility: platform patching is Webflow's job, not yours.
2. A managed platform moves risk; it does not remove it. If Webflow had a flaw of its own, you would depend on its security team to fix it. That is the trade you make with any hosted service, and it is why the certifications and security documentation below matter in procurement.

We build and migrate Webflow sites for B2B companies, so we have an interest in the topic.

What security features does Webflow include, from DDoS protection to SOC 2 Type II?

Webflow security covers the hosting environment, encryption, DDoS protection, and recovery by default, and Webflow Enterprise adds the security controls that vendor reviews often ask for. The table lists what Webflow states on its own pages as of October 2026.

SSL certificates also mean browsers do not show "not secure" warnings, which protects user trust as much as the data transmitted between visitors and your site.

For procurement, Webflow's Trust Center lists its security documentation, including SOC 2 Type 2 reports, an annual pentest report, CAIQ and SIG Lite self-assessments, and a Shared Security Responsibility Model. Sensitive documents sit behind a "Get access" request, so ask for them early in a security review. The Trust Center states that Webflow is "independently audited for SOC 2 Type II and certified ISO 27001 compliant." For GDPR, Webflow's Data Processing Agreement says it acts as a processor for customer personal information, except for customer relationship data, where it is an independent controller.

Two practical notes. Webflow does not offer scheduled backups, so take a manual backup before large changes. And if you are asking whether Webflow is HIPAA compliant, Webflow's own answer is that it is not HIPAA compliant by default, so healthcare organizations should not collect protected health information through Webflow forms.

What does Webflow Enterprise add for security teams?

Webflow Enterprise adds the identity, audit, and contract controls that enterprise security teams usually require before they approve a vendor: single sign-on that can be enforced, automated provisioning, an audit log API, custom security headers, and written SLAs for uptime and incident response. If your company runs a heavy vendor security review, start with these.

A week like PHP2Shell shows why. When a critical flaw lands, your security team asks every vendor the same questions: were you affected, when did you patch, and who do we call? Webflow's Enterprise page lists "defined incident response SLAs and a clear escalation path," which gives that question a contractual owner. On a self-managed PHP stack, the owner is your own team.

Three details matter in a review. Guest members do not need SSO even when it is enforced, so list every guest, including agency accounts, and decide who keeps access. The audit log API is pull-based, and Webflow says logs are available "within at least 10 minutes of the event," so your security team has to poll it rather than wait for alerts. And custom security headers, which help against cross site scripting attacks, are available only on Enterprise, so a site on another plan cannot set its own Content-Security-Policy header.

These are the terms Webflow publishes; confirm the SLA wording and response times in your own contract. For the rest of the plan, including timelines and governance, see our guide on what to check before you buy Webflow Enterprise, and our Webflow Enterprise agency page covers how we run those projects.

What security work stays with your team, from login credentials to access controls?

Your team still owns everything that is not the platform: who can log in, what code you add, where customer data goes, and any other system the site connects to. On a hosted site, these are the parts of site security that remain yours.

• Login credentials and access controls. Turn on two-factor authentication with an authenticator app for every account, give each person the lowest role that works, and remove access the day someone leaves. Unique passwords plus a second factor blunt brute force attacks and repeated login attempts. Shared logins defeat all of this.
• Custom code and third-party scripts. Every tag manager container, chat widget, or embed runs JavaScript code in your visitors' browsers. A compromised script can run malicious code on every page. Keep an owner and a purpose for each script and remove the ones nobody can explain.
• Form destinations and data handling. Know which CRM, automation, or webhook receives each form, and do not collect sensitive data or personally identifiable information you do not need.
• Staging and private pages. Use password protection to restrict access to unreleased pages, and remember that Webflow says uploaded files are not restricted and can be opened by direct URL.
• The rest of your web presence. A WordPress blog, help center, careers site, or landing-page tool on a subdomain still runs its own stack. If any of it runs PHP, PHP2Shell applies to it today.
• Your domain and DNS. Protect the registrar account with two-factor authentication, because whoever controls DNS controls where your site points.
• Incident response. Write down who can lock accounts, restore a backup, and contact Webflow support, so a bad day does not start with a search for passwords.

Our website maintenance checklist covers how often to review each of these.

How does Webflow security compare with WordPress security?

The main difference from traditional CMS platforms is who patches what. On a self-managed WordPress site your team or hosting provider applies security patches to the server, PHP, core, themes, and plugins; on Webflow, the platform patches the hosting layer and you manage access and the code you add.

Neither column is risk-free. A well-run WordPress site on a strong managed host can be safer than a Webflow site with shared logins and unreviewed scripts. What changes on Webflow is the maintenance burden: the hardest layer to staff, emergency server patching, is no longer on your team's list.

What should you do this week if part of your site runs on PHP?

Patch first, then reduce how much of your site depends on a server you have to patch. The UK NCSC's guidance for PHP2Shell gives a clear order, summarized here.

1. Find every PHP installation, starting with internet-facing ones: the main site, blog, help center, staging servers, and any appliance or service that bundles PHP.
2. Update to a fixed release (8.2.35, 8.3.36, 8.4.27, or 8.5.12) or your vendor's backport. If a host manages PHP for you, ask them for a date in writing.
3. Apply temporary mitigations from the PHP advisories if you cannot update yet, such as disabling session upload progress, and keep web application firewalls in front of the site. Cloudflare says its WAF rules are not a substitute for patching PHP.
4. Consider taking a system offline if you can neither patch nor mitigate it quickly, as the NCSC advises.
5. Check for signs of compromise. Wiz lists unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, oversized or malformed PHPSESSID cookies, and unexplained PHP worker restarts.

Once the emergency is over, decide whether your marketing site needs a server at all. If it is mostly pages, a blog, and forms, a managed platform removes a whole class of PHP vulnerabilities from your patch list. Our WordPress to Webflow migration guide explains how to move without losing search traffic, and our Webflow migration service handles the move for you.

Questions about Webflow security and PHP2Shell