Critical PHP flaws: why brochure sites do not need to run it

On 21 October the PHP project released emergency fixes for two critical vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0 and able, under certain conditions, to lead to unauthenticated remote code execution. The fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Unsupported branches get no official fixes. I take the exploitation conditions from the announcement on php.net, which I suggest checking: secondary sources are not always aligned.

I do not want to write yet another alarm piece. I want to say what the hours I spent updating servers reminded me of: most of the sites I look after had no reason to run PHP at all.

The cost of running code on every request

A WordPress site, on every request not served from cache, starts PHP, loads the core, the theme and the plugins, queries the database and assembles a page that will be identical to yesterday's. For a brochure site, where content changes once a year, the work is wasted and, worse, it is an entry point: as long as an interpreter is reachable from the internet, every flaw in the language, the core, a plugin or the theme is an emergency.

A flaw like these has an uncomfortable property: it does not depend on how careful you were with plugins. It hits the runtime underneath, the one you do not choose site by site. The only defence is prompt updating, and promptly updating dozens of sites, each with its own PHP version, its own hosting and its own plugin compatibility, is exactly the kind of work I would rather not repeat at every vulnerability. I covered it in Hacked WordPress site: the window between a flaw being published and the update is when automated scanners work best.

Why I am migrating brochure sites

That is why I am moving brochure sites to a static architecture. Not because WordPress is a bad tool, but because a site that rarely changes needs neither a database nor a language executed on every visit. The site is built once, at build time, and published as files on a CDN. Visitors receive ready-made HTML.

There are three practical consequences.

• A smaller attack surface: the public server runs no PHP, there is no wp-login.php and no database to reach. A flaw in the interpreter has nothing to hit, because there is no interpreter.
• Speed: the HTML is already built, so response time depends on the CDN and not on a server assembling the page. For LCP and Core Web Vitals it is a structural advantage, not a tweak, and so it helps SEO too. I wrote about what really makes a site slow in Slow WordPress site.
• Less urgent maintenance: no rush to update PHP, theme and plugins for a site nobody has touched in months.

Calling a static site «unhackable» is convenient but untrue. The GitHub, provider and domain accounts still need two-factor authentication, and so do the build dependencies and any server functions for forms or chat. The surface is small and known, not zero.

But how do you update the content?

It is the right objection, and for some clients the panel is indispensable: I know it well, I worked that way for years. The point is that the panel does not have to sit on the same server that serves the site. These are the routes I use or evaluate.

• Nuxt Studio: an editor that works on the project's Markdown files. Authors edit text in the browser, with a preview, and saving becomes a commit on GitHub; Netlify rebuilds the site. There is no database in between, and every change has an author and can be undone. It is the solution I use most often when the site runs on Nuxt Content.
• Strapi: a headless CMS you install and run yourself, with content types, roles and an API. I use it in Fix and Sail, where an application layer is needed too. It has its own database and server, but they are separate from the public site, behind restricted access.
• Storyblok or other hosted headless CMSs: the visual editor is hosted by the vendor, the site reads content through an API and rebuilds on every publish. You avoid running a server, in exchange for a fee and a dependency on an external service.

The choice depends on who writes. With three pages to fix once a year, Markdown is enough; with a person on an editorial team you need a panel; with several roles and approval flows you consider a real CMS. The common criterion is that the panel stays out of the visitor's path, so a flaw in it does not become a flaw in the public site.

When WordPress is still the right choice

I do not migrate everything. A WooCommerce store, an editorial team publishing every day, a site that depends on plugins with no simple equivalent: WordPress still makes sense there, and the job becomes keeping it lean, with few plugins, updated PHP and serious maintenance. The full comparison, with the migration procedure, is in From WordPress to Nuxt.js, GitHub and Netlify.

My take

I love WordPress, I have built sites with it that I am proud of. But the latest emergency made one thing clear: for a brochure site updated once a year, keeping a dynamic engine running just to show static pages is a risk that serves nobody. I prefer to build once, publish on a CDN and let security not depend on how fast I can update a server.

The site you are reading works this way: Nuxt, Markdown content, GitHub and Netlify, with a preview for every change and the main branch never touched directly. For people who need to update text on their own, the panel exists, but it lives somewhere separate. And if a site needs a rich panel, I say so plainly and do not force it onto a static solution.

Why work with me

I have delivered more than 300 projects and work with more than 30 agencies as an external developer, from Rome and remotely. I know WordPress from the inside, and that is why I can tell which sites should stay where they are and which should move.

If you have a brochure site on WordPress and want to know whether a static version makes sense, get in touch: in a chat of about 20 minutes we look at the site, who updates it and how often, and I tell you what I would do. The service is Website development.