Why are there more and more security holes? PHP2Shell, AI and what you can do

Why are there more and more security holes?

Yesterday I wrote about how I handled PHP2Shell on the websites I look after. It was a long day, but it ended well.

This post is about the bigger picture. PHP2Shell is not a one-off accident. It is the latest example of a trend that has picked up speed: more security holes than ever, flaws deep down in the building blocks everyone uses, and attacks that start before the fix is out. And in the middle of it all is AI, both with the people who find the flaws and with the people who exploit them.

What is a CVE?

A CVE is a reference number for a known security hole, for example CVE-2026-109618 for one of the PHP2Shell flaws. The number lets developers, hosting companies and security tools talk about the same flaw. On its own it says nothing about how dangerous the flaw is. The score (CVSS) does that, on a scale from 0 to 10. PHP2Shell scored 9.2.

PHP2Shell in brief

PHP2Shell is two flaws in PHP itself, the programming language behind WordPress, WooCommerce, Drupal, Joomla, Magento, Laravel and a huge number of other systems. According to W3Techs, around 69% of the websites where the server language can be seen run on PHP.

A few things make it stand out:

• The flaw had been in the code for more than ten years and works in the default configuration. You do not have to have done anything wrong to be vulnerable.
• It sits beneath everything the owner sees. The researchers showed they could take over servers running WordPress, Drupal, Joomla, Magento, Nextcloud and Laravel without logging in. Updating WordPress did not help. It was the engine underneath that had to be replaced.
• It was found with the help of AI. The security firm Calif writes openly that they used a language model as an "audit buddy" and built on a pattern the model helped them find. Wiz Research and OpenAI are also credited with the findings.
• The attacks started before the fix. The details leaked the day before, and Cloudflare saw the first attacks at 9:43 Danish time, around six hours before PHP released the fixed versions.

Sources disagree on how widespread exploitation is now. Amazon writes that it is being broadly exploited, while PHP's own security team had not seen working attack code when the fix came out. That does not change what you should do: update.

Not the first time

Critical flaws in building blocks that millions of systems stand on have become a regular pattern:

• Log4Shell (2021) in the Java library Log4j got the highest score, 10. The hard part was not fixing it, but finding out where the library was used at all.
• xz-utils (2024) was a backdoor someone had deliberately planted in a small compression library in Linux. It was found by chance, because a developer wondered why SSH logins used too much CPU.
• Next.js (March 2025) had a flaw that let attackers skip login checks on self-hosted sites.
• React Server Components (December 2025) also scored 10: code could be run on the server without logging in, and it affected Next.js among others.
• WordPress core (July 2026) got its own chain of flaws, called wp2shell, which gave full control of a site with no account and no plugins. It was also found with AI.
• PHP2Shell (October 2026) hit the language underneath it all.

What they have in common is that the flaws sit in layers that a website owner never sees and rarely knows they have.

Why are there more CVEs?

The numbers speak for themselves. Security researcher Jerry Gamblin counts the published CVEs every year:

So the first half of 2026 produced more CVEs than the whole of 2023. The US standards institute NIST, which runs the big vulnerability database (NVD), writes that submissions grew 263% from 2020 to 2025. It can no longer review them all and now prioritises the ones being exploited.

There are several reasons for the growth:

• More organisations can issue numbers. In 2025, 365 organisations could assign CVE numbers. Two of the biggest are Patchstack and Wordfence, both of which work with WordPress. Together they accounted for more than 10,000 CVEs in 2025, about one in five.
• The Linux kernel now assigns a number to almost every bug fix, including ones that can hardly be exploited.
• AI finds more flaws. Language models review code faster than people, and they find flaws that have sat untouched for years.
• More code is being written than ever, also with AI, and more code means more flaws.

But more CVEs does not mean the world has become correspondingly more dangerous. Only 8.3% of the CVEs in 2025 were critical. And of the 35,364 from the first half of 2026, only 85 have made it onto the US cyber agency (CISA) list of vulnerabilities that are actually being exploited. That is 0.24%.

So the problem is not that everything is dangerous. The problem is finding the few that are, in a pile that grows faster than anyone can read it.

The time from flaw to attack has disappeared

What has really changed is the pace.

• Google's security firm Mandiant estimates that flaws are on average exploited 7 days before the fix arrives. Attacks routinely start before there is a fix to install. A few years ago you had weeks.
• VulnCheck found that 29% of the vulnerabilities exploited in 2025 were exploited on or before the day the flaw was published.
• For WordPress it is even faster. Patchstack measured that the most exploited flaws are attacked a median of 5 hours after publication.

You used to be able to update once a month and be reasonably covered. Not any more.

WordPress: the problem is in the plugins

WordPress deserves its own chapter, because so many small businesses use it. Patchstack recorded 11,334 new vulnerabilities in the WordPress world in 2025, 42% more than the year before.

• 91% were in plugins, 9% in themes, and only 6 in WordPress itself.
• 46% had no fix when they were published.

Every plugin is a door that needs watching. And almost half the time there is no new lock to fit when the hole becomes known. 2026 then showed that even WordPress' own core and PHP underneath it can hit everyone at once.

AI: on both sides of the table

I use AI in my own work every day, and I see it as a tool that makes me faster and more thorough. But it is clear that the same tool is changing the security picture in both directions.

