When a PHP vulnerability hits the news, WordPress sites scramble to patch. CodeCows sites don't. We don't use PHP, and that's not an oversight — it's a security decision.
What just happened
A critical PHP vulnerability was recently disclosed affecting WordPress and other PHP-based platforms. Attackers can exploit it to execute arbitrary code on the server, take over the site, and potentially access customer data. If your website runs on PHP, you need to patch immediately. If it doesn't, you don't.
Our stack: zero PHP
Every CodeCows site runs on a stack that contains exactly zero PHP files:
- Frontend: Static HTML, CSS, and vanilla JavaScript. No server-side rendering, no templates, no interpreters.
- Backend: Cloudflare Workers — JavaScript running at the edge, not on a shared server with a PHP interpreter.
- Database: Cloudflare D1, a managed SQLite database. not MySQL/PHP.
- Hosting: Cloudflare Pages, a static hosting platform that serves files directly from the edge network. No PHP runtime, no WordPress, no plugins.
That means the attack surface for PHP vulnerabilities is literally zero. There is no PHP interpreter to exploit, no WordPress core to patch, no plugins with vulnerabilities, no themes with backdoors, no wp-config.php to leak credentials.
Why most contractor sites use PHP (and why that's risky)
About 43% of all websites use WordPress, which runs on PHP. Most contractor websites are built this way because it's what most web designers know. and it's easy to set up. But PHP has been the source of some of the largest web vulnerabilities in history:
- PHP interpreter bugs — vulnerabilities in PHP itself, affecting every site that runs it
- WordPress core vulnerabilities — patched regularly, but you have to update
- Plugin vulnerabilities — the average WP site has 50+ plugins, each a potential entry point
- Theme backdoors — free themes often contain malicious code
- wp-config.php exposure — database credentials in a file that can be leaked
Every time a new PHP vulnerability is disclosed, every WordPress site owner has to: read the news, check if it affects them, find the patch, test the patch, deploy it, and hope they weren't already exploited. That's a weekly occurrence.
What we do instead
We skip the entire PHP problem by not using it. Our sites are:
- Static files served from the edge — HTML, CSS, and JS are pre-built and served from Cloudflare's global network. No server processes user input.
- Serverless functions for the booking system — the booking calendar talks to a Cloudflare Worker (JavaScript), which talks to a D1 database (SQLite). No PHP involved.
- No login system on the public site — the admin page is protected by a token, not a PHP session. No login forms to brute-force.
- No database credentials on the server — D1 is managed by Cloudflare, we never touch the database password.
What this means for your business
If you're on a CodeCows site and a PHP vulnerability hits the news:
- You do nothing. Your site is not affected.
- Your customers are safe. No data was exposed because there's no PHP to exploit.
- You don't lose uptime. No patching, no downtime, no emergency updates.
- You stay focused on your trade. While competitors are scrambling to patch their WordPress sites, you're out working.
The honest trade-off
PHP sites can do things we can't easily do: complex server-side rendering, user accounts with sessions, e-commerce with WooCommerce, dynamic content from a CMS. But contractor websites don't need any of that. A plumber's website needs: a homepage, service pages, a contact form, photos, and a way to book a call. That's all static content plus a simple form handler. PHP is overkill.
By choosing a simpler, PHP-free stack, we trade flexibility we don't need for security we do need. For a contractor, that's the right trade.
Want a site that's immune to PHP attacks?
Every site CodeCows builds is PHP-free by design. See pricing or book a call and your site will be live in 48 hours — with zero PHP files to hack.