Is a Static Website Really More Secure? What It Actually Removes
Two PHP bugs scored 9.2 out of 10 under CVSS v4.0. Here is what a static-first build on Astro, GitHub, and Cloudflare actually removes from the request path, and what it just moves.
Is a Static Website Really More Secure? What It Actually Removes
On October 21, 2026, the PHP project fixed two remote code execution bugs. They were scored 9.2 out of 10 under CVSS v4.0. The nicknames came fast, because there is a set of people whose whole job is reacting to exactly this, and they were up all night doing it.
If you run a site built on PHP, that night cost you: patch, restart, verify, repeat on every server you have. If you run a site on Astro, it cost you nothing, because there is no PHP in the request path. I have been asked directly whether any of the tools I build on use PHP, and the answer is no. This post is the longer version of that answer, including the parts that make the answer less satisfying.
Because the honest version of "static sites are more secure" is not a victory lap. It's a claim about where the work moved.
What PHP2Shell actually was
The two bugs are CVE-2026-109618 and CVE-2026-109619. The PHP project describes the first as remote code execution through corruption that happens while the engine is cleaning up a request that ran out of memory. The second as request-owned global state surviving past the request that owned it, then getting reused by a later request on the same worker. That description comes from the Dutch national cyber security centre's advisory repo, which is the plainest version I have read of either one.
Three things about the blast radius matter more than the mechanism.
It goes back a long way. The bugs are present in every unpatched PHP release since 5.4, which means versions that stopped receiving support years ago are still affected, and the official fixed releases cover only 8.2 and later: 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Anything on 8.1 or older gets no official build. You are waiting on a distribution to backport, or you are upgrading a system that has been stable for a decade.
Nobody could turn it off from their own code. You cannot fix this from inside your application, and no configuration change fully resolves it. The published mitigations, all of which were circulating within hours, reduce exposure and are explicitly described as partial and temporary. Blocking multipart uploads at the web server. Capping post sizes. Turning off session upload progress. Disabling fatal error backtraces. Four knobs, all of them a downgrade to something you were using PHP for.
The last one is the interesting one. session.upload_progress ships enabled by default, which is how a bug in the engine's request cleanup turns into code execution on a server running someone's Drupal that they patched last spring. Nothing about that involves their code being wrong.
The part that complicates the story
Here is where the evidence cuts against the scary version, and I would rather write it than leave it out.
watchTowr published a running FAQ on these bugs and reported exploitation in the wild, observed through its own honeypot network on release day. That is the highest-quality part of the panic, and it is worth taking seriously.
Sansec, the firm that publishes on ecommerce attacks, ran in the opposite direction after its first assessment. Its October 22 update said that mass exploitation was less likely than it first expected, because an attack needs specific knowledge of the target server and specific conditions on it. The public exploits that appeared did not work against a default PHP installation. Most needed another bug already present in the target application, a local file inclusion, which is a severe problem of its own. Several Dutch sites took themselves offline as a precaution, including their parliament and their national cyber security centre. Sansec's line about that was blunt: you do not need to take your store offline.
Both of those things are true at once. Attempts against real servers were observed, and the crashes that made the news were mostly fear doing the work.
So the honest reading is not that PHP is falling apart. It is that a 9.2 in the engine underneath your application is a jobs-for-everyone event no matter how good your code is, and that whether it converts to a breach depends on the specific shape of your server. That second clause is the whole problem. It is not a control you own.
Where the target actually is
PHP runs about 70 percent of the web, if you mean sites whose server-side language can be identified, which is where that number comes from. Its maintainers shipped fixes for eight release branches inside a day. The PHP security team is not the villain of this story, and anyone writing an article that implies otherwise has told you more about their stack preference than about security.
The difference between that and what I build is not code quality. It's the shape of the request path.
A traditional PHP stack works like this, on every single request: a web server hands the request to a process, that process parses your script, the script talks to a database, and the result gets rendered on the way back out. Four standing systems, all of which have to be running, patched, and listening, for the page to appear.
My stack works differently, and it is worth being precise because the details are where the security actually lives. Astro generates HTML at build time, either on my machine or in a CI job. The output is files. Those files go to GitHub, and a build service hands them to Cloudflare, which serves them from the edge. When someone visits, Cloudflare finds a file and sends it. There is no process parsing a program to decide what page to return.
Not everything here is a file, and I would be lying if I said it was. The site runs under Cloudflare Pages in server mode, which means some routes are rendered on demand in a Worker rather than built ahead of time. The booking calendar is Cal.com, loaded as a third-party iframe. A contact form endpoint, when there is one, is a small serverless function handling input. Those are real programs with real trust boundaries and I treat them that way.
But the pages, the posts, the pricing tables, the case studies, the overwhelming majority of what this site returns to a stranger: that is a file lookup. The engine that ran is gone by the time the request exists.
Three things that actually removes
One: there is nothing to run code on. Remote code execution needs a program to execute in. With no application worker in production and no database listening on a port I have to defend, the attack that PHP2Shell describes does not have a place to land. That is not a claim that this site is unhackable. It's a claim about the specific step in the attack chain that a bug in this month's PHP release sits in.
Two: content edits never touch a running system. Keystatic, which runs the content side of this site, stores content as files in a Git repository. Editing a page in the admin writes a commit. Deploying rebuilds the site from that commit. There is no public admin endpoint to credential-stuff, no database to inject into, no plugin ecosystem waiting for someone to publish a malicious update to it, and no version of this site where the production server has write access to the content. The write boundary is GitHub's, and it already has a patch cadence, an auth system, and audit logging that I did not have to build.
Three: when something goes wrong in the build, nothing bad is live. A malicious npm package published this month, a compromised CI action, a bad dependency bump: any of those can poison a build. But the thing it poisons is a build. Nobody gets served a page that was never accepted, and reverting is a commit. Compare that to the PHP case, where the fix has to reach every running server, in order, before the bug stops mattering.
That third point is not a total win, and the next section is about why.
Where this argument breaks down
The strongest objection to everything I just wrote is not PHP. It's npm.
I build the site out of hundreds of packages from a public registry. If one of them, or one of their transitive dependencies, ships malicious code, my "no runtime" story is worth nothing, because the malicious code compiles into the static files I ship to the edge. The attack moved from the request path into the supply chain, which is the same reason the last two years of security news have been about it. Static-first does not make me immune to that. It moves where I have to be careful.
Second, anything that accepts input is a server program again. A contact form, a search endpoint, a webhook receiver, a checkout: the moment user-controlled data reaches code that has to decide what to do with it, every rule that applies to a backend applies. Smaller surface is not the same as no surface, and anyone selling you "no attack surface" is selling.
Third, architecture is not configuration. A static site with a loose Content-Security-Policy, or a secret baked into a bundle, or an exposed storage bucket, is simply a smaller target that someone will still hit. Fewer things to secure is not the same as secured. This is the part of the argument I care about most, because the small-target framing is where a lot of people stop working.
Fourth, and worth saying plainly: none of this is a claim about my skill. The architecture gives me fewer places to make a mistake. It does not choose a good CSP for me, or keep a token out of a commit, or notice that I left a debug route public. I still run an OWASP ZAP scan on every build, still let Dependabot file its pull requests, still run npm audit when a dependency moves, because the architecture is worth exactly what I do with it.
What I would actually tell someone choosing
If you are building a system where every request runs your application code, you are signing up for a patch cadence forever, and that is a completely normal thing to sign up for. Most real software is that. You can run it well; most of the internet is doing it right now, including the parts I use.
But if what you are publishing is content, then a static-first build changes the class of risk you carry, and the difference is concrete. The question stops being "have I patched every server" and becomes "have I patched my toolchain in CI." One of those is something you can verify in a build log before it ever reaches production. The other one has a night in it.
That is the actual answer to whether a static website is more secure. Not that it is safe, and not that PHP is dangerous. It is that I would rather fix a build than argue with a running server at two in the morning.
The other half of the argument is that a site which is a set of files is a site you can keep answering questions on for a decade without an incident report. That is what how a project runs is built around, and it is the reason the full inclusions are published instead of described in a sales call.
Further reading