Build for search and AI.

What does a static website change about security?

A static website is a set of finished files. When someone opens a page, nothing builds it on a server, so a flaw in the software that builds pages cannot be reached through a visit. The site still has accounts, build tools and an owner to look after. This page says what changes, what does not, and how to check it yourself.

Every dated fact below names its source and the day we read it, and says whether it is about the Croftweaver site template, about croftweaver.com, or about someone else's product. Read from 22 October 2026 to 23 October 2026.

Is Croftweaver safer than WordPress?

On one point, yes.

The Croftweaver site template holds no PHP files, and neither does the repository of croftweaver.com. The server-side code of both is written in TypeScript, so a flaw in PHP does not apply to either, whatever its date. Many well-known systems, WordPress among them, are written in PHP, so a flaw in PHP applies to servers that run an affected PHP version.

Our judgment, not a measurement: more critical flaws will be found in PHP after the ones fixed on 21 October 2026. AI tools are already finding flaws in PHP, and the PHP team receives far more reports than before. PHP runs on a very large number of servers, with a great deal of application and plugin code on top of it. Flaws will also be found in newer code, Astro's included. What differs is how much code a visit runs.

We give no overall ranking. No single fact about what runs on a server settles one, and every site depends on its accounts. A WordPress site has a database and plugins besides WordPress itself, and WordPress.org tells its owners to keep WordPress and the plugins up to date. A Croftweaver site has build tools to keep up to date. The sections below set out the differences, each with its source or a check you can run, and what stays with you. For why owners leave WordPress, with figures, see From WordPress to Astro.

What this rests on

News · dated 21 and 22 October 2026 · to be updated or removed

The PHP alert of 21 October 2026

On 21 October 2026 the US cyber agency CISA urged organizations to patch two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619, nicknamed “php2shell”. This is what the sources say. We give each report to the source that made it.

What CISA said
Patch at once. The flaws allow remote code execution without a login and affect all PHP installations serving web requests. Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. CISA alert, read
The alert names PHP and no other product. CISA alert, read
Who is affected
All PHP installations serving web requests, php.net says, among them PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It sees the risk as highest for mod_php. php.net advisory, read
The two flaws
CVE-2026-109618, “RCE via OOM corruption”: rated critical, published on 21 October 2026, fixed in 8.2.35, 8.3.36, 8.4.27 and 8.5.12. GitHub advisory GHSA-w8hw-w9fx-j79w, read
CVE-2026-109619, “RCE via stale global state”: rated critical, published on 21 October 2026, fixed in the same four versions. GitHub advisory GHSA-6wmf-4rv5-p3rp, read
Reported by
Calif, OpenAI and Wiz Research told the PHP project about the flaws in August 2026, the PHP Foundation writes. PHP Foundation, read
Older versions
PHP 8.1 and older no longer receive updates from the PHP project. Its security team published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and long-term-support vendors provide backported fixes. php.net advisory, read
Attacks?

The reports differ, and some are older than others.

  • CISA had not observed exploitation when it published its alert. CISA alert, read
  • Cloudflare's chief technology officer said the same day that Cloudflare was seeing early attacks emerging, and called its firewall rules a stopgap. The Hacker News; Krebs on Security; The Record, read
  • The security firm watchTowr reported “active exploitation attempts” later the same day, after reporting none earlier. Its head of threat intelligence told The Record that nobody had been successful so far. The Hacker News; The Record, read
  • Krebs on Security wrote that experts say working exploits exist and that the flaws are already being exploited in the wild. Krebs on Security, read
  • As of its update of 21 October 2026, The Hacker News wrote that no source had reported a confirmed break-in of a specific server. The Hacker News, read
Offline as a precaution
Several governments, and some companies, took services offline for a while before patching. Malwarebytes points out that downtime alone does not mean a site was broken into. The Record; The Hacker News; The National; Malwarebytes, read

The flaw sits in PHP itself

The people who found the flaws showed them working. Wiz Research ran code without a login on the latest container images of PHP applications such as Drupal, Joomla and WordPress. It says the flaws are in PHP itself and that exploitation does not depend on a flaw in the application's code. Wiz Research, read

Calif says it confirmed code execution without a login on PHP applications such as Drupal, Joomla, Laravel, Magento, MediaWiki, Nextcloud, phpMyAdmin, Roundcube, Symfony, WHMCS and WordPress. Calif, read

