Short version
On October 20 and 21, 2026, two critical PHP vulnerabilities (PHP2Shell) became public. They can let an attacker run code on a web server remotely, so sites like Smartschool, Knack, and DigiD went offline as a precaution. WordPress runs on PHP, so it is directly involved. A plugin won't fix this: your host has to update PHP to 8.2.35, 8.3.36, 8.4.27, or 8.5.12. A static website, built with Astro and optionally a headless CMS, runs no PHP on the server and has nothing to patch when a flaw like this appears. It is not invulnerable, but its attack surface is much smaller.
Wednesday, October 21, 2026 was a strange day on the web. Smartschool, a school platform widely used in Flanders, was down. So were the Roularta magazines Knack and Libelle, the Belgian rail infrastructure manager Infrabel, and all Flemish government websites. In the Netherlands, the government login DigiD and the site of the House of Representatives went dark too. None of them had been hacked. They took themselves offline as a precaution, because of two critical vulnerabilities in PHP, the programming language that an estimated 70 percent of all websites run on. WordPress runs on PHP too. If you are a self-employed professional or a small business with a WordPress site, here is what happened, what to do now, and why a static website is not affected.
What happened on October 21, 2026
On Tuesday, October 20, the first details leaked about two new PHP vulnerabilities, soon nicknamed PHP2Shell. They are tracked as CVE-2026-109618 and CVE-2026-109619, and the PHP security team rated both 9.2 out of 10. They are remote code execution flaws: an attacker can use an ordinary web request to run their own code on the server. That can lead to stolen data, a defaced site, or a full server takeover.
The timing was the hard part. The patch was scheduled for Wednesday afternoon, while the details were already circulating. According to Sansec, Cloudflare reported the first attacks on Wednesday morning. The Dutch government’s cybersecurity agency NCSC and the PHP Foundation had not seen active exploitation later that day. Many organizations did not want to take the risk and went dark, as NOS and De Morgen reported throughout the day.
The maintenance modes built into Magento and WordPress do not help: PHP still parses each request before the application checks for the maintenance flag.
The update arrived just before 4 p.m. Central European Summer Time. According to the advisory on php.net, PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12 fix both flaws. The PHP project considers the risk highest on servers running Apache with mod_php. Sites on PHP 8.1 or older no longer get updates from the PHP project. There are only minimal source backports for 7.4, 8.0, and 8.1, so most hosts will have to move those sites to a newer PHP version first.
Why your WordPress site is directly involved
WordPress is written in PHP. Every time someone requests a page on your site, the server starts PHP, WordPress pulls the content from a database, and PHP builds the page on the spot. That is exactly where this flaw strikes.
The flaw sits in front of WordPress, not inside it
Most WordPress problems come down to an outdated plugin or a weak password. A security plugin or a WordPress update can help with those. Not this time. PHP processes the incoming request before WordPress runs a single line of code, which is why even maintenance mode is no protection, as the Sansec quote above explains.
So the fix happens at the server level. On shared hosting, the plan most small businesses use, you can’t do that yourself. You depend on your host: how fast it installs the update and restarts the PHP processes.
What to do now
You don’t need to be a developer to check whether your site is safe. Go through this list:
- Check your PHP version. In WordPress, you’ll find it under Tools > Site Health > Info > Server.
- Compare it with the fixed versions: 8.2.35, 8.3.36, 8.4.27, or 8.5.12, depending on your branch. A lower number in the same branch has not been updated yet.
- Ask your host in writing whether PHP has been updated and whether the PHP processes were restarted. An update that isn’t active protects nothing.
- Is your site on PHP 8.1 or older? Ask for a move to a supported version, preferably 8.3 or later: according to php.net, PHP 8.2 only gets security fixes until December 31, 2026. Make a backup first that you can actually restore, because older themes and plugins don’t always work on a newer PHP version.
- Using Cloudflare? According to Sansec, Cloudflare rolled out firewall rules against the known attacks, including on the free plan. That is a stopgap, not a replacement for the update.
- Afterward, check that no unknown administrators were added to your WordPress site and that everything still works as it should.
I describe a regular maintenance routine with updates, backups, and checks in WordPress maintenance: what it involves and what it costs. Such a routine would not have prevented this flaw, but you’ll know who to call and how to roll back.
When your WordPress site is too old to update
For some sites, “just update PHP” is easier said than done. Older WordPress installations sometimes rely on plugins or a theme that are no longer maintained: they have reached end of life, and their makers no longer release updates. A plugin like that often stops working on a recent PHP version or a new WordPress release. That is why the whole site got stuck on an old version.
A flaw like this one then forces a hard choice. Either you keep running a PHP version that no longer gets security fixes, or you update and accept that parts of your site stop working. Repairing it means replacing outdated plugins, adapting the theme, and testing everything again. That is often almost as much work as building a new website.
At that point, it pays to ask a broader question: do you still need WordPress, or does a static site fit better with what your website does today? If you are one of our clients and your site still runs on an older WordPress installation like that, we’re happy to look at the smartest option with you: updating, replacing, or rebuilding.
Why a static website is not affected
There is another way to build a website. With a static website, every page is built ahead of time, once, when you publish something. The result is a folder of plain HTML, CSS, and JavaScript files. Those files sit on a CDN, a network of servers that delivers them as close to your visitor as possible.
When someone opens one of those pages, no PHP runs and no database is queried. The server sends a file that was already waiting. A PHP flaw has nothing to hook into, because there is no PHP. While organizations across Belgium and the Netherlands were patching PHP servers on October 21, a site like that needed nothing. The next PHP flaw won’t change that.
This website is an example. Straffe Sites runs as a static Astro site on Vercel. The handful of server functions it has, for forms and quotes, run on Node.js, not PHP. For this site, there is nothing to patch or take offline. That doesn’t mean the flaw doesn’t concern us: we also host and maintain WordPress sites for clients, and everything in the previous section applies to them just as much.
And if you want to edit content yourself?
That is what a headless CMS is for. In a headless setup, you manage your content in a CMS such as Storyblok, which runs at the vendor. On every publish, the build fetches the content and turns it into static pages again. Your editing environment is not on your own domain, and your visitors never talk to the CMS. The vendor maintains and patches its own platform with its own security team. You can read how such a project works on the page about headless website development.
| Question | Traditional WordPress site | Static Astro site | Astro with a headless CMS |
|---|---|---|---|
| What happens on every visit | PHP builds the page from a database | A prebuilt HTML file is sent | A prebuilt HTML file is sent |
| Does PHP run on your server | Yes, on every visit | No | No |
| Database behind the pages | Yes, with posts, users, and settings | No | No, the content lives at the CMS vendor |
| Login page on your own domain | Yes, /wp-admin | No | No, you log in at the vendor |
| Who had to act on October 21 | Your host, and often you or your developer | Nobody | At most the CMS vendor, for its own platform |
| Recurring maintenance | Core, theme, plugins, and PHP version | Build dependencies | Build process and CMS connection |
Static is not the same as invulnerable
It would be dishonest to pretend a static website can’t be hacked. The attack surface is smaller, but it doesn’t disappear. It moves elsewhere:
- Your hosting account and your Git account. Anyone who gets in there can change your site. Turn on two-factor authentication everywhere.
- Your domain name and DNS settings at your registrar. Those deserve a strong password and two-factor authentication too.
- Third-party scripts, such as chat widgets, ad pixels, and embeds. Every external script is code you don’t control.
- Forms. They send data to a service or server function, and that has to be secure in its own right.
- The packages your build process uses. You keep those up to date, just as you would with WordPress plugins, only less often and without visitors being able to reach them directly.
The real difference
With WordPress, there is a program on your server that processes every request from a stranger. With a static site, the server processes nothing and only delivers files. A flaw in that processing step, like PHP2Shell, simply has nothing to hit.
When static HTML is not the right choice
You can’t fit Smartschool, DigiD, or the Infrabel website into a few HTML and JavaScript files. Platforms like those have logins, personal data, schedules, messages, and connections to other systems. They need real server applications, and therefore teams that patch when something goes wrong. Taking them offline as a precaution on October 21 was a responsible call.
The same applies, on a smaller scale, to an online store with a lot of product logic, a member area, or a booking system. Those need server logic, in PHP or another language. And if your WordPress site works well, with a host and a developer who respond quickly when needed, there is no reason to panic.
But most websites of self-employed professionals and small businesses are not platforms. They show who you are, what you do, a few references, a blog, and a contact form. For a site like that, a server that builds every page live is a heavy engine for a short trip. You pay for it with maintenance, updates, and days like October 21.
From WordPress to a static site: how it works
A move starts with an inventory: which pages, posts, and forms you have, and which URLs bring in visitors from Google. The content is migrated, the pages are rebuilt in Astro, and old URLs get a redirect if they change. Forms go to a separate service or a small server function. If you want to keep publishing yourself, a headless CMS is added. If not, the content can live in the code, as it does on this site. I explain how that works in a website without a CMS.
If you want to know how we build sites like this, see the page on how to hire an Astro developer. And if this flaw made you wonder whether your site could work differently, ask your question. We’ll give you an honest look, even if the answer is that your WordPress site is fine as it is.