PHP2Shell has brought web security back into focus. Understandably: two critical vulnerabilities have been patched in PHP, the language that underwrites WordPress and many other popular platforms. PHP is used by roughly 69% of websites whose server-side language can be identified. That’s a huge opportunity for bad actors.
You’re going to hear plenty of “glad I moved away from WordPress” and “this is why we build everything ourselves”.
There are a few things worth understanding before jumping to the conclusion that you need to rethink your business’ tech stack.
Attackers seek out the greatest ROI on their time.
If you’re trying to open a million doors, you don’t focus on a flaw in the key, you focus on a flaw in their shared locking mechanism. Dependencies that power solutions used by millions are battle hardened, but IF you can find a vulnerability, it’s Christmas.
A developer saying their custom CMS has never been hacked might be a quality indicator, sure. They might also have built something that hasn’t attracted much attention. “No known breaches” often means “untested”, not exceptionally secure, just not worth the man hours or the compute to try and exploit.
A smaller codebase can reduce the attack surface. But a bespoke system may also have fewer reviewers, fewer security audits, and (importantly) fewer people finding the solution when sh*t hits the fan.
And in this case, the vulnerabilities are in PHP itself. Researchers demonstrated attacks against WordPress, Drupal and Joomla, but even a simple application on an affected PHP deployment can be vulnerable. A custom CMS using PHP doesn’t escape the underlying problem.
AI changes the likelihood of finding these flaws.
Researchers used frontier models to help turn complex memory bugs into working exploits. These particular bugs followed a complex chain of events that would need a level of skill an understanding found in very few dev offices in the world. Claiming humans could never have found them goes too far; but these bugs were far from easy to spot. It’s like finding Wally (Waldo for the Yanks) if the page was the size of a billboard.
Capable open-weight AI models are also available for local deployment, widening access to sophisticated coding tools.
GLM-5.3-Flash is a natively multimodal open-weight model released on August 26, 2026. It features a 320B total parameter architecture with 18B active parameters per token: That’s comparable to the top models from Open AI and Anthropic as little as six months ago. The key difference is this model can run locally on a relatively mid-bench gaming PC, and already has ablated/uncensored models (which take off the guardrails), with hundreds of thousands of downloads. Models like this are a dream for hackers.
Meanwhile, AI is helping people ship software faster than they can assess its security.
“Build me a website with a login” leaves a lot unspecified: permissions, session handling, input validation, secret storage, rate limiting and monitoring. A working interface doesn’t tell you whether those foundations are solid. Research has repeatedly demonstrated security weaknesses in AI-generated code. That doesn’t make every AI-built site unsafe, or every WordPress site safe. It’s just another thing to consider when architecting your next project.
Established projects deserve scrutiny too. The PHP Foundation acknowledges that early signs of one underlying problem were identified in 2024, and that decision-making and resource shortages delayed a fix. Open-sourced software built on established codebases are battle hardened, but big ships turn slowly. Newer, or vibe-coded systems are simpler and less reliant on legacy, but also more likely to get the basics wrong. There’s risk and reward in both.
My expectation is that we’ll hear about more vulnerabilities as these tools improve. Familiar platforms will feature in those headlines because of their reach, and the widespread consequences when something goes wrong.
Website owners: DO THIS NOW.
Check with your host that the PHP security update has actually been applied. Updating WordPress alone won’t patch PHP. The upstream fixed releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12; distribution packages may carry backported fixes. PHP processes also need restarting after the update.
If you’re not a developer and your site uses WordPress, do this.
Go to your dashboard (sitename.com/wp-admin), open Site Health and scroll down to the Server toggle. Check that your PHP version is 8.3.36 or above. If you’re on an older version, assume you’re vulnerable and contact your webhost or website service.