Key takeaways
- PHP2Shell is a pair of critical PHP flaws, patched on October 21, 2026, that let attackers run code on a web server without a password.
- The fix lives on the server, not in the CMS, so the real test was whether someone owned that server and could act the same day.
- It was a global event: from the US and LATAM to Europe and China, any site running on PHP was exposed until the fix was installed.
- Webflow says its core services don't run on PHP, so Webflow-hosted sites needed no patch. Logins, custom code and scripts still need an owner.
- For fintech, SaaS and AI companies, buyers judge your security through your site, so an owner for every layer is now a sales issue too.
What is PHP2Shell?
PHP2Shell is the name for two critical flaws in PHP (CVE-2026-109618 and CVE-2026-109619), the server language behind WordPress, Drupal, Magento and most self-hosted websites. On an unpatched server, an attacker could run their own code without logging in. Both flaws are rated 9.2 out of 10.
For a business, that means someone could change what your site shows, read data stored on the server, or use it as a way into other systems. PHP's own security advisory says every PHP installation serving web requests is at risk.
The window was short. A first exploit attempt was spotted on October 17, details leaked on October 20 and PHP shipped fixed versions on October 21: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. By October 22, attacks were widespread, though no confirmed break-in of a named site had been reported.
Was PHP2Shell a US problem or a global one?
Global. The flaw sat in PHP itself, so every PHP server was in scope, whatever country it ran in. Governments, universities and companies took sites offline on several continents, mostly as a precaution. Europe and Asia were exposed in the same way, wherever a site ran on PHP.
The Americas show how wide it went. In the US, CISA urged immediate patching and the FBI advised taking systems offline until they were fixed. Brazil ordered its federal agencies to patch at once, and Colombia's cyber response team counted 8,699 exposed PHP services. Argentina and Mexico saw no major outages, but PHP sites there run the same versions and carried the same risk.
For a company selling across the Americas, the takeaway is simple. Where your team, host or customers sit changed nothing. If anything on your domain runs PHP, you were affected.
Why didn't updating WordPress fix it?
Because the flaw sits in the server software underneath WordPress, not in WordPress itself. Updating the CMS, the theme or every plugin left PHP exactly as it was. Only whoever controls the server could install a fixed version.
That is where most teams got stuck. Marketing can usually log in to the CMS, but the server is often run by a host, an IT team or a developer who set it up years ago. Older sites had it worse: PHP 8.1 and earlier got no official fixed release, so those sites needed an upgrade or a fix built by the host.
Why was finding the owner harder than the fix?
Because many websites are launched and then left. The site is built as a project, the freelancer or agency moves on, and the hosting login stays in an old inbox. The patch itself is a routine update. The slow part is everything around it: knowing which PHP version you run, finding who has server access, and agreeing who can take the site offline.
This is why we treat a website as a product, not a project. A product has an owner after launch, a backlog and a release rhythm. A project has a handoff date. Our Expand squads ship on a three-day cadence across 25+ ongoing partnerships, and part of that work is knowing what runs where and who holds the keys.
Ownership should also keep marketing moving. On Kolibri, we set up a modular CMS so the marketing team published 30+ ebooks and articles in under 8 months without a developer. A good handoff gives marketing the parts it should run and names who handles the rest: hosting, updates and security.
Our tip: Write a one-page site register: platform, host, PHP version, who has admin access and who can take the site offline. If it takes more than an hour to fill in, that gap is a bigger risk than PHP2Shell.
What does PHP2Shell mean for fintech, SaaS and AI companies?
It turns website security into a sales and fundraising question. In these categories, buyers and investors judge the company by its site before they take a call, and an incident on the marketing site still reads as an incident at the company.
- Pipeline: a site in maintenance mode collects no demo requests, while paid campaigns keep sending traffic to an error page.
- Security reviews: enterprise buyers ask how you patch and who responds to incidents. “We had to find out who owns the server” is a weak answer.
- Compliance: if personal data was exposed, US state breach laws, Brazil's LGPD and similar rules can require notifications. Your legal team decides what applies.
For Centinel, a Madrid fintech, we built a Trust & Control section that names SOC 2 Type II and GDPR compliance, because security is part of what its buyers evaluate. The site booked 5 enterprise leads in its first month, and Centinel raised a €1.2M pre-seed after launch. A trust section only holds up when the operations behind the site match it. Our guide to fintech website design covers what reviewers look for on the page.
Was Webflow affected by PHP2Shell?
No. Webflow's Trust Center states that “Webflow's core services are not built on PHP and are not affected,” and that no action is required from customers. Webflow runs and patches its own hosting, so there was no server for your team to update.
A managed platform moves one layer of ownership, not all of them:
The last row is the one teams miss. A Webflow marketing site can sit next to a WordPress blog, a careers portal or a self-hosted tool on a subdomain, and those were exposed like any other PHP server.
What should you do this week?
Confirm the fix first, then fix ownership. This is the order we recommend.
Today
- Ask which PHP version runs your site. Your host, IT team or agency should answer within the day. Safe versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35, or newer.
- Restrict or pause anything unconfirmed. If the site runs PHP 8.1 or older, or nobody can confirm the fix, take it offline and serve a 503 status so search engines treat the downtime as temporary.
- List every subdomain and tool on your domain. Then make sure to check each one for PHP.
This week
- Review server logs from October 17 onward. If anything looks unusual, rotate passwords and API keys, since one of the flaws can expose data held in server memory.
- Clean up access. Remove former freelancers and agencies from hosting, the CMS and your Webflow Workspace, and turn on two-factor login.
- Fill in the site register from the tip above and share it with marketing, IT and leadership.
This quarter
- Name one owner per layer in writing, including who can take the site offline and who tells sales and marketing.
- Plan your next upgrade early. PHP 8.2 reaches end of life on December 31, 2026.
- Add your website to your security answers. The next buyer questionnaire should not be a scramble.
Should you leave PHP after PHP2Shell?
Not because of one week. Patch now, then decide based on who you want owning your server for the next few years.
PHP itself isn't the problem. A stack nobody owns is. If your team has the people and process to run servers, staying on a well-managed PHP setup can make sense. If you'd rather your team spends its time on pages, campaigns and conversion, a managed platform takes the server off your plate.
Amigos Ingleses made that switch after 13 years on a WordPress, Teachable and ThriveCart stack that broke often. We moved 20+ pages and 280+ blog posts to Webflow without losing a single SEO ranking, and the team now launches campaigns up to 3x faster.
If PHP2Shell made you rethink who owns your server, our Transform team can plan and run your move to Webflow, with your SEO intact.