AI finds flaws people did not

Google has an AI agent, Big Sleep, which has found flaws in the SQLite database among others before attackers could use them. In the US defence competition AIxCC in 2025, AI systems found 54 of 63 planted flaws and fixed 43 of them, and at the same time found 18 real, unknown flaws. Anthropic, the company behind Claude, writes that its newest model has found thousands of serious flaws in operating systems and browsers. That is the company's own count, but the direction is clear.

The most interesting thing about PHP2Shell is a detail Calif shares itself: the same type of flaw was found in a review of PHP in 2024, but it was not fixed, because nobody could prove it could be exploited. With AI they could prove it. AI makes it cheaper to go from "this looks suspicious" to "here is an attack that works". That is good for the people fixing flaws. It is also good for the people who want to abuse them.

AI helps attackers

After wp2shell in WordPress, Calif built an extension of the attack that gave full control of the server. With an AI assistant it took less than an hour. According to them, that kind of work usually takes a few weeks.

Anthropic has described how a state-sponsored group used Claude in an espionage campaign against around 30 targets, where according to Anthropic the AI did 80 to 90% of the work. Google has seen the first malicious software that asks a language model for help while it runs. It was used by a Russian group against Ukraine.

AI also creates noise

Daniel Stenberg, who leads curl, one of the most widely used pieces of software in the world, closed its bug bounty programme in January 2026. It was flooded with AI-generated reports that sounded convincing but were wrong. The share of real bugs fell from above 15% to below 5%. And of the 1,061 vulnerabilities VulnCheck saw attributed to AI findings in the first half of 2026, only 14 have been exploited in practice.

AI writes flaws too

When AI writes code, it is not automatically secure. The security firm Veracode tested more than 100 language models in 2025, and 45% of the code failed their security tests. Bigger and newer models were no better. A research study showed that AI models sometimes invent names of software packages that do not exist, for the commercial models in at least 5% of cases. Attackers can exploit that by creating packages with exactly those names.

My view

I do not believe AI makes the world more or less secure by itself. It makes everything faster. Flaws are found faster, fixed faster and exploited faster. That rewards those who are quick to update, and punishes those who wait.

For my own work it means AI may write and suggest, but I am the one who reviews, tests and stands behind what ends up on a client's server. And that updates are not something you do when you happen to have time.

The law is catching up

The EU has adopted the Cyber Resilience Act. From 11 September 2026, manufacturers of software and digital products in the EU must report actively exploited vulnerabilities within 24 hours, and from December 2027 the rest of the product security rules apply. In Denmark, the NIS2 act came into force on 1 July 2025 and sets requirements for companies in a range of critical sectors.

The rules mainly hit manufacturers and larger companies. My assessment is that smaller businesses will feel them indirectly, when customers and partners start asking how they handle security and updates.

How to protect yourself

The good news is that what protects against PHP2Shell also protects against most other things. The Danish Agency for Civil Protection published nine national tips for small businesses this week (in Danish), and they match my own experience well. This is what I would recommend for a website:

1. Find out who updates what. WordPress, plugins, theme, PHP and the server are often updated by different people. On shared hosting, the hosting company updates PHP. If you have your own server, it is you or your developer.
2. Turn on automatic updates, and check that they run. It is no use having them switched on if they quietly fail. Someone has to look.
3. Run a PHP version that still gets fixes. PHP 8.1 and older got no fix for PHP2Shell.
4. Have fewer plugins. When 91% of the vulnerabilities are in plugins, every plugin you remove is one door less. Remove the ones you do not use, and choose ones that are maintained.
5. Take backups, and test that they can be restored. A backup that has never been tried is a hope, not a plan. Read my guide to backing up WordPress.
6. Use two-factor login on WordPress, hosting, domain and email. The US cyber agency CISA recommends it as one of the first steps.
7. Use a firewall (WAF) as an extra layer, not as a replacement for updates. It can buy time while you wait for a fix.
8. Monitor the site, so you notice if it goes down, changes or starts sending visitors on to strange sites.
9. Agree what happens when things go wrong. Who do you call, and who has access to what? It is much easier to agree on a Tuesday morning than on a Friday evening with a hacked site.

If you want to go deeper, I have collected eight points in a security baseline for small businesses.

Sources

• Calif: PHP2Shell, the researchers' own write-up
• Sansec: PHP2Shell, timeline and mitigation
• Tenable: frequently asked questions about PHP2Shell
• Jerry Gamblin: 2025 CVE Data Review and CVE Mid-Year 2026 Check-In
• NIST: NVD prioritises because of record CVE growth
• Mandiant: M-Trends 2026
• VulnCheck: State of Exploitation 2026 and first half of 2026
• Patchstack: State of WordPress Security in 2026
• Calif: wp2root, from wp2shell to full control
• Google: Big Sleep and SQLite
• DARPA: AIxCC results
• Anthropic: Project Glasswing and AI-orchestrated espionage campaign
• Google Threat Intelligence: threat actor use of AI
• Daniel Stenberg: the end of the curl bug bounty
• Veracode: security of AI-generated code
• Study: AI models inventing package names
• European Commission: Cyber Resilience Act
• Danish Agency for Digital Government: NIS2
• CISA: Cyber Essentials
• Sikkerdigital.dk: nine tips on digital security for small businesses (Danish)