← All blog posts

The Bug Was Old, the Speed Is New: The Recent PHP Vulnerabilities and the Part AI Played

· By The Better Website Guy

Diagram on a blue-to-tan gradient headed "The bug was old. The speed is new.", under a kicker reading PHP2SHELL, EXPLAINED and the line "A decade-old flaw in PHP, found with AI, attacked within minutes." A white panel below holds a four-step timeline: August, two teams find it, both using AI; Oct 17, first attack, four days early; Oct 21, PHP ships emergency patches; 45 min, tens of thousands of attempts. The second and fourth steps are marked in red. A white strip along the bottom reads: Fewer moving parts behind your site means fewer doors to try.

On October 21, 2026, the PHP project shipped emergency fixes for two flaws in PHP itself, the language that runs most of the websites on the internet. Within hours, attackers were trying them at scale. The flaws had been sitting in PHP's code for over a decade, and they were found this summer with the help of AI.

That combination is why this one is worth understanding even if you have never thought about what your website runs on. Here is what happened, the part AI played, and what is changing for everybody who builds and looks after websites.

Skip to the AI stuff

What is PHP2Shell?

PHP2Shell is the nickname for two critical vulnerabilities in the PHP language, CVE-2026-109618 and CVE-2026-109619, that let an attacker run their own code on a server running PHP with a single crafted request and no password. PHP patched both on October 21, 2026. They are bugs in PHP's core engine, not in any plugin or theme, so they reach WordPress, Drupal, Joomla and almost any other PHP website.

PHP2Shell at a glance:

PHP runs roughly 70% of the websites whose server language is known, according to W3Techs, which is why researchers described the exposure as most of the web.

How does the PHP2Shell vulnerability work?

PHP2Shell works by breaking how PHP cleans up after a request fails partway through, particularly when it runs out of memory. Wiz, one of the firms that found it, describes all of the bugs as memory-safety problems in that error handling. In the right conditions, PHP ends up trusting memory it has already released, and an attacker can steer what is in it.

The unusual part is that it does not depend on anything the website itself does. In Wiz's words, "even a simple 'Hello World' application running on an affected PHP version can be vulnerable." Researchers demonstrated working attacks against both WordPress and Drupal. A carefully built site on an affected version of PHP was exactly as exposed as a careless one.

Which PHP versions are affected by PHP2Shell?

Every PHP version from 5.4 up to the October 21 releases is affected by at least one of the PHP2Shell bugs, and only 8.2 through 8.5 received official fixed releases. According to Tenable's summary of PHP's advisories:

Updating is the only complete fix. Configuration workarounds are circulating, and PHP's own security team says they do not make an installation safe.

When was PHP2Shell found, patched and exploited?

PHP2Shell was found in August 2026, attacked as early as October 17, and patched on October 21, a day ahead of schedule because details had leaked. The full timeline:

What is CVE-2026-115560?

CVE-2026-115560 is a third PHP vulnerability, announced October 23, 2026, that PHP considers an unlikely risk because it only affects applications configured in an unusual way. According to The Hacker News, it needs a site to change its session serialization setting while running, which few sites do. No attacks have been reported. PHP is fixing it in its next regular release rather than an emergency one, and recommends setting session.upload_progress.enabled=0 until then.

How was AI used to find PHP2Shell?

Both teams that found PHP2Shell used AI models to find the flaws and turn them into working attacks, compressing months of expert work into days. The code had been in PHP for over a decade. A limited version of the problem was even spotted in 2024 and judged not to matter.

Calif, a security firm working with OpenAI, found the first problem in early August using OpenAI's GPT-5.6 Sol. Wiz found it independently on August 19, using Google's Gemini 4 Argon alongside GPT-5.6 Sol and its own tools, and had confirmed working attacks against Drupal and WordPress within two days. Wiz's account of what that was like: a single researcher "completed in a week what previously would have taken a world-class team months of work."

It was not a one-off. In July, a pair of flaws in WordPress itself (nicknamed wp2shell) let anyone take over a default WordPress install. According to The Hacker News, Searchlight Cyber found that chain using GPT-5.6 Sol in a little over ten hours. WordPress patched it on July 17, and by early on the 18th it was being used against real sites. A security firm testing it afterwards said AI made reproducing the bug and building a working attack "trivial."

Wiz summed it up better than I can: "The vulnerable code had been there for more than a decade. What AI changed was the ability to understand the weaknesses and turn them into a working exploit."

If researchers found PHP2Shell first, how did attackers use it?

Attackers mostly used PHP2Shell after it was fixed, against servers that had not installed the fix yet. Finding a flaw first is not the same as everybody being protected from it. PHP is open source, so the moment the fix was released, the exact code that changed was public, and comparing the old version with the new one shows anyone what was broken. A fix is a bit like a recall notice for a lock: it protects the people who act on it, and it tells everyone else which locks to try. Automated tools then sweep the internet for servers still running the old version, which is what Cloudflare was seeing within 45 minutes.

