1. Home
  2. Insights
  3. Web Design

Web Design

The PHP security flaw that made headlines, and whether it's time to rebuild your website

By LAB Digital Creative ·

PHP is the programming language behind about 70% of websites, and on October 21 it made the headlines. The people who maintain it shipped emergency fixes for two critical security flaws. Every WordPress, Drupal and Joomla site runs on PHP, so there’s a good chance this one touches yours.

Here’s what happened, what you should do this week, and why we think it’s a good moment to ask a bigger question about your site.

What PHP is, and why this matters

PHP is the programming language that runs on your web server and builds each page when someone visits. WordPress is written in it. So are most plugins, themes and contact forms you’ve ever installed.

It’s everywhere. W3Techs puts PHP behind about 69% of websites whose server-side language is known. When PHP has a serious bug, a big slice of the internet has the same bug at the same time.

What the flaws do

The two flaws, CVE-2026-109618 and CVE-2026-109619, let someone with no login run their own code on your server. In security terms that’s “unauthenticated remote code execution,” and it’s about as bad as it gets. Both are rated 9.2 out of 10.

A few details make this one worse than usual:

  • It doesn’t depend on your site’s code. Wiz Research, the team that found the flaws, showed working attacks against WordPress, Drupal and Joomla, and said even a bare “Hello World” page on an affected version could be vulnerable. Keeping your plugins updated doesn’t help here. The problem is underneath them.
  • The bugs are old. Wiz says they’d been sitting in PHP for more than a decade. They used AI models to help find and test them, which is a sign of where security research is heading. The same tools that help researchers find old bugs faster are available to everyone else, too.
  • Attackers moved fast. Within a day of the announcement, Rapid7 reported multiple exploitation attempts, and watchTowr said its honeypots were already seeing attacks.

Two days later, PHP warned about a third issue, CVE-2026-115560. That one only affects sites with an unusual configuration, and PHP considers it unlikely to be a problem for most people, according to The Hacker News. It’s a reminder that one patch rarely ends the story.

What to do this week

You don’t need to touch code. You need two answers from whoever hosts your site.

Which version of PHP is my site running? The fixed versions are 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Anything older on those branches needs the update.

Has the server been patched and restarted? Good hosts move fast on something like this, but don’t assume. Ask, and get a yes in writing.

Version 7, 8.0 or 8.1 makes the conversation harder. Those versions are past end of life, so there’s no official PHP release for them, only limited fixes that your host or a support vendor would have to apply. Anything older than 7.4 has no fix at all, and the only option is upgrading. By W3Techs’ numbers, about a third of PHP websites are still on version 7 or older.

Is it time for a recode?

Patching fixes this bug. It doesn’t change the setup that keeps producing bugs like it.

A typical small business WordPress site has a server running PHP around the clock, a database, a theme, a page builder and a stack of plugins, each from a different developer on a different update schedule. Every one of them is something to patch. When PHP itself breaks, all of them are exposed at once.

That’s fine when someone is maintaining it carefully. It’s a problem when the site was built five years ago, the developer moved on, and the login hasn’t been touched since.

A rebuild is worth a serious look when:

  • your site is on PHP 7 or older and upgrading would break the theme or plugins
  • updates make you nervous because something always stops working
  • the site is slow on a phone and nobody can say exactly why
  • you avoid editing it because the builder is a maze
  • you’re paying for hosting, security plugins and maintenance on a site that doesn’t bring in calls

Two or three of those on one site usually means another patch is buying time, not fixing the problem.

Why we’re rebuilding our sites

We’re rebuilding all of our sites to be faster, more secure and easier to change, starting with our own.

The new LAB site is built as a static site. Every page is built ahead of time and served from a global network, so there’s no PHP running when you visit and no database for anyone to break into. A flaw like this can’t reach a server that doesn’t exist. Pages load fast because there’s nothing to assemble on the fly. Our team edits content in a visual editor, and every change is saved with a full history, so a bad edit is a click away from undone.

We’ll be honest about the trade-off. Static sites aren’t the right fit for everything. A store with thousands of products, a member login area or a heavily customized booking system may still belong on a traditional platform, kept patched and watched closely. Plenty of the WordPress sites we manage will stay WordPress for good reasons. The point is to choose the setup on purpose, not to keep it because that’s what got built in 2019.

Not sure where your site stands?

Send us your URL and we’ll check what it’s running on, how it’s hosted and how it’s holding up on speed and security. We’ll record a short video walking you through what we find, including whether a patch is enough or a rebuild makes more sense. No pressure either way.

Ask for a site review or call us at 901-522-5002.

Rather have someone just look at your site?

Send us the link and we'll tell you the first three things we'd fix.

Call 901-522-5002 Get started