What the PHP2Shell incident confirms about WordPress: Security needs to be part of the conversation

Why security needs to be part of the conversation

Throughout 2026, as I have transitioned more to using Astro and had a strong preference for that over WordPress, I've had a lot of discussions with people about the different merits of the systems. Essentially, I would always advocate for leaving WordPress.

Despite its attempts to keep up with the modern web era that we're in, even if it gets a similar workflow with AI or an output such as static, it's through a very convoluted setup. It's one with many pitfalls, as we have always known the WordPress ecosystem to have.

Something that occurred to me recently is that everybody tends to talk about the merits of the workflow, the output, the ecosystem and what functionality might be in place. But something that people really don't give more than perhaps a passing thought to is security.

We regard static sites as having a lot more security, simply because they don't have the attack surface that the WordPress system does, or that PHP and the retrieval of data from a database would have.

That's very interesting in light of the recent PHP issue that we've all faced. It obviously has to be said, first of all, that this isn't about WordPress specifically. It's about PHP, and WordPress just happens to run on PHP, as many other things do.

What would the client choose?

When we're considering what we're building a website with, we might think about the functionality, the availability of plugins or extensions, or whatever we could add to the site. We might think about client editing.

But if we take all of those things to the client and say we've considered these, and we haven't brought the consideration of security to the forefront, then we have a bit of an issue.

I know for a fact that most clients would choose the more secure system, despite a lot of them not choosing a maintenance plan, which is ridiculous. Still, if you said to a client:

“I've got two systems that I can build your website with. One of them has ongoing, daily security vulnerabilities that we are always going to have to monitor and respond to. The other one, once it's rendered and published online, is safe and secure, and you don't have to worry about that so much.”

Which one would the client choose?

Obviously, they would choose the more secure, less arduous system. That happens to be static or Astro, funnily enough, whereas WordPress has always had, and still does have, a ton of security vulnerabilities, whether at the level of the plugins, the core, the themes or, indeed, now in PHP.

Security during development and after publication

I'll just quickly say that this isn't to say there aren't security issues you can face in the Astro system. Obviously, you've got to know about supply chain vulnerabilities, what dependencies are there, and use only trusted sources. That's quite similar to using trusted plugins.

But the truth is that this is a development process. Security then comes into the development process, and that can be accounted for before the site goes to build. If you will, much of that risk really remains with the developer and their own setup.

Once the site is actually live on the internet, it poses no significant risk to either the client or their website users. This is something that really needs to be considered when deciding on the tech stack to use for a project.

All else being equal

Again, I'm going to state that there are many systems that have been compromised with this whole PHP scare. But it just so happens that WordPress and other systems rely on PHP, so the question does have to be brought to the forefront once again.

If everything else is equal, if you want to squabble about the ecosystem, if you want to debate the workflow and what WordPress is capable of against, for example, an Astro website, then just because of the presence of PHP, the runtime retrieval of data and the compilation of all the HTML, it's an inferior system.

Just because of the process that WordPress uses, it's a more risky system. It's a less secure system. It's something that's more prone to vulnerabilities being exploited, which can cause actual harm to a business or, indeed, a person.

Again, all else being deemed equal, developers might squabble about their preferences:

“I like to work in WordPress.”

“I like to work in Astro.”

“I like to use the WordPress ecosystem.”

“I'm happy to code it myself using AI.”

Whatever you want to argue about with those opposing values, when it comes down to the merits of security in the system those building processes are built upon, there is only one clear winner. This should most definitely be a significant factor in choosing your tech stack.

Is this a question of professional liability?

I should remind you that we are liable for what we produce at a professional level. Even if we hand a website over to somebody and say, “Go and have an independent security check,” and all of that, we are responsible for what we hand over.

If there was a breach that needed to be traced back to the website system, there could be a question nowadays:

“You could have done all of this with Astro, or even a static site, at no further expense to the client and with no compromise to the aesthetics or functionality. You could have done all of that. You chose WordPress, which is on an inferior and very vulnerable system. Why did you do that?”

Does the liability fall to you? I would argue that perhaps this is a question of professional liability.

The moment I decided to leave WordPress

Just to make this clear, I do want to say that, for a while, I was enjoying creating with Astro, vibe coding and static sites. But when I built and developed FEWD Studio, which is a desktop code editor with a heavy tilt towards Astro builds, I actually created the first website for it in Bricks, which is based on WordPress.

Although it actually amounted to nothing, I had a security scare on that site within the first couple of days due to the licensing process I was putting through. It happened to have been an empty warning, but it made me feel extremely vulnerable, and I had to put a couple of hours into investigating the issue.

This was the moment when I decided, “I am not working with WordPress anymore.”

I had also, in my day job in an agency environment, spent a lot of that week overcoming various security issues.

The thing is, I run a very tight ship in that web department. I am always proactive on security, as much as somebody can be and as much as my knowledge enables. Yet there are always moments when you have to tend to security and put all of your project work to the side.

After a week like that, and then thinking that my own site had become compromised, I decided this was reason enough to leave WordPress.

Months on, I haven't felt restricted

Now, months on, I've not felt restricted in what I can achieve in an Astro website or, indeed, a static site.

I now quite despise working with WordPress when I have to do that for other people's projects. It's slow, it's clunky and, like I've said before, it is inferior in terms of the workflow and security.

We're here in October 2026, and there have been months of continued WordPress core vulnerabilities and critical updates. WooCommerce as well. Breakdance has had some. I can't think of many plugins that haven't had significant issues, quite scary, critical, “you need to update now” issues.

Then we have the actual foundation that WordPress is built on having one of the biggest worldwide scares you can have.

I think the question has been answered. For security alone, you need to make a more informed and more professional decision about what you will use to build websites for yourself or your clients.

Actually, in some ways, it doesn't even have anything to do with yourself, professional liability or the clients. It has a lot to do with the responsibility we have for users who could find their own systems compromised because a website was built using a system that fares badly against other options.

Moving into the modern era of web development

I would like to end this on a high note.

I have created FEWD Studio, a desktop code editor that provides pagebuilder interface for static and Astro website coding. I've also created a CSS framework called GenCSS, and this whole article isn't something to just sway you towards those. You can use VS Code. You can use other CSS frameworks. I would just urge you to move into the Astro world.

If you are working with WordPress, Framer or Webflow, you're used to page builders, and the idea of coding is scary and a bit unfamiliar, I have a free front end web development course on YouTube that will get you started.

FEWD Studio has page builder elements, so you can visually create in an Astro environment. It helps you create the components visually. It's something you can transition to very easily from WordPress.

Added to that, I am this week starting up a community for those who want to transition into this modern era of web development.

I think it's exciting. I think there are lots of opportunities, and I would encourage you to read the room, be at the forefront of this new movement and enjoy it.

It does require a little bit of a learning curve, and I invite you to join me and the community as we embark upon that.

Learn Astro and leave Wordpress

Community is opening soon!  JOIN THE WAITING LIST!

https://getboosh.com/community