If you run a business website, there is a reasonable chance it is built on WordPress or another PHP-based platform. Two PHP vulnerabilities, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed “PHP2Shell,” made headlines this week at Wired, The Verge, and the BBC, which reported websites being taken down worldwide as the update was issued.
This piece covers what happened, what you should do today if your site runs PHP, and why we think this is a good moment to look at a different way of building and hosting a business website. One that is faster, costs less to run, and has far less to patch.
What happened
On October 21, 2026, the PHP project published a security advisory and emergency releases for two flaws that allow unauthenticated remote code execution. In plain terms, an attacker who can send a web request to a vulnerable server may be able to run their own code on it, with no login required. Both are rated 9.2 (Critical) on CVSS v4.0, according to the PHP project’s pre-release notice.
A few details matter for anyone who owns a website:
- Every PHP installation that serves web requests is affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The PHP project considers the risk highest for mod_php, citing a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs (PHP advisory).
- The flaw is in PHP itself, not in your application. The Wiz researchers who were among those who discovered it wrote that “exploitation does not depend on a flaw in the application’s code” and that “even a simple ‘Hello World’ application running on an affected PHP version can be vulnerable.”
- Fixed versions are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 (PHP advisory). PHP 8.1 and earlier are end-of-life. The project published source-only patches for 7.4, 8.0, and 8.1 with no binary releases, which means older servers depend on a Linux distribution or hosting vendor to ship a fix (Sophos advisory).
- Updates are not automatic on many servers. Linux distributions and hosting vendors received the patches in advance, so check with yours. The PHP project says configuration workarounds reduce exposure to specific attack paths but do not make an installation safe (PHP advisory).
- Details leaked a day before coordinated disclosure (Sophos advisory), and BleepingComputer reported that Cloudflare’s CTO said the company was already observing early attacks targeting the two flaws. The UK’s National Cyber Security Centre told organizations to update, apply the PHP project’s temporary mitigations if they cannot, and if even that would take too long, “consider taking the system offline until it can be fully mitigated” (NCSC).
The reason this is a global story rather than a niche one is scale. As of this week, W3Techs measures PHP at 69.3% of websites whose server-side language it can identify, and WordPress alone at 39.6% of all websites it surveys.
If your site runs PHP, do this today
Patch first, think about architecture later. If a hosting company or agency manages your site, ask them to confirm which PHP version it runs now and when it was updated to one of the fixed releases above. If you run your own server, update PHP and restart every PHP worker. If you cannot update today, apply the temporary mitigations the PHP project published, understanding that they reduce exposure but are not a fix, and if you cannot do even that quickly, NCSC advises considering taking the system offline until it is patched. Sophos also recommends reviewing server activity from August 1, 2026 onward, since the flaws may have been known to third parties before disclosure.
That is the emergency. The rest of this article is about not having this emergency again.
A different way to build a business website
Most business websites do not need a program to assemble each page on demand. A services page, a team page, a location page, and a blog post are the same for every visitor. A traditional CMS like WordPress keeps a PHP runtime and a database listening for requests anyway. Caching can serve many pages without touching them, but the runtime is still there for logins, forms, uncached pages, and the admin interface, and that runtime is what PHP2Shell targets.
The alternative is usually called a static site or Jamstack, which jamstack.org describes as “an architecture designed to make the web faster, more secure, and easier to scale.” Pages are generated once, at build time, as plain HTML, CSS, and JavaScript files. Those files are then distributed to a content delivery network (CDN) and served from locations near each visitor. There is no PHP interpreter and no database in the path of an ordinary page request. The page is a file, and the CDN serves it. Interactive pieces, such as a contact form, run as small isolated functions that only execute when someone submits that form.
We practice what we are describing. This website is built from Markdown with a static site generator and deployed to a CDN, and the only server-side code is a small set of functions that handle form submissions and uploads, each with its own narrow job. Nothing on this site was exposed to PHP2Shell. We still track and update the handful of dependencies behind those functions and the build pipeline, which is a much shorter list than a CMS and its plugins.
Security: a smaller surface, not a nonexistent one
A static site removes two of the most common sources of website compromise: a general-purpose runtime exposed to the internet, and a plugin ecosystem. The scale of that second problem is easy to underestimate. Patchstack’s State of WordPress Security in 2026 report counted 11,334 new vulnerabilities in the WordPress ecosystem during 2025, with 91% of them in plugins, and 46% had no fix available from the developer at the time they were publicly disclosed. WordPress core itself accounted for only six. The exposure is the plugin layer, and most business sites run a dozen or more plugins.
We want to be precise here. A static site still has an attack surface. Your DNS and domain registrar accounts, your hosting account, your build pipeline, any third-party scripts you embed, and any form handlers or serverless functions all need the same care as anything else you run. The difference is that the list is short, the pieces are isolated, and none of them is the single most widely deployed server-side runtime on the web, which attackers study full time.
Speed and search
Pre-built pages served from a CDN are fast by default, because the work of assembling the page already happened. There is no database query and no PHP execution to wait on. That shows up directly in the metrics Google publishes for site owners. Google’s Core Web Vitals guidance sets targets of a Largest Contentful Paint within 2.5 seconds, an Interaction to Next Paint under 200 milliseconds, and a Cumulative Layout Shift under 0.1, and says that good Core Web Vitals, “along with other page experience aspects, aligns with what our core ranking systems seek to reward.”
Google does not promise that speed alone moves rankings, and we will not promise it either. What we can say is that a static site makes those targets easier to hit, provided you are disciplined about the analytics and third-party scripts you add on top, and a slow, plugin-heavy site makes them hard. The same pre-built pages are also simple to cache, which is why they hold up under traffic spikes without anyone scrambling to add servers.
Cost
A static site has no server to size, patch, or monitor, and no database to back up. Hosting itself is cheap. Netlify’s entry plan is free, while the lowest WP Engine managed WordPress plan is $28 per month billed annually, and that is before security plugins and a maintenance retainer. You still pay for pieces like form handling and email delivery on a static site. The larger difference is what maintenance looks like. There are no plugin updates, no compatibility breakage after each one, and no emergency weeks like this one. There is still ongoing work to keep content current and dependencies updated, and we are upfront about what that costs.
Where Managed Intelligence changes the math
Many businesses chose WordPress because a fully custom site from an agency cost more than they could justify, and WordPress offered a workable middle ground. For sites that mostly publish pages and posts, that trade-off has changed.
As a Managed Intelligence Provider, part of our work is helping organizations use agentic coding tools under the supervision of experienced engineers. In our own practice, those tools have materially shortened the time it takes to build, revise, and maintain a bespoke static site compared with the traditional agency model. A site that used to require a large upfront design and development engagement, followed by a change-request process for every edit, can now be built as a lean, custom codebase and kept current as part of normal operations. The economics that pushed small businesses toward one-size-fits-all platforms are not what they were.
The engineer stays in the loop. The tools draft and refactor. A person reviews for accuracy, accessibility, security, and whether the site actually says what your business needs it to say. That is the same People+ principle we apply to every piece of AI we help a client adopt, and it is the reason we are comfortable putting our own name on the result.
Where to start
If your site runs PHP, confirm today that it has been patched. Then, when the urgency passes, ask a simpler question: does your website need to run code for every visitor, or does it need to be fast, secure, and easy to keep current?
For many businesses in Alaska and Hawaii, we think the answer points toward a modern static site. If you would like to see what that looks like for yours, book a short discovery call and we will review your current site and give you a straight read on what a modernized version would involve and cost.