PHP2Shell: The Bugs That Gave the Web a Fright This October

Every Halloween has its monster, and this year's was living in the code behind millions of websites. In the third week of October, two serious flaws in PHP were made public, and attackers began trying them almost at once. Some governments took their own websites offline while they dealt with the risk.

If you own a website but have never logged into its server, this can sound like your developer's problem. It matters to you because PHP runs a large share of business websites, including every WordPress site, and your website carries your name. Below is what went wrong, in plain English, and how to make the next scare less painful.

What is PHP, and why does your website care?

PHP is a programming language that runs on a web server and builds each page at the moment a visitor asks for it. Each of those asks is called a request. Think of it as the kitchen behind a restaurant. Visitors only see the dining room, but every dish is cooked in the kitchen first.

According to W3Techs, PHP runs 69.2% of the websites whose server language it can identify, and WordPress, which is built on PHP, powers 39.6% of all websites.

On hosted website builders, the platform runs the server side for you. Webflow, for example, said in its Trust Center that its core services are not built on PHP and were not affected. On another hosted platform, check its status page.

What went wrong? PHP2Shell in plain English

PHP2Shell, a name coined by researchers at security company Wiz, covers two flaws in the core of PHP itself, so no plugin or theme is to blame. They affect PHP installations that serve web pages, from version 5.4, released in 2012, up to 8.5.11, unless a vendor has patched them.

Each flaw has an official ID, called a CVE number, and both score 9.2 out of 10, or critical, on CVSS, the industry's standard severity scale. Both allow what security people call unauthenticated remote code execution, which means a stranger with no login could make your server run their own commands.

CVE-2026-109618: the half-written ticket

Imagine the kitchen runs out of space on its order pad halfway through a very large order and abandons the ticket half-written. Later, the clean-up crew finds it and acts on it as if it were complete. PHP does something similar with memory. When it runs out of memory partway through a request, it can leave that request's data half-built, and its clean-up code may later treat the broken data as valid. An attacker can trigger this on purpose to slip in their own instructions.

CVE-2026-109619: the guest who never quite left

Now picture a hotel that doesn't fully reset rooms between guests. A note left by one guest is still on the desk when the next arrives, and staff treat it as an official instruction. PHP handles requests with workers, small programs that each serve many visitors one after another. With this flaw, data from one request can linger after PHP has thrown it out, and a later request on the same worker may use it. An attacker can be the guest who leaves the note.

A PHP core developer first spotted signs of the out-of-memory flaw in 2024, while fixing an issue from PHP's first external security audit. This year, security firm Calif found a flaw using an OpenAI model, through OpenAI's Patch the Planet programme, and Wiz found the same kind of bug independently.

How much damage could PHP2Shell do?

What has happened so far

Amazon's honeypots, decoy servers that record attacks, logged an attempt on 17 October, four days before the announcement. Details leaked online on 20 October, two days before the planned disclosure, and PHP released its fix early, on 21 October. Cloudflare then saw tens of thousands of attack attempts within 45 minutes and millions by early on 22 October.

Palo Alto Networks' Unit 42 counted over 22.6 million internet-facing PHP installations that are potentially vulnerable. Cyber agencies in the US, UK, EU, Canada, Australia and Japan urged organisations to patch, and the FBI and NSA advised taking systems offline if they could not be updated promptly.

As of 22 October, agencies in Germany, the Netherlands and Japan had confirmed no successful break-ins. Then on 26 October, the US Cybersecurity and Infrastructure Security Agency (CISA) added both flaws to its Known Exploited Vulnerabilities catalogue, its list of flaws with evidence of active exploitation.

What could happen to an unpatched site

An attacker who can run commands on your server can do almost anything your website can do, including:

• customer details or form submissions copied and leaked

• pages defaced or quietly filled with spam

• malware or scam redirects served to your visitors

• browser warnings, or a "This site may be hacked" label in Google that costs you search visitors until the site is cleaned and reviewed

• downtime, plus the cost of a professional clean-up

What fixed it, and why isn't patching the end of the story?

PHP's maintainers released fixed versions on 21 October 2026: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The official PHP advisory says updating is the only complete fix, and PHP needs restarting before the update takes effect.

PHP 8.1 and earlier are end of life, meaning PHP no longer releases updates for them. It shared basic code patches for 7.4 to 8.1, which a developer has to apply by hand, and some hosts ship their own fixes, but the safest answer is a supported version. PHP 8.2 reaches end of life on 31 December 2026, so aim for 8.3 or newer.

For servers that cannot update straight away, PHP published temporary settings changes that reduce exposure but, in its words, "do not make an installation safe". Cloudflare and Google Cloud added rules to their web application firewalls, filters that block suspicious requests before they reach a site, which buys time for sites that use those services.

A third flaw, CVE-2026-115560, followed on 23 October. It only affects an unusual set-up for sessions, the way a site remembers a visitor between pages. PHP rates it an unlikely risk and will fix it in a routine release, and no attacks have been reported.