A few attempts came earlier than that. The vulnerability IDs leaked on October 20, and nobody has said publicly how the attacker behind the October 17 attempt knew. A leak is one possibility. Another is that somebody else found the same flaw on their own, the way two teams already had, weeks apart, with tools anyone can use. How that whole path works, from a private report to an internet-wide sweep, is in zero-day vs n-day.

How is AI changing website security?

AI is making serious vulnerabilities cheaper to find, faster to exploit, and worth aiming at small websites. It cuts both ways. The researchers who used AI to find PHP2Shell reported it, which is the only reason a fix exists, and OpenAI coordinated PHP's maintainers, the research teams, Cloudflare and US government agencies to get the patch out. Wiz says the same AI tools helped it detect attacks and check that the patch worked. But OpenAI was also direct about the other side: the same capability "can also help attackers rapidly develop offensive tools and exploits." What has changed is not who is good at this. It is how much it costs.

Three changes, as far as I can see, and none of them are going back.

Finding serious bugs is getting cheaper. Work that took a skilled team months now takes one person days, and in the WordPress case, hours. There is a lot of old code on the internet that has never had that kind of attention, so it is reasonable to expect more announcements like this one, not fewer.

The gap between a fix and an attack is shrinking. Patchstack, which tracks WordPress security, looked at last year's most heavily exploited WordPress flaws and found a median of five hours between a flaw going public and attacks at scale. With PHP2Shell it was closer to minutes, and some attempts came before the patch existed. A published fix also tells everyone exactly where to look.

Small sites are no longer too small to bother with. When a serious attack took months to build, it was aimed at banks and governments. When it takes an afternoon, it gets pointed at every server on the internet at once, automatically. Nobody picks out a bakery's website. It is just on the list with everything else.

Can developers keep up with AI-found vulnerabilities?

Honestly, nobody knows yet, and I am not sure. The process the web relies on assumes there is time: a researcher finds a bug, reports it privately, the maintainers fix it, hosts roll it out, and site owners update over the following days or weeks. PHP2Shell went from a leaked ID to millions of attack attempts in about a day. Projects like PHP are looked after by teams that are small next to how much of the web depends on them, and every faster discovery lands on the same people.

Here is what does seem to work, from what I have seen this year:

None of those is a full answer. Together they are probably what keeping up looks like now: less reliance on someone remembering to do it, and less to remember.

How do I check if my website is affected by PHP2Shell?

Check which PHP version your site runs and confirm with your host that it has been updated. No code needed, and most of it is one email.

One. Find out which PHP version you are on. On WordPress, go to Tools, then Site Health, then the Info tab, and open the Server section. If the PHP version starts with 5, or with 7.0 through 7.3, that is the urgent case: there is no patch for those, and the fix is moving to a supported version.

Two. Ask your host, in writing, whether they have patched. Most managed and shared hosts run PHP for you and will have updated already. Ask anyway: "Has the PHP on my site been updated for CVE-2026-109618 and CVE-2026-109619?" A good host answers that in one line.

Three. Update everything else while you are there. WordPress core, plugins and theme, then delete any plugin that is deactivated rather than leaving it installed. The WordPress post walks through that inventory step by step.

Four. If your site was unpatched from October 17 on, ask whether anyone has looked. Amazon's advice is to start any investigation from October 17, not from the announcement. Admin accounts nobody created, plugins nobody installed, and files that changed when nobody was working on the site are the usual signs.

Is WordPress affected by PHP2Shell?

Yes. WordPress runs on PHP, so every WordPress site on an unpatched PHP version was exposed, and the fix is updating PHP rather than WordPress. Researchers demonstrated full takeovers of WordPress through PHP2Shell.

That is not an argument against WordPress. I build custom WordPress themes when a business needs one, and a WordPress site I built would have needed this patch too, because the flaw was in PHP, not in anyone's theme. If a site needs WordPress, it needs somebody who makes sure it is updated within hours, not weeks. That was always part of the deal. This month just made it visible.

Are static or hand-coded websites affected by PHP2Shell?

No. A website that does not run PHP on its server cannot be attacked through PHP2Shell. This site is an example: it is plain HTML, CSS and JavaScript files. When you visit a page, the server hands you a file that was written in advance, so there is no program running for each visitor that a bad request could break. The contact form is one small function on Cloudflare. That is the "less to patch" point above, in practice, and it is why most of the sites I build start that way. The longer version is in the hand-coded websites post.

It is not hack-proof, and I would not want this read as a claim that it is. Hosting accounts, domain registrars and email are still ways in, and a weak password on any of them matters more than how the site is built. (If you are not sure your domain is in your name, the free websites post has a five-minute check.)

The takeaway

PHP2Shell was a decade-old flaw in the language that runs most of the web. AI helped researchers find it, the fix shipped on October 21, 2026, and attacks followed within minutes. The bug was old. The speed is new, and it applies to attackers and defenders alike.

The practical question for any website owner is the same one it always was, with a shorter deadline: what does my site run, who updates it, and how quickly? If you are not sure of the answers, send me a message and I will tell you what I see, including when your setup is fine as it is.

The Better Website Guy

Designer/developer behind The Better Website. Hand-codes every build himself: no templates, no page builders, no plugin stack.

Let's chat

← Back to the blog