These were demonstrations by the people who found the flaws. They are not reports of sites that were hit. Running on PHP does not show that a given site was attacked or is exposed today. Exposure depends on its PHP version and on whether its host has patched.

What we did not check about the alert: whether a given host has patched its PHP; which sites were broken into, and whether any WordPress site was; the names in lists of outages that circulated, which we could not confirm; and OpenAI's own post about the flaws, which our tools could not open.

What runs when someone opens a page

Code that runs on every visit is code that a visitor's request can reach. This is what runs, step by step.

A WordPress site, for a request that no page cache answers

  1. VisitorThe browser asks the server for the page.
  2. Runs codePHP starts.
  3. Runs codeWordPress runs.
  4. Runs codeThe plugins run.
  5. Runs codeThe database answers.
  6. VisitorThe finished page goes back.

A Croftweaver site

  1. VisitorThe browser asks for the page.
  2. Runs codeAccording to Cloudflare's documentation, one short function of the site runs on each request. On croftweaver.com it passes the request on unchanged.
  3. No codeCloudflare hands back a file that was built in advance.
  4. VisitorThe page arrives.

“Runs code” means code that belongs to the site and runs on a server for each visit. Cloudflare's own network software runs in every case. A response that a page cache serves before PHP runs does not run PHP. Each step carries a label as well as a colour.

Side by side

Area A WordPress site A Croftweaver site
Code that runs for a visit PHP, WordPress and its plugins, except for a response that a page cache serves before PHP runs. croftweaver.com: one function. The template: two.
Where the content is kept In a database, MariaDB or MySQL. As files in a Git repository.
A login on the site An administration area at /wp-admin/, with a login screen. No page named admin or login on croftweaver.com. The pages change when someone edits the files and publishes.
What needs updates WordPress, its plugins, and PHP. The packages that build the site (see the checklist). Not PHP.

The sources for the table:

What Cloudflare handles

A Croftweaver site is served by Cloudflare Pages. These are statements from Cloudflare's own documentation, each with its page and the date the page was last updated. What Cloudflare does is Cloudflare's to promise. This page repeats what it says, and says nothing where the documentation is silent.

What Croftweaver sets up, and what stays yours

Set up by the template

  • Security headers on every page, in public/_headers: a ban on sniffing content types, a referrer policy, a ban on framing, a permissions policy and a content security policy. the template at 3b8a6c5f, read
  • We call these headers set, and we do not say they protect the site. A header asks the browser to behave. It does nothing against an attack on a server.
  • croftweaver.com keeps the same five headers in its own public/_headers (its content security policy also names its analytics host). public/_headers, lines 7 to 12, read
  • croftweaver.com uses Plausible Analytics, not Cloudflare's analytics. Its home page loads one script from outside the site, the Plausible script from analytics.m-squad.com, and no Cloudflare analytics beacon. Command: curl -s https://croftweaver.com/ | grep -o -E '<script[^>]*src="[^"]*"'; curl -s https://croftweaver.com/ | grep -c -i -E 'cloudflareinsights|beacon.min.js'; curl -s "$(curl -s https://croftweaver.com/ | grep -o -E 'https://analytics[^"]*[.]js')" | grep -o 'window.plausible.init' | sort -u, run

Offered by the toolkit's launch steps

  • The toolkit's script cloudflare-setup.mjs sets Always Use HTTPS, a minimum TLS version of 1.2, Email Address Obfuscation off, Network Error Logging off, Bot Fight Mode off and AI crawler blocking off, through Cloudflare's API and one short-lived token. It asks the owner to confirm before it changes anything, and it does not set HSTS. the toolkit script cloudflare-setup.mjs at 3b8a6c5f, read
  • A step in the toolkit's launch checklist switches on Dependabot security updates for the site's repository. the toolkit launch checklist at 3b8a6c5f, read

Stays yours

  • The Cloudflare, GitHub and domain registrar accounts: two-step sign-in, who has access, and who may publish.
  • On croftweaver.com, npm run ship publishes the main branch to production, the live site. AGENTS.md, lines 139 to 145, read
  • The rule in AGENTS.md is that only the owner publishes live. AGENTS.md, line 201, read
  • The domain's DNS records and its renewal date.
  • HSTS, which tells browsers to use HTTPS only, is a Cloudflare dashboard switch and is not in public/_headers. On croftweaver.com it has been on since 12 October 2026, for six months, subdomains included. README.md, lines 216 to 222, read
  • Other dashboard values on croftweaver.com, as the README records them after reading Cloudflare's API on 13 October 2026: Always Use HTTPS on, a minimum TLS version of 1.2, a rule that removes the NEL headers, and Bot Fight Mode off. README.md, lines 216 to 222, read
  • The README records that CANONICAL_URL has been set in Cloudflare since 12 October 2026, so that the pages.dev address sends visitors to the live domain. README.md, lines 11 to 14, read
  • The template sets up none of DNSSEC, CAA records and a security.txt file: it holds no security.txt file, and DNS records are the owner's. the template at 3b8a6c5f, read
  • The result for croftweaver.com shows where it stands on those three.
  • Optional add-ons, such as a form service, analytics or an editing tool. Each adds code or a login, and its own updates.

A checklist for any website

These seven points apply whatever software runs your site. They are listed by what costs most when it goes wrong. In our judgment the first two matter far more than the rest. Where a Croftweaver site differs, the point says so.

  1. Lock the accounts that can publish

    GitHub, Cloudflare and your domain registrar. Use two-step sign-in, best with a passkey or a hardware key. Remove people who left. Give access tokens the narrowest scope that works. Whoever can log in to these can change what your site says. A WordPress site has the same kinds of accounts, plus its own administration login.

  2. Know who can publish

    List every person, script and AI assistant that can push to the production branch, and what happens when one does. With one owner this list is short. With a team it needs a rule.

  3. Turn on security updates for everything your site runs

    On a Croftweaver site that means the build tools. Switch on Dependabot security updates, then merge the fix once the tests pass. Your site keeps its own lockfile, so no Croftweaver release patches it for you. Once a month, run npm audit and read what it says. On a PHP site it means PHP itself, the system and its plugins. For croftweaver.com on 22 October 2026:

    • The audit lists no known flaws. Command: npm audit, run
    • Four of the eight direct packages were behind the latest version. Two were a patch step behind: @astrojs/check and astro. Two were at least a major version behind: TypeScript 6 to 7, and @types/node 24 to 26. All of them are used to build and test the site. Command: npm outdated, run
    • The toolkit's own Dependabot file for the Astro starter ignores major updates of @types/node, which follows the Node major, and of typescript, because @astrojs/check 0.9.x does not accept version 7 yet. The file says so in comments. the toolkit Dependabot file at 3b8a6c5f, read
    • The lockfile last changed on 22 October 2026, when Dependabot updated six packages. Command: git log -1 --format='%cI %s' -- package-lock.json, run
    • Dependabot alerts and security updates are on for the repository (the command needs access to its settings). Command: gh api repos/karero/croftweaver-site --jq .security_and_analysis.dependabot_security_updates.status; gh api -i repos/karero/croftweaver-site/vulnerability-alerts | head -1, run
    • The repository also has a Dependabot file that asks for version updates once a month: one grouped pull request for the minor and patch steps of the npm packages, with no major updates of @types/node or typescript, and one grouped pull request for GitHub Actions updates. the Dependabot file of croftweaver-site at 9b38eda, read

  4. Watch the domain

    The renewal date, auto-renew and the registrar lock. Remove DNS records that point at services you no longer use. Set up SPF, DKIM and DMARC, so that receiving mail servers can check that mail from your domain is real.

    • croftweaver.com is registered until 7 October 2028. Command: whois croftweaver.com | grep -i 'registry expiry', run

  5. Keep the optional parts few

    A contact form, an editing tool or a third-party script each adds code or a login. Add one for a reason, and read again what it sends and where.

  6. Check the live headers after a change

    Security headers sit in public/_headers, but the live site is what counts. The four checks include the command.

  7. Keep private files out of the public folder

    Almost everything in the public folder is on the internet. On a Croftweaver site that folder is public/. Drafts, price lists and exports are public too, if you put them there.

If you stop updating

The site keeps serving. Your pages are files, and Cloudflare renews the HTTPS certificate (see what Cloudflare handles). What changes is what piles up behind the scenes.

A routine that covers most of it is short. Once a month, merge the security pull requests and run npm audit. Once a year, reread the figures on each page and check the renewal date of the domain.

Four checks you can run yourself

Each needs a terminal and no account. The next section gives the result for croftweaver.com.

  1. The response headers

    curl -sI https://croftweaver.com/

    Expect lines for strict-transport-security, content-security-policy, x-content-type-options, x-frame-options, referrer-policy and permissions-policy.

  2. DNSSEC

    dig +short DS croftweaver.com

    Expect a line of numbers and a long string of letters and digits if DNSSEC is on, and nothing if it is off.

    Cloudflare says DNSSEC adds an extra layer of authentication to DNS, so that requests are not routed to a spoofed domain, and that it adds the needed record itself for domains registered with Cloudflare. Cloudflare docs, DNSSEC (updated 24 June 2026), read

  3. CAA records (optional)

    dig +short CAA croftweaver.com

    Nothing is fine. If lines appear, they name the certificate authorities that may issue certificates for the domain.

    Cloudflare says a CAA record states which certificate authorities may issue certificates for a domain, and warns that a record which does not allow Cloudflare can cause trouble when you add a custom domain to Pages. Cloudflare docs, CAA records (updated 21 April 2026); Pages custom domains, known issues (updated 21 April 2026), read

  4. security.txt

    curl -s https://croftweaver.com/.well-known/security.txt

    Expect a short text file with a Contact line, an Expires date in the future and a Canonical line.

    RFC 9116 asks a site to publish this file at /.well-known/security.txt, so that someone who finds a problem knows where to send it. Contact and Expires are required. RFC 9116, read

The result for croftweaver.com

One row per check, as seen from outside on the date shown. A check that fails is listed as failing. We update this table by hand when a check changes.

Check Result, and how to run the check
Security headers Pass. All five headers from the template are sent, and so is HSTS, which is a Cloudflare setting. Command: curl -sI https://croftweaver.com/, run
DNSSEC Pass. The answer holds a key tag and algorithm 13, so DNSSEC is on for croftweaver.com. Command: dig +short DS croftweaver.com, run
CAA records Not set. CAA is optional, and a wrong record can stop a certificate from being issued. Command: dig +short CAA croftweaver.com, run
security.txt Pass. The file is served, and it holds a Contact and an Expires date. Command: curl -s https://croftweaver.com/.well-known/security.txt, run

What can still go wrong with a static website

A Croftweaver page is built in advance and served as a file. The only server-side code that runs for a visit is one short function on Cloudflare's platform (see what runs). Scripts that run in the visitor's browser are another way in, covered under A script from someone else below. So the ways into a static site are mostly about access: the accounts that can publish it, the DNS records that point to it, the build that makes it, and the scripts its pages load from elsewhere. We found no source that says whether static sites are taken over more or less often than other sites, and we make no claim about that. We also do not claim that a flaw in Astro or in its packages cannot reach a static site.

A DNS or registrar account

Whoever can change your DNS records can send your visitors, and your mail, somewhere else.

  • CISA described the attack on DNS accounts: the attacker takes over an account that can change DNS records, points records such as A, MX or NS at addresses the attacker controls, and can then obtain valid certificates for the domain, so visitors see no warning. CISA, Emergency Directive 19-01 (22 January 2019), read

A left-over DNS record

A record that still points at a service you stopped using can be claimed by someone else. Remove the record when you remove the service, and avoid wildcard records.

  • GitHub says a domain takeover can happen when a repository is deleted, a billing plan is downgraded or another change unlinks the custom domain, while the domain stays configured for GitHub Pages. GitHub Docs, verifying a custom domain for Pages, read
  • GitHub advises against wildcard DNS records, because they put a domain at immediate risk of takeover even when it is verified. GitHub Docs, verifying a custom domain for Pages, read
  • Cloudflare's Pages documentation says that detaching a custom domain from a project means changing the zone's DNS records: delete the project's CNAME record, then remove the domain from the project. Cloudflare docs, Pages custom domains, read
  • In February 2024 The Hacker News reported research by Guardio Labs: more than 8,000 domains and 13,000 subdomains of well-known brands had been hijacked since at least September 2022. The Hacker News, on Guardio Labs research, read
  • In the one example the report examines, a subdomain's DNS record still pointed at another domain, so the subdomain inherited that domain's email policy. The Hacker News, on Guardio Labs research, read

A build step or a token

The build can run other people's code with your secrets within reach. The npm warning under where this advice runs out is another case.

  • In March 2025 CISA warned that the GitHub Action tj-actions/changed-files had been compromised and could disclose secrets such as access keys, GitHub tokens, npm tokens and private RSA keys; version 46.0.1 fixed it. CISA alert, 18 March 2025, read

A script from someone else

A page that loads a script from another domain can run whatever that domain serves, on every visit. Check what your pages load, and remove what you do not need.

  • In June 2024 Sansec reported that a company had bought the polyfill.io domain and its GitHub account in February, that the domain then injected malware through sites that embedded it, and that more than 100,000 sites embedded it. Sansec, 25 June 2024, read

What an attacker does with it

Google defines hacked content and lists four kinds of it:

What it costs afterwards

The clean-up can take much longer than the break-in. Google wants the way in closed before it reviews a site, and a hijacked domain can end up on blocklists. We found no source for how long the web filters of companies take to forget such a domain.

From the owner of croftweaver.com, not independently checkable: a WordPress site of his was compromised. In March 2021 Google's Search Console emailed him that hacked content had been found on the site, and applied a manual action that warns visitors in search results. Hidden pages with spam titles had been added to the site, and spam mail pointed at them. He restored a backup to remove the pages, but the spammer got back in and put them up again; he believes the way in had not been closed. By his own recollection it took about two years until the domain was off the spam lists that companies use, and he cannot name a single list. Afterwards the site ran two WordPress security plugins, one paid and one free.

Restoring a backup can bring back the old files, and any flaw in them. Google's advice above is to fix what let the attacker in.

If it happens to you

  1. Verify the site in Google Search Console and read its Security Issues report.
  2. Clean the site, and close the way in before anything else: the attacker came through something.
  3. Put the clean site back online, then ask Google for a review.
  4. Look the domain up at check.spamhaus.org, Spamhaus's own checker.

How the risk compares with WordPress

Our judgment, not a measurement. On one question, how likely a break-in is to come through the site's own software, we think a typical WordPress site is exposed to much more than a Cloudflare and Astro site: a database and a public login, plugins, and thousands of new plugin flaws a year. We make no comparison for other PHP systems. The accounts, DNS records and scripts above reach both kinds of site, and we have no data on what a break-in costs or how long recovery takes on either. No source measures the difference, so we give no figure, and we still give no overall ranking.

What we know on each side:

The audit in the checklist checks the version the site runs; the advisory list covers all versions. A count of flaws in a whole ecosystem is not the exposure of one site, so we compare no counts with each other.

One roof

Shared ownership does not show that a site is safer, and we do not say so. It adds three separate points of failure under one roof. First, the owner says that for croftweaver.com the registrar, the DNS zone and the Pages project are in one Cloudflare account, so one stolen login would reach all three. Second, an outage or a policy change at Cloudflare could expose host, registrar and DNS to the same incident (see Cloudflare is a dependency). Third, Astro's full-time team now works for Cloudflare, so a compromise of Astro's release path could reach any site that builds with the compromised release, on any host, not one account.

Where this advice runs out

News · dated 21 October 2026 · to be updated or removed

If you run PHP anywhere

CISA's advice of 21 October 2026, in our words:

  • List every system that runs PHP. PHP is often a component of other software, so you may not see it.
  • Patch, internet-facing systems first. The fixed versions are in the panel above.
  • If you cannot patch at once, or you run PHP 8.1 or earlier, take the system offline until you can.
  • A web application firewall may give some protection meanwhile. It does not replace the patch.
  • Read the PHP project's security advisory for how to patch.
  • Watch for PHP worker processes that start a shell or download tools.
CISA alert, read

Updating WordPress or its plugins does not update PHP. The host, or whoever runs the server, does that. Malwarebytes; The Hacker News, read

How this page was checked

Each dated fact above carries its source and the day we read it. An AI assistant read each source directly on 22 and 23 October 2026, without a summary tool, and kept a log of what each one says. On 23 October it used a search tool only to find sources, never to read them. A test, tests/check_security_page.sh, checks that every registered claim has a source and a date and that the page shows what the data lists. It cannot check that a source says what the sentence says. Editorial review covers that, and everything on this page that is not a registered claim.

What we did not check here: whether the routes file of the live deployment leaves static files out of the function.

Report a security problem From WordPress to Astro