Note · October 26, 2026
A PHP flaw took four sites offline. Here's how AI helped rebuild them safely.
A case study in security-first rebuilding. We retired four aging CMS sites and replaced them with static pages that have nothing to patch, working side by side with an AI assistant.
In October 2026 a serious vulnerability in PHP, the language behind most content management systems, gave us a decision to make about four of our own websites: ezNet Solutions, ZealLabs.ai, my personal site and our ministry’s site. All four ran on an older CMS with a stack of templates, plugins and extensions that each needed patching, and several no longer worked on current versions of PHP.
We took them offline. The question was what to put back.
The lesson wasn’t “patch faster”
It’s tempting to treat an incident like this as a patching problem. It isn’t, really. The risk came from running software with a public admin login that had to be kept up to date, forever, by a small team with other work to do. The lesson we took: don’t run what you don’t need.
None of these sites needs a database to show a page. So the new versions don’t have one.
What we built instead
- Static pages. Each site is now plain HTML, built ahead of time and served from Cloudflare’s network. There’s no server-side code, no login page and no database to attack.
- Content in plain files. Pages and notes like this one live as text files in version control. Every change is recorded and can be undone.
- Nothing to patch on the public site. When the next PHP flaw comes along, it won’t apply.
- Dynamic pieces only where they earn their place. The contact form is a small serverless function with spam protection. It has no admin screen and stores nothing.
- Email treated as sacred. Before touching anything, we exported every DNS record and compared the old and new settings line by line, so mail kept flowing the whole time.
How AI fit in
We did the rebuild in partnership with an AI coding assistant, and it’s a good example of what we teach in the Zeal AI CoLab: AI does the heavy lifting; people stay in the loop.
The assistant inventoried the old sites, separated real content from leftover template filler, wrote scripts to check every salvaged file for anything that wasn’t plain audio or text, compared hundreds of DNS records exactly, and drafted the new pages. I approved every step that touched email, DNS or anything going live. Nothing went public without a human looking at it first.
The result is four sites that are faster, cheaper to run and far harder to break into, rebuilt in days rather than months. That’s the “From Z to A” idea in practice: we didn’t ask how to patch the old setup; we asked what we’d build if we started from today’s tools, then worked backward.
If you run a small organization’s website
A few questions worth asking:
- Does your site actually need a database, or just pages and a contact form?
- Who patches your CMS, plugins and theme, and how quickly?
- Is there an admin login on the public internet? Does it use multi-factor authentication?
- If your site went down tomorrow, do you have a clean copy of your content and your DNS records?
If those questions make you uneasy, let’s talk.