A patch closes the door, but it can't tell you whether someone walked in while it was open. The UK's National Cyber Security Centre advises looking for backdoors, which are hidden ways back in that an attacker leaves behind. The earliest recorded attempt was on 17 October, before any fix existed, so ask whoever runs your server to check any site that ran an affected version.

Haunt-proofing your site: how do you build for the next one?

There will be a next one. No habit makes a website unhackable, but these make a scare like PHP2Shell far easier to handle. Our post-launch website checklist covers the wider routine.

Run supported versions only. Every layer of your site, from PHP to your content management system (CMS) and its plugins, should still receive security updates.

Choose hosting that patches for you. Some hosts update PHP for you and others leave it to you, so ask which applies to your plan, and how quickly the PHP2Shell fix went on.

Keep an inventory. Write down your platform, PHP version, host, plugins and who has access. When news like this breaks, that list answers "are we exposed?" in minutes.

Schedule updates, or automate them. Set a monthly update day, and apply urgent security fixes within days.

Put a web application firewall in front. It won't replace patching, but it can block known attacks while a fix is rolled out.

Give people only the access they need. This is called least privilege. Limit admin rights and remove old accounts, so a stolen login reaches as little as possible.

Keep tested, off-site backups. A backup stored away from your server, and restored once as a test, is what gets you back online quickly after a break-in.

Turn on monitoring and alerts. Uptime checks, file-change alerts and Google Search Console's security notices can flag a problem early.

Write a one-page incident plan. Note who to call, who can take the site offline, where the backups live and who speaks to customers.

Name one owner. Make one person, in-house or at an agency, accountable for maintenance, because sites stay unpatched when everyone assumes someone else is on it.

Forward this to your developer or host

1. Which PHP version serves our site? Check the hosting panel, or in WordPress open Tools, Site Health, Info, Server. Note that php -v shows the command-line version, which can differ.

2. Are we on 8.5.12, 8.4.27, 8.3.36, 8.2.35 or newer? If we are on 8.1 or older, what is the upgrade plan?

3. If PHP comes from Debian, Ubuntu or RHEL packages, check that distribution's security tracker. Fixes are back-ported, so the version number may not change (Ubuntu 24.04's patched package still reads 8.3.6).

4. Have all PHP processes been restarted since the update?

5. Temporary only: if we cannot update today, PHP's interim memory limit and session upload progress settings may reduce exposure. Confirm with your host first.

6. Has the server been checked for backdoors or other signs of compromise, going back to at least 17 October?

7. Is a web application firewall in place, with its PHP2Shell rules on?

8. When did we last restore a backup as a test?

Frequently asked questions

What is PHP2Shell?

PHP2Shell is the name for two critical flaws in PHP, CVE-2026-109618 and CVE-2026-109619, made public on 21 October 2026 and rated 9.2 out of 10. They let an attacker with no login run commands on a server using PHP 5.4 up to 8.5.11. Fixed versions came out the same day.

Is my WordPress site affected by PHP2Shell?

WordPress runs on PHP, so your site is exposed if the server's PHP is unpatched. Updating WordPress or its plugins does not fix it, because the flaw sits in PHP itself. Ask your host whether the server runs a patched version and whether PHP was restarted since.

Are Webflow sites affected by PHP2Shell?

Webflow said in its Trust Center that its core services are not built on PHP, are not affected, and need no action from customers. Any separate tools or servers your site connects to that do run PHP still need checking.

If my site is patched, am I safe from PHP2Shell?

Patching closes the hole, but it does not remove an attacker who got in beforehand. The earliest recorded attempt was on 17 October, four days before the fix. The UK's National Cyber Security Centre advises checking for backdoors, so ask your host to review any server that ran an affected version for signs of compromise.

Will PHP2Shell hurt my Google rankings?

A patched site that was never broken into should not be affected. If an attacker changes your pages or adds spam, Google may show a "This site may be hacked" label beside your site in results. That label costs clicks until the problem is fixed and you request a review in Google Search Console.

A calmer Halloween next year

For many owners, the scariest part of PHP2Shell was not knowing whether their own site was exposed. Once your developer has worked through the box above and one person owns your site's upkeep, that question has an answer.

If you would like a second pair of eyes on your set-up, whether it runs on WordPress, Webflow or something else, get in touch with the Tiron team.

Sources

• PHP, 2026 news archive and security advisories

• CERT-EU, Security Advisory 2026-018: Critical Vulnerabilities in PHP

• UK National Cyber Security Centre, Critical security issue affecting PHP

• Palo Alto Networks Unit 42, Threat brief: CVE-2026-109618 and CVE-2026-109619

• Google Cloud, Responding to core PHP vulnerabilities

• Amazon Web Services, PHP2Shell exploitation before public disclosure

• The Hacker News, PHP warns of another unpatched flaw

• Tenable, PHP2Shell frequently asked questions

• Webflow, Trust Center

• W3Techs, Usage statistics of PHP and WordPress

• Google, Search Help on the "This site may be hacked" label