PHP2Shell: check your website's PHP version this week

If your business website runs on WordPress, there’s a server update you need to confirm this week. It won’t show up in your WordPress dashboard as an update button, and nobody is going to email you about it unless your web company or host does.

What happened

On Oct 21, the PHP project released fixes for two critical security flaws, CVE-2026-109618 and CVE-2026-109619. They go by the name PHP2Shell. Both can let an attacker run their own code on a web server without logging in first, and the PHP project says every PHP installation that serves web pages is at risk (PHP security advisory).

PHP is the software on the server that runs WordPress, and a lot of other website software too. That’s why a WordPress update won’t fix this, and neither will updating your theme or plugins. The flaws are in PHP itself, so PHP is what has to be updated.

The fixed versions are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The PHP project isn’t releasing fixed versions of PHP 8.1 or older, though its security team did publish source-code patches for 7.4, 8.0 and 8.1. Some hosts and Linux vendors patch those older versions on their own, so an older number doesn’t always mean an unpatched server. It does mean you should ask.

How did they find this?

Part of this bug has been sitting in PHP for years. The PHP Foundation says a developer saw the first signs of the memory problem behind one of the flaws during a 2024 security audit, but nobody could show a real way to attack it, and the fix stalled (PHP Foundation).

This summer, three groups found their way to it. Ryan Austin at the security firm Calif reported it to PHP on Aug 11, and OpenAI’s Codex Security team reported the same root problem that same day. Wiz, another security firm, reported more ways in on Aug 24.

AI was part of the work, and each group describes it a little differently:

• OpenAI says Calif found a critical flaw using one of OpenAI’s AI models, as part of a program OpenAI runs to help get serious bugs found and fixed (OpenAI).
• Calif’s own write-up puts the weight on the researcher. Ryan Austin knew PHP’s history of memory bugs and had a hunch where to look. After the first find, the team had an AI model turn that pattern into a search, and the search turned up a second way in (Calif).
• Wiz says it found its first bug using its own research platform plus AI models from Google and OpenAI, and that the AI is what made building a working attack practical in hours (Wiz).

The fixes were written by PHP’s own developers. The PHP Foundation says it uses AI to help sort and check incoming reports, but a person makes every decision and works on every patch. The PHP advisory and the CISA alert don’t mention AI at all.

Is anyone using it yet?

As of its Oct 21 alert, CISA said it had not seen these flaws being exploited (CISA). When we checked on Oct 22, neither CVE was on CISA’s Known Exploited Vulnerabilities catalog, the list CISA keeps of flaws it knows attackers are using.

That doesn’t make it safe to wait. CISA still told organizations to patch right away. Cloudflare says it has already seen attack attempts aimed at its customers.

What does this mean for my WordPress website?

The researchers call this remote code execution, which means someone on the internet can make your server run their own commands. Wiz, one of the groups that found it, says a successful attack could let someone take control of the server, steal sensitive data and deface the sites running on it. Wiz also showed it could read passwords and other private data out of the server’s memory without going that far. Cloudflare says the flaws can expose customer data or knock a site offline.

Here’s what that looks like in practice, based on what Google sees on hacked sites (Google Search Console Help):

• Pages get changed, or spam pages get added that you never wrote.
• Malicious code gets slipped into your pages and tries to attack the computers of people who visit.
• Google labels the site in search results with a warning like “This site may be hacked,” or the browser shows a warning page before anyone gets in.

CISA also tells server owners to watch for PHP downloading tools or opening a command line on its own, which can be a sign someone has gotten in.

For a business, the damage is mostly about people. A customer in Peru who searches your name and sees a hacked warning will probably call someone else. A visitor who gets bounced to a scam page won’t trust your site again. Google’s warning stays until the site is cleaned up and Google sees the fix, so cleanup takes real time, and it’s time you’re not spending on the business. If customer information was on that server, like form messages or account logins, you’ll also need to work out what was exposed and who needs to know.

How to check your site

1. Find your PHP version. In WordPress, go to Tools > Site Health, open the Info tab and expand the Server section. The PHP version is listed there (WordPress.org).
2. Compare it to the fixed versions above. If it matches one of them or is newer in the same line, you’re on a fixed release.
3. If it doesn’t match, or you can’t get into your dashboard, ask whoever runs your server whether PHP has been updated or patched for CVE-2026-109618 and CVE-2026-109619. That might be your host, your web company, or the person who built the site years ago. Write down who you asked and what they said.
4. If they can’t update it soon, ask about taking the site offline until it’s patched. That’s CISA’s advice for systems that can’t be updated right away.

If the site does have to go dark for a day or two, Google’s guidance is to keep a full shutdown short, a few days at most, because pulling a whole site can take a while to recover from in Search (Google Search Central